SVX日記
2006-02-05(Sun) メモリの増設を思い立つ
先日、準最新のノートPCを入手してホクホクのオイラであるが、あまりに快適すぎて不満が出てきてしまった。人間の業とは真に深いものよのう。つまり、ウィンドウの切り替えがちょっとモタつくのが、どーにもガマンならなくなってしまったのだ。特にPhotoshopElement。そりゃ、明らかな超重量級アプリであるから、512MBという我が人生最大のメモリ容量をもってしても、さすがにスワップインが伴っても不思議でもなんでもないのだが。
でも、気になるのだッ!! ……えぇいッ!! 3年以上は愛用する予定なのだから、増設してしまえッ!! そういえば、最近のメモリの相場はどうなのよ。オイラの最後の記憶では、デスクトップ用のPC-100が128MBで数千円だった気が……いや、車載PC用にDDRの256Mを買ったっけ? まぁ、いいや。まずは、NECの純正メモリを確かめてみよう。
ちょっと不思議だったのが、このノートPCに付属のマニュアルには、適合する純正メモリの型番が記載されているのに、NEC Directでは扱っていないコト。純正メモリを扱っていない直販サイトってなんじゃらほい……と思いつつ、ググってみてわかった。なんと、1GBの「PK-UG-ME022」は定価16万円(税抜)也。23%オフで129,360円!! ……とかいわれてもなぁ。いくらなんでもこのご時世、そんな値段なワケがない。NECともなれば、扱う部品の種類があまりに多岐に渡るから、値動きの激しいPC用部品のカタログ更新が追いつかなくなり、しまいにはあきらめてしまった状態なのだろうな。
なんにせよ、価格.comに行ってみよう。なんでも「DDR2 SDRAM/SO-DIMM PC2-4200」という規格が適合するらしい。まずはNEC Directでも売っているI/O DATAの製品……3万すか、ちと高い。BUFFALOの製品も似たようなもの。高いなぁ、512MBにしとくかなぁ……そうだ、ノーブランドだとどうなんだろう? わ。1万弱であるじゃねーか!! でも、相手はメモリだからなぁ。メモリが不良だと、動作が不安定になるし、HDDと違って予備クラスタでごまかせないからなぁ……。
2006-02-06(Mon) ディスクキャッシュで腹イッペイ
そうそう、Linuxのサポートを仕事にしていると、当然ながらOSの挙動について詳しくなる。システムのトラブルを解決するには、大量のシステム統計情報をガリガリと読みこなし、原因を推定し、診断を下さねばならないからだ。だから、最近はLinuxのメモリ利用状況は、ログを読むだけで手に取るようにわかる。
いきなり昔話になるが、太古のOS(MS-DOSなど)には、ディスクキャッシュという機能があった。搭載されているメモリの一部に、フロッピーディスクやハードディスクから読み込んだ部分を貯蔵して(残して)おいて、再度必要になったときに、ディスクから読まずに、メモリから取り出すことで高速化する機能である。キャッシュに利用されるメモリ量はキャッシュ機能をオンにする時に設定によって決まる。キャッシュ用のメモリ量が多いほど快適になるが、その分メインメモリが減るので、設定には熟慮を要した。
しかし、近年のOSにはディスクキャッシュの設定は存在しない。だが、別にディスクキャッシュという機能がなくなったわけではない。搭載メモリの遊んでいる部分は、すべてディスクキャッシュに利用してしまおうという方針になっているのである。確かに余っているメモリを有効活用するという意味で、ディスクキャッシュはうってつけである。
だから、システム起動時はともかくとして、システムが稼動するにつれて、空きメモリにはどんどんディスクの内容が充填されていく。この段階では、キャッシュした内容が再度使われるかどうかの判断なんて行われない。なにしろ、カタッパシから読んだディスクの内容を空きメモリに充填していくのである。これは、設定にもよるが、搭載メモリの90%以上が利用された状態になる程度まで進行する。つまり、真に空いているメモリが10%以下になってしまうまで続くのである。
[mitsu@colinux mitsu]$ free
total used free shared buffers cached
Mem: 61416 60000 1416 0 3516 38636
-/+ buffers/cache: 17848 43568
Swap: 65528 0 65528
上記は、coLinuxを64MBで起動して、しばらくの後の状況である。搭載メモリが61416KB、利用メモリが60000KB、空きメモリが1416KB。実にメモリ使用率97.7%である。で、どれくらいキャッシュに利用されているかというと、buffersとcachedの合計値がそれだ。42152KB。これは68.6%である。実に搭載メモリの7割近くは、ディスクキャッシュに利用されているのである。
で、大変に質問に多いのがこの状況についてである……「たいへんです!! ウチのサーバ、ほとんど空きメモリが残ってないんです!!」……という質問である。結論から言うと、思いっきり大丈夫である。何の心配もない。ディスクキャッシュの内容なんてのは「別になくても構わない」内容であるから(だって、同じデータがディスク上にあるのだ)、別途必要になった時には即座に開放することができるからである(例外はあるが)。
この状況では「-/+ buffers/cache」の行に注目しなくてはいけない。usedの欄はかなり少なく、freeの欄はかなり多い。これは、キャッシュに利用しているメモリ容量を、空きメモリであるとして計上した場合の容量である(実際にbuffersとcachedの数値を加減してみてほしい)。つまり「実質の空きメモリ」はこの行で確認できるようになっているのである。それを加味すると、メモリ使用率は29%。まだまだ余裕であることがわかる……
……と、このようにLinux環境においては、サクっとメモリについて語れるオイラであるが、Windowsはわからない。統計情報をどこで見たらいいのかさえわからない。え? やっぱそう? タスクマネージャ? そーなのか……やっぱり、テキスト至上主義のUNIXの方がどう考えても正しい姿だよな。ホントにこんな情報しかないの? でも、項目の意味すらわからないんだよねぇ。ググる……
……概ねわかった。タスクマネージャの「物理メモリ」と「コミットチャージ」が重要な情報らしい。まずは「物理メモリ」の「合計」だが、これは実際の搭載メモリを現している。搭載メモリが512MBなら、約512000を表示しているはずだ。
で、重要なのが「コミットチャージ」の「合計」だ。これはシステムが利用しているメモリ容量だ。400000とか表示されていたら、400MB利用しているという意味。なに? ウチは512MBしか搭載してないのに、800MB以上使っているコトになってるって? 大丈夫。別におかしくない。ざっと言うと、足りない部分はハードディスクをメモリ代わりに利用しているからだ。それが仮想メモリ。ただし、ハードディスクをメモリ代わりに使う場合は、必要なときにメモリに呼び戻さなければならないので、遅くなる。これがPhotoshopのウィンドウに切り替えるときにモッサリする理由だ。
結局、どうすればいいのか? それは「コミットチャージ」の「最大値」を見ればいい。自分が普段使うように……できればちょっと贅沢めにアプリをたくさん立ち上げて、ウィンドウを開きまくって「最大値」を見るのだ。それが望ましいメモリ搭載量である。理論的には、その値が「物理メモリ」の「合計」を上回らない限り、仮想メモリは利用されないはずである。つまり、それでもモッサリを感じるとしたら、それはメモリのせいでなく、CPUの処理能力のせいであるということだ。
ちなみに「コミットチャージ」の「制限値」は「物理メモリ」の「合計」と仮想メモリの容量を足した数値だ。どうがんばっても、これを超えてメモリを利用することはできないという限界量だが、限界量付近ではかなりレスポンスが悪化するハズなので、ここまで大丈夫であるとは思わないほうがいいだろう。
2006-02-07(Tue) メモリに安心させられる
注文していたメモリが届いた。まぁ、しかし……なんだこのパッケージは。コンドームじゃあるまいし。そんなに思い切りデカデカと「安心」なんて表示をしなくても……そりゃ確かに、オイラもそれを一番大事な要素と考えて購入したんだけどさぁ……。
しかし、例によって箱を開けると内容物は小さい。下手に大きいとノートPCの中に入らなくて困るので、そりゃ通常サイズであってほしいが、1万円も出したのにかかわらずこの大きさ……金を出した甲斐がないったらありゃしない。今は亡き、ハイウェイカードを5万円分買った時の約20%にあたる落胆ぶりである。
PCを裏返しにして、ネジを3箇所外し、表に返し、キーボードを持ち上げると、メモリ増設スロットが現れた。で、ちょっと緊張しながら、挿し込む……前に、流しで蛇口に触れておく。これは、静電気でメモリが破壊する恐れがあるので、必要とされている儀式であるが、静電気でメモリを破壊してしまったという人の話を聞いた事がないのはナゼだろう? ここは一発、電子ライターのパッチンで、要らないメモリにプチサンダーを落とし、動作確認をしてみたいところである。意外と平気なんじゃないの?
余談であるが、似たような儀式に「車のヘッドライトの交換時、電球には手を触れない」というものがある。なんでも、点灯時に付着した手の油脂が蒸発して、電球が割れることがあるらしい。しかし、私は以前に雑誌の特集で、コッテリとバターを塗りつけて点灯させてみた実験記事を読んだことがある。別に、電球は割れなかったという話だ。ちゅーわけで、そーゆーわけである。
さて、増設して好きなだけウィンドウを開いて作業をしてみた。んが、コミットチャージは750MBを超えない。そりゃ、そうだよな。事前に確認してみた時でも700MBを越えるあたりがやっとだったんだから。せっかく増設したが、増設分の75%が遊んでしまっている状態である。
しかし、だからといって1GBの増設が無駄で、512MBの増設で十分だったというわけではない。昨日書いたように、近年のOSは搭載メモリの遊んでいる部分をすべてディスクキャッシュに利用し、パフォーマンスの改善に役立てるからである……Linuxだけでなく、Windowsでもそうなんだよね……? まぁ、試してみりゃいいのである。
cygwinから大き目のファイルのハッシュ値を求めてみよう。ハッシュ値を求めるのは、ファイルの内容をすべてナメ、全領域にアクセスさせたいだけで、今回の場合はそれ以上の意味はない。ちなみに、ファイルは30分のmpeg1ビデオファイルで1つ300MBだ。
SUZAKU:/MyDocuments/My Videos/megaten $ ls
合計 612920
-rwx------+ 1 mitsu 筏 313814368 Feb 20 2005 0220megaten1.vcd.mpg*
-rwx------+ 1 mitsu 筏 313814368 Apr 10 2005 0410megaten1.vcd.mpg*
SUZAKU:/MyDocuments/My Videos/megaten $ time md5sum 0220megaten1.vcd.mpg
f1b51c53ee2ebd5bb97bf6dc9abdbee3 *0220megaten1.vcd.mpg
real 0m16.929s
user 0m4.806s
sys 0m1.301s
SUZAKU:/MyDocuments/My Videos/megaten $ time md5sum 0220megaten1.vcd.mpg
f1b51c53ee2ebd5bb97bf6dc9abdbee3 *0220megaten1.vcd.mpg
real 0m7.092s
user 0m5.027s
sys 0m1.181s
SUZAKU:/MyDocuments/My Videos/megaten $ time md5sum 0220megaten1.vcd.mpg
f1b51c53ee2ebd5bb97bf6dc9abdbee3 *0220megaten1.vcd.mpg
real 0m7.253s
user 0m4.876s
sys 0m1.361s
SUZAKU:/MyDocuments/My Videos/megaten $ time md5sum 0410megaten1.vcd.mpg
65c2d0261cd90151f1bd06fc63c3c5df *0410megaten1.vcd.mpg
real 0m20.343s
user 0m4.566s
sys 0m1.141s
SUZAKU:/MyDocuments/My Videos/megaten $ time md5sum 0410megaten1.vcd.mpg
65c2d0261cd90151f1bd06fc63c3c5df *0410megaten1.vcd.mpg
real 0m6.897s
user 0m5.117s
sys 0m1.111s
SUZAKU:/MyDocuments/My Videos/megaten $ time md5sum 0410megaten1.vcd.mpg
65c2d0261cd90151f1bd06fc63c3c5df *0410megaten1.vcd.mpg
real 0m6.966s
user 0m4.917s
sys 0m1.321s
SUZAKU:/MyDocuments/My Videos/megaten $ time md5sum 0220megaten1.vcd.mpg
f1b51c53ee2ebd5bb97bf6dc9abdbee3 *0220megaten1.vcd.mpg
real 0m6.876s
user 0m4.917s
sys 0m1.311s
2006-02-15(Wed) Cygwinでsoxしてlameする
PCを新調して、HDDが80MBになったので、iTunesをインストールして、手持ちのCD百数十枚をすべて放り込んだら、ナンでもカンでもこのPCに集めてしまいたくなってきた。残りHDD容量は15GBを切っているが、まだ15GBもあるという見方もできる。なんとなく、過去にCD-R焼いて保存してあった、デジカメの写真もHDDに呼び戻してしまう。なーに、容量が不足したら、改めてDVDに焼いてしまえばいいのだ。
そうだ。そういえば先日、過去に録り溜めた「英会話入門」のCD-Rが見つかったのだった。mp3に圧縮して、CD5枚ほどになっているから、軽く数年分はありそうだ。以前に書いたとおり、最近「英会話入門」が再開されたのだが……しかし、どうも昔のノリでないんだよなぁ、コレが。で、番組を聞く環境整備もできないまま、しばらく聞かずに自動録音サーバを放置しておいたら、いつの間にか遠山顕先生は「英会話中級」に移っていて、録音時間がズレ、録音しソビれていた……えぇい!! なにしろ、このCD-RもすべてPCに放り込んで、聞く環境を整備するのだッ!!
……と、意気込みつつ、昔のCDを読ませたトコロ、妙にmp3のファイルサイズがデカい。英会話入門は15分番組なのに8MBも食っている。普通の曲だと15分で15M弱になるはずなので、8MBは十分に小さいが、モノラルのしかもAMラジオの録音に、44kHz、80kbpsというのは、ちょっとオゴりすぎじゃねぇか。当時のオイラはナニを考えていたんだろう? こりゃマズい。なにしろマズい。マズいったら、マズい。これは再エンコードしなおして、正しい状態にしなければ。
最終的に英語を聞くのが目的なのであれば、ビットレートなんて気にせずにサッサと聞き始めればいいのだが、どーもオイラの悪いクセが出た。こーゆー問題を解消しないと聞く気にならなくなってしまうのである。だが、これは技術者全般の悪いクセであろう。正しい状態にして、キチンとライブラリ化しないと気がすまない。だってそうすりゃ、プレイヤへの転送も速くてラクだ。ラクするための苦労をいとわないのが正しい技術者の姿である。だから、これでいいのだだッ!!
再エンコードする方法にもこだわる。イッキに、ラクに、確実に……と考えると、コマンドインターフェイスのヤツ以外には考えられない。unix系のmp3エンコーダである「lame」とサウンドコンバータ「sox」を利用することにしよう。これをcygwin環境にインストールするのである。
しかしながら、cygwin用のバイナリ配布は行われていない。よって、サックリとはインストールできず、いわゆる「./configure、make、make install」を行う必要がある……のだが、オイラはこの方法でちゃんとインストールできたコトが少ないんだよねぇ。大丈夫だろうか。まぁ、とりあえず、やってみる。
まずは「lame」だ。「./configure、make、make install」……お!? これは一発でインストールできた。特に問題も生じない。じゃ、この調子で「sox」だ……が、ダメ。最後の「make install」する段になって……
SUZAKU:/home/mitsu/sox-12.17.9 $ make install
make: `install' は更新済みです
……とか出ちまってインストールができない。なんだ!? ナニが悪いのか? 最近はLinuxのサポートをやっているので、不具合の根っこを調査するのに、ソースを読んでどうこうするのには慣れたが「./configure」や「make」はいまだに苦手科目なんだよなぁ。こういう場合は、どうやって問題の根を探したらいいんだ?
$ ./configure
:
:
Old Rate enabled.................. no
Fast ulaw enabled................. yes
Fast alaw enabled................. yes
GSM Support....................... yes
ALSA Driver....................... no
OSS Driver........................ no
SUN /dev/audio.................... no
Ogg Vorbis support................ no
MAD MP3 Decoder................... no
LAME MP3 Encoder.................. no
soxは外部に関連プログラムがあると、自動的にそのライブラリを利用するようにコンパイルされる。今回の場合はlameだ。ライブラリを取り込んで、soxが直接mp3を吐けるようになる。だが、既にlameのインストールは終わっているハズなのに表示が「no」のままだ。別にsoxでmp3を吐けなくても、パイプでlameに渡してもいいのだが、せっかくそのような機能があるのに、利用しないテはない……というか、利用できるハズなのに理由がわからず利用できないのは、どうにも気持ち悪い。
さらに気になるのはその前のmadというヤツ。こいつがあればsoxが直接mp3を読めるようになるっぽい。今回の場合は入力も出力もmp3であるから、そんなものが利用できるなら、利用しないテはない……というか、利用できるハズなのに理由がわからず利用できないのは、どうにもこうにも気持ち悪い。
ちょっと本腰入れて「./configure」について勉強するか。ググると「configureをデバッグする」なんてぴったりのページが見つかった。ふみふみ……config.logを読めって?
SUZAKU:/home/mitsu/sox-12.17.9 $ vi config.log
configure:4695: checking lame/lame.h usability
configure:4707: gcc -c -g -O2 -mno-cygwin -Wall -mno-cygwin conftest.c >&5
conftest.c:68:23: lame/lame.h: No such file or directory
configure:4713: $? = 1
即席で作られた「conftest.c」の中には「#include
#include <lame/lame.h>
int main() {
printf("Where is lame?\n");
}
$ gcc test.c
$ gcc -c -g -O2 -mno-cygwin -Wall -mno-cygwin test.c
test.c:1:23: lame/lame.h: No such file or directory
$ gcc -mno-cygwin test.c
test.c:1:23: lame/lame.h: No such file or directory
「-mno-cygwin」だ。これってナニ? 調べたら、cygwinライブラリを利用しないバイナリを生成するオプションとのコト。cygwinライブラリを組み込むと、cygwinをインストールしていない環境で動かなくなるとか、自動的にGPLになってしまうという政治的な問題があるらしいが、そんなの自分のPCで使う分には関係ないやん。サクッと……
SUZAKU:/home/mitsu/sox-12.17.9 $ vi configure
2849 case "$target" in
2850 *cygwin* )
2851 # CFLAGS="$CFLAGS -mno-cygwin"
2852 # CPPFLAGS="$CPPFLAGS -mno-cygwin"
2853 # LDFLAGS="$LDFLAGS -mno-cygwin"
2854 ;;
2855 esac
configure:4695: checking lame/lame.h usability
configure:4707: gcc -c -g -O2 -Wall conftest.c >&5
configure:4713: $? = 0
configure:4831: checking for lame_init in -lmp3lame
configure:4861: gcc -o conftest.exe -g -O2 -Wall conftest.c -lmp3lame >&5
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -lmp3lame
collect2: ld returned 1 exit status
configure:4867: $? = 1
今度はココでコケとる。「-lmp3lame」が見つからん? ライブラリの「libmp3lame.a」がないってことか? それが「/usr/local/lib」下にあるのは確認済みじゃゾイ。ライブラリの位置を教えたればいいんかな? 以下のようにオプション付けて、再度「./configure」じゃ!!
$ ./configure "LIBS=-L /usr/local/lib"
:
:
Old Rate enabled.................. no
Fast ulaw enabled................. yes
Fast alaw enabled................. yes
GSM Support....................... yes
ALSA Driver....................... no
OSS Driver........................ yes
SUN /dev/audio.................... no
Ogg Vorbis support................ no
MAD MP3 Decoder................... yes
LAME MP3 Encoder.................. yes
SUZAKU:/home/mitsu/sox-12.17.9 $ make install
make: `install' は更新済みです
うげ。相変わらずやん……コレ、意味わからん……でも……「$ make -n uninstall」は動くんだよねぇ……って、もしかして、アレか? この「install」って名前が悪い? つーか、同じディレクトリに置いてある「INSTALL」っていうドキュメントファイルに反応している!?
SUZAKU:/home/mitsu/sox-12.17.9 $ mv INSTALL INSTALL.txt
SUZAKU:/home/mitsu/sox-12.17.9 $ make install
$ sox before/1007.mp3 -b -r 16000 -t wav - | lame -b 24 - - > after/1007.mp3
2006-02-26(Sun) FT245AMテスト基板稼動
久々に、ちょっと気合を入れて作業してみた。思い返せば、基板を設計してから約1ヶ月、基板が届いてから1ヶ月、ハンダ付け始めてから1ヶ月……で、今日になってやっと通信に成功した。まったくもってヒドい開発ペースである。
途中まで裏表逆に設計してしまった上に、使った線がちょっと太かったので、なんだかムチャなことになっている……が、ちゃんと動くからこれでよいのだ。USBに接続すれば、ちゃんと認識されるし、Cygwinから/dev/com8にデータを送れば、ちゃんとPICが受信してくれる。一応、変換基板としては動作確認完了といってよいだろう。ほっ、よかった。
とりあえず、これといって作りたいUSB対応機器はないのだが、以前から便利に使っていた「CPU使用率メータ」のUSB版でもサクッと作ろうかと思っている。今、職場で使っているPCはノートだもんだから、シリアルポート用のアイテムが使えないんだよね。
余談だが、この開発は、以前に愛用していたジャンクのメビウスノートを引っ張り出してきてやっている。というのも、以前に作ったRS-232C切り替え器はPICライターの接続に便利だし、4ポートの内蔵USBハブもこれまた便利なのだ。233MHzの遅さはちょっと気になるが、まぁ、Cygwinのviでソース書いて、アセンブルして、PICに書き込む程度なら、さして気にするほどでもない。
2006-02-27(Mon) ほろ酔いケース加工
なんだか、久々にやり始めたら楽しくなってきちゃって、廊下の端に座り込んで、グラスのスコッチをチビチビやりつつ、その辺に転がっていたプラの名刺ケースの箱をガリガリ。史上最強にいい加減な加工をしてしまったが……まぁ、とりあえず十分である。あ、ちなみに、今回使用するアナログメータは、以前に90円で買ってきたバッテリチェッカをバラしたジャンク部品である。シャレであるから動けばよいのだ。
2006-02-28(Tue) CPU使用率を得てみる
ここ数日「USB接続版アナログCPU使用率メータ」を作っているワケであるが、あくまでハードウェア側は「入力された数値をアナログ表示するだけ」のガジェットであるから「CPU使用率メータ」にするためには、PC側から「CPU使用率」をハードウェア側に継続的に送信しなくてはならない。
以前にCPU使用率メータを作った時には、ネット上からWindows用のCPUメータアプリ(ソース付き)を持ってきて、適当に流用して作った。今回もそれを使おうかな、オレ用cvsからプロジェクトを落としてと……あれ? リンカを通らない……あぁ、前回はBorlandのフリー版Cコンパイラ用に書いたんだっけ……Cygwin上のgccだとなんだか大量にエラーを吐いてしまう。いまさらコレだけのために、別途Cコンパイラを入れるのもイヤだなぁ……面倒くさい。
どぉーしよぉー……ん? 待てよ? Cygwinにはtopとかvmstatとかってないんだっけ? ……ない……ん? じゃ、/procの下になんかないの? お!? あるじゃん!! /proc/stat!! Cygwinってイザという時に期待を裏切らない。イザという時以外には、よく期待を裏切られるけど……。
$ cat /proc/stat
cpu 4120394 0 5247745 79092769
cpu0 4120394 0 5247745 79092769
page 2388170 390404
swap 2388170 352464
intr 62255651
ctxt 338348792
btime 1141097464
大事なのはcpuの行。詳細はman procするか、ココを見て欲しいが、なにしろ、CPUが仕事してた時間と遊んでた時間の合計はここから得られるのである。あとは単位時間ごとに差分をとって比率を得るだけ。
1 #!/usr/bin/ruby
2
3 # CPU使用率を求める
4
5 busy = all = nil
6
7 loop {
8 open('/proc/stat', 'r') {|psh|
9 lastbusy = busy
10 lastall = all
11
12 if(psh.readline =~ /^cpu\s+(\d+)\s+(\d+)\s+(\d+)\s+(\d+)\n$/)
13 user = $1.to_i; nice = $2.to_i; sys = $3.to_i; idle = $4.to_i
14 all = (busy = user + nice + sys) + idle
15 end
16
17 if(lastall)
18 p (lastbusy - busy) * 100 / (lastall - all)
19 end
20 }
21 sleep 1;
22 }