-
- いいね！0
tagomoris
@tagomoris
しばらく通信断が起きた後のケースを想定すると送信待ちキューがそれなりに詰まってることが想像され、しかもそれが複数ホスト同様の状況になっている可能性も高いので、ゆっくりめに送りつつ送信待ちキューがはけるのを期待するのがよい
2014-04-04 17:39:35
tagomoris
@tagomoris
@sonots 「吐き出す数」って、その吐き出す処理がどのくらいの時間で完了するかの完全な見通しがあるならいいけど、無いならひとつずつやって完了を確認しつつ進まないと制御不可能になる気がしますが
2014-04-04 17:40:20
そのっつ (Naotoshi Seo)
@sonots
@frsyuki 千個 queue に溜まっているときに、今は１個吐き出して queued_chunk_flush_interval 待っているのを、x個吐き出して queued_chunk_flush_interval 待つ、というようにしたい。
2014-04-04 17:40:42
たろー
@annin_taro_tofu
@sonots なるほど、connection数が多いと怖いですね...。複数チャンクを同時に送ることになると、帯域とかに気を付けないといけなさそうなので、どばっと出そうなのを防ぐために帯域制限とかのオプションもあったほうがいいかなーと思います。
2014-04-04 17:41:07
Sadayuki Furuhashi
@frsyuki
フロー制御か…buffer側はwriteをひたすら呼ぶけどoutput側からrejectできる設計もありうるな。X MB送信したらY秒待つみたいな。
2014-04-04 17:41:09
tagomoris
@tagomoris
いっぽうある確率で通信断が散発するようなケースを考えると、一度の通信にかかる時間が長くなるだけI/Oに失敗する確率が高まるので、バースト通信の効率が下がる。flush単位(chunk)を小さめに保ち、ひとつずつ確実に送信/確認する、ことを繰り返すほうがよい。
2014-04-04 17:42:32
Sadayuki Furuhashi
@frsyuki
@sonots ほほー。1個writeして0.1秒待つより、10個writeして1秒待つ方が有効なケースがあると言うことです？
2014-04-04 17:43:03
そのっつ (Naotoshi Seo)
@sonots
@annin_taro_tofu 帯域制限が一番いいですよね〜。ただ、今簡単にやろうとすると、chunk size と chunk の数で制御するしかない
2014-04-04 17:43:04
tagomoris
@tagomoris
自分が try_flush_interval を追加したのはあくまで chunk のサイズをRPC payload size limitがある出力先にあわせて制御したかったからであって、通信再送とかはまったく考えてなかった
2014-04-04 17:44:35
tagomoris
@tagomoris
@repeatedly まあ、なんか現場レベルで変な運用が行われてる可能性もあるし、そもそも状況が誤認されている可能性もあるけど、どうなんすかねえ
2014-04-04 17:45:14
SKS rep
@repeatedly
一回のwriteを増やすということは，日頃1回のwriteやっているエラーハンドリングをその複数writeの中でやることになって，さらに複雑度が増すので，入れるのにはかなり慎重になりたい
2014-04-04 17:46:37
SKS rep
@repeatedly
複数writeのうちの間でネットワークエラーが起きたときに，そこでもexponential backoffするのかとか，色々と考えることが増える．それ以降は全部secondaryに流すべきなのかとか…
2014-04-04 17:48:07
たろー
@annin_taro_tofu
@sonots そうですね、うまい帯域制限方法とかあると嬉しいですね。とにかく細かい単位で送るようにして、chunk sizeを小さくすることで擬似的に通信量を均すのが手を入れないで帯域制限を行う現実解かなと思います。
2014-04-04 17:48:32
そのっつ (Naotoshi Seo)
@sonots
@frsyuki うーん、0.1 ぐらいならいいんですが、実際 0.1s に 1 chunk だと遅くて、とはいえば、もっと queued_chunk_flush_interval を短くして大丈夫なんだろうか、というかんじですね。
2014-04-04 17:57:19
そのっつ (Naotoshi Seo)
@sonots
@repeatedly 複数 write で例外がおきた時点で例外処理に入ればいいかなと思ってました。成功した分は成功しているので pop 済み。
2014-04-04 18:00:29
Sadayuki Furuhashi
@frsyuki
@sonots queued_chunk_flush_intervalは短くするとfluentd内部に問題が発生しうるかというと、問題ない気がしますねぇ。試しに0.001にしてみるのはどうでしょう
2014-04-04 18:00:33
tagomoris
@tagomoris
@sonots @frsyuki flush_interval を設定して普段のflushをそこそこ高頻度にしつつ buffer_chunk_limit を大きめにすれば再送時の 1 write ごとはけっこう大きいデータ量が転送されるので、そんな感じでいいのでは？
2014-04-04 18:04:19
そのっつ (Naotoshi Seo)
@sonots
@tagomoris @frsyuki buffer_chunk_limit を大きくすると詰まりはじめて性能劣化する、という問題があってですね ...
2014-04-04 18:05:07