HDDへのディスクI/Oを甘く見てはいけない・・・

今日は午前中1件、午後2件社外での打ち合わせで、その間の移動や空き時間はできるだけ歩いていたのですが、かなり暑くて汗をかいた感じでした。いずれの打ち合わせも実のあるもので満足です！

さて、そのうちの一つが少し悩んでいた問題の検討で、Linux上で3万スレッドくらいが通信・ディスクI/Oなどを並列処理するプログラムの動きにムラがあるという感じの課題です。

freeコマンドで確認すると、動きにムラが出てくると下記の感じに、buffersやcachedがかなり大きくなり、freeが減ってくる、という感じでした。

# free
             total       used       free     shared    buffers     cached
Mem:      37002864   11297192   25705672          0    5781972     268444
-/+ buffers/cache:    5246776   31756088
Swap:     39239672          0   39239672

プログラムを少し変更しながら、ディレクトリアクセスを減らすとどうなるか、ディレクトリ作成を減らすとどうなるか、ファイル書き込みをなくすとどうなるか、ファイル読み込みもなくすとどうなるかなどを比較してみると、ファイル書き込みとディレクトリ作成はかなり差が出ることがわかりました。

そこで、HDDに書き込み先をしていたのを、RAMディスクにして実験してみました。

# free
             total       used       free     shared    buffers     cached
Mem:      37002864    5695780   31307084          0       9580     574304
-/+ buffers/cache:    5111896   31890968
Swap:     39239672          0   39239672

buffersが全く増えません。ファイル書き込み・ディレクトリ作成がbuffersでデバイスへの処理待ちになっていた感じでしょう。

普通のプログラムではまず問題にならないようなHDDへのディスクI/Oですが、1Gbpsを超えるネットワークパケットを扱いながら、多数のスレッドでディスクI/Oを繰り返すと影響は大きく、スループットを見ていても見事に低下したり波が出たりします。

問題が明らかになったので、具体的にこういう構成で対処しようというアイディアもかたまり、ホッとした感じです。個人的にはこういう問題も大抵「プログラムの問題」と見られやすく、その疑いを晴らすのはかなり苦労するのですが、無事にプログラム自体の作りの問題では無いということを実証できて良かったというところです。

今年度中に目処をつけなければならない仕事がたくさんあったのですが、ようやくいずれも目処がついてきましたし、来年度の相談もたくさんいただいており、ますます楽しい仕事をたくさんできそうです！