Hiroaki Nakano
nakan****@nttco*****
2013年 12月 27日 (金) 15:12:32 JST
中野@幕張です。 世の中で、208.5日問題ver.2がRHEL6で発生して一部話題になったり していますが、その関係でちと気づいたことあります。 208.5日問題ver.2とは、RHEL6.1〜6.4くらいで、208.5日後に ホットリブートもしくはkexec(kdump含む)をすると、tscカウンタが オーバーフローしてシステムクラッシュを含む影響が予想される、 という問題ですが、その回避策として、カーネルパラメータに notscオプションをつけて、タイマをtscからhpetなどにしてしまう というのがあります。 それをすると、tscではタイマの最小単位がナノ秒なのが、 hpetにすると最小単位がマイクロ秒になってタイマ粒度が 1/1000になります。 # いや、この場合1000倍になるっていうのかな？精度が # 1/1000で、最小単位が1000倍になります。 で・・・ UltraMonkey-L7のvirtualservice_tcp.cpp L494付近ですｗ handle_acceptメソッドで、acceptするときに スレッドプールからスレッドを取り出してacceptorとして 登録し、nanosleepして次のacceptを待つのですが、 その待つ単位が50ナノ秒です。 これ、タイマがhpetになると、50nsecじゃなくて1usec待ちますね＾＾； # APICタイマとかだと余計遅くなりますがｗ タイマを変更すると性能が落ちる可能性があるのは、 一応ノウハウとして知識に入れておいていいかもです。 余談： ここ、SO_REUSEPORT(BSDのではなくLinuxの方)つかったら nanosleepじゃなくselectに変えられるのかな？ SO_REUSEPORTをどう使うのが一番効果的なのか、 悩み中ですｗ -- 中野 宏朗 (NAKANO Hiroaki)
UltraMonkey-L7
Fork