ℹ️本記事は古いコンテンツを変換して表示しています。
表示が崩れたり、リンクが正しくない可能性があります。ご了承ください。
2016/05/29 23:05 : XtreemFSをFreeBSDで動かす(6) 書き込み速度の改善
どうもFreeBSD+OpenJDKのバグで、Selector.select(int)がタイムアウト前に返ってくる模様。このせいでMRCやOSDのあるスレッドが空回りしてCPUを食いつぶすことがある。(よくある)
これを直してやって、7.4MB/sまで改善した。(前回は6MB/s)
# dd if=/dev/zero of=/mnt/xtfstest/test bs=65536 count=4096 4096+0 records in 4096+0 records out 268435456 bytes transferred in 36.120514 secs (7431662 bytes/sec)
2016/05/31追記:
上記はiSCSI+ZFS+SSD ZILでの測定結果。気になって夜も眠れないので、UFS on SSDにOSDを置いて計ってみたら、6.7MB/sになった。遅くなってるけど、きっと測定誤差だと信じたい。(だとすると改善も誤差だけど……)
# dd if=/dev/zero of=/mnt/xtfstest/test bs=65536 count=4096 4096+0 records in 4096+0 records out 268435456 bytes transferred in 39.965025 secs (6716759 bytes/sec)
正直なところ心が折れそうだけど、GlusterFSは(xattrが必要だから)zfsのzilで加速、とかができないし、微妙に柔軟性が足りない気がするのでもう少しがんばりたい。
どうもFreeBSD+OpenJDKのバグで、Selector.select(int)がタイムアウト前に返ってくる模様。このせいでMRCやOSDのあるスレッドが空回りしてCPUを食いつぶすことがある。(よくある)
これを直してやって、7.4MB/sまで改善した。(前回は6MB/s)
# dd if=/dev/zero of=/mnt/xtfstest/test bs=65536 count=4096 4096+0 records in 4096+0 records out 268435456 bytes transferred in 36.120514 secs (7431662 bytes/sec)
2016/05/31追記:
上記はiSCSI+ZFS+SSD ZILでの測定結果。気になって夜も眠れないので、UFS on SSDにOSDを置いて計ってみたら、6.7MB/sになった。遅くなってるけど、きっと測定誤差だと信じたい。(だとすると改善も誤差だけど……)
# dd if=/dev/zero of=/mnt/xtfstest/test bs=65536 count=4096 4096+0 records in 4096+0 records out 268435456 bytes transferred in 39.965025 secs (6716759 bytes/sec)
正直なところ心が折れそうだけど、GlusterFSは(xattrが必要だから)zfsのzilで加速、とかができないし、微妙に柔軟性が足りない気がするのでもう少しがんばりたい。
過去に一度対策を入れているが、うまく動かないことがある、ということでコメントアウトされていたので、ちょっと手を入れてみた。
ただ、コミットではselectが空回りしたら25msだけsleepする動作(もともとそう書いてあったんだよ!)をするので、最悪の場合どこかで25msのレイテンシを稼いでしまう。このレイテンシが問題になるようなら、このスレッドはselectしながら定期的にタイマー(自称poorman's timer)をチェックする動作をしているので、selectorをpipeか何かで定期的(現在のselect timeout時間ごと)に起こすようにしてやれば、selectorのtimeoutなしにできるハズ。
今のところスループットに悪さはしていないようなので、いったん放置。