pcgw(2 core, 1G)のメモリ負荷、および虞らくそれに起因するCPU負荷について

kswapd0 というカーネルスレッドがCPUを定期的に100%近くのintensityで使う。 スーパーバイザーから見えるCPU負荷が配信の数と無関係に起こるので気持ちわるい。 peercastの最大CPU負荷は50%程度と見積っていて、これが2プロセス動くから 100%。 スワップデバイスのIOに共なう見掛け上のCPU使用ではなくて実際にCPUサイクルを消費しているらしい。xosviewでページイン/アウトが観測できない。スーパーバイザーから見えるという事でも裏付けられる。

ディスクアクセスがある時もある。この時ディスクアクセスをしているプロセスが iotop で見付からない。 ページングも発生しない。ほとんどがREAD。

最初に考えたのは、メモリにプレッシャーがかかるとプロセスのTEXTセグメントがアンロードされて、それを実行ファイルから読み直しているのかということ。スワップアウトよりも先にそういう事が起こるのは聞いたことがないので、なさそう。

(swappinessの影響については考えてなかった。)

怪しいのはスクリーンショットを放りこんであるディレクトリで、65万ファイル8GBが1つのディレクトリに入っている。ディレクトリ自体のサイズが40MBあって、スクリーンショットはWebUIから頻繁にアクセスされる。スクリーンショットは増えつづけるので、このディレクトリのサイズも増加しつづける。

このディレクトリの内容のキャッシュが(カーネルの管理する)メモリから掃き出されると、ディスクから読み直さなければならなくなる。

ちなみに、個々のファイルの属性は別のiノードに格納されているので、ls --color でディレクトリを読むと1GB程度のSLAB割り当てが起こるらしい。pcgwでこのようなタスクが自動的に起こることはないが…。

ディレクトリの構造として最もシンプルなものを選んでしまった。この時の考えとしては、ディレクトリエントリーがメモリに載ればパフォーマンス問題は出ないだろうと考えた。

Squidのように0~Fまでのディレクトリを作ってその下に00~FF までのディレクトリを作って…というようにハッシュテーブルのように分割するべきだった？

ただし、この場合でもファイルをランダムにディレクトリに割り当てると「ホットな」ディレクトリの数が多くなって相応のディレクトリキャッシュが必要になるはず。

「時間」 スクリーンショットを保存する時に該当ディレクトリを触るので、必要なディレクトリはプリロードされた状態になる。

「チャンネル」 分散してしまう。100枚だとすると…。知らん。末端のディレクトリサイズの期待値と、同じディレクトリに入っている確率。

ファイルを削除するとディレクトリはshrinkするか？ 答え:しない。ext系のfsではしないようだ。ファイルを全て削除しても一覧処理にディレクトリサイズ分のIOが必要になる。