-
- いいね！0
tagomoris
@tagomoris
@sonots 普段の性能を安定して上げたいなら flush サイズを細かくしたほうがいいのは確かだけど buffer_chunk_limit をいじっちゃうと再送待ちチャンクにまで影響が出るので flush_interval で制御したほうがいい、という話です
2014-04-04 18:08:33
tagomoris
@tagomoris
だいたい普段から性能かつかつな感じの状況のままで運用してたら、更に通信エラーとかで詰まりが出た後の再送をバースト状にやっちゃうと被害が広がるだけのような気がするが
2014-04-04 18:09:22
そのっつ (Naotoshi Seo)
@sonots
https://t.co/I97doyEySk で buffer_chunk_limit 大きくして、dummer で大量に流し込むとひどい性能劣化を再現できるはず
2014-04-04 18:16:52
tagomoris
@tagomoris
@sonots 平常時のflush sizeは flush_interval を短くすることで小さくする(buffer_chunk_limitは関係ない)、そうすればスループット限界近くでの性能劣化は防げるでしょう
2014-04-04 18:17:35
そのっつ (Naotoshi Seo)
@sonots
捌けなくなった場合に、buffer_chunk_limit が大きいと、性能劣化具合がひどい。という事実が、チューニングの可能性を狭めているな。
2014-04-04 18:24:42
そのっつ (Naotoshi Seo)
@sonots
2.1.1 でよくなってたりしないかな. rubinius だと大分スムーズに流れるとリピー氏が言っていた気がするけど > 性能劣化
2014-04-04 18:26:20
そのっつ (Naotoshi Seo)
@sonots
このころは try_flush_interval がまだなかった気がする。queued_chunk_flush_interval はあったのかな ...
2014-04-04 18:30:52
Sadayuki Furuhashi
@frsyuki
多数のホストから1台のサーバにデータを送るとき、データの受信時に結構なCPUを使うようなワークロードで、リトライを起こさずにスループットを上げるのは難しいな。ありがちなのは送信前にサーバにお伺いを立ててサーバが過負荷にならないように制御するか、そもそもpull型にするかかな。
2014-04-04 18:32:07
たろー
@annin_taro_tofu
buffered_chunk_limitが大きい設定で、捌けなくなる→各チャンクサイズが大きくなる→送信するコスト、送信ミスの可能性が高くなる→さらに掃けなくなる っていう悪循環ですかね...。
2014-04-04 18:39:12
そのっつ (Naotoshi Seo)
@sonots
吐き出す chunk の数については、queued_chunk_flush_interval を 0.001 にしても問題なさそう、という見解だったので、それでコントロールする、でいいか。まず試してからだな。
2014-04-04 18:46:49