[[KairosDB]]はキーのインデックスが二分木の[[Cassandra]]を使っているので、キー数つまり系列数が小さいときにはスループットが上がってほしいのだけど、なぜか系列数10,000,100,000,1,000,000のいずれかでもあまり変わらない。しかし、系列数10,000のときだけCPU利用率が半分ぐらい余っていることを発見し、さらにCPU利用率の変動が剥がしく急に落ち込んだりすることがあった。ワーカー数を増やしたりあれこれした結果、kairosdbの設定で、バッチのキューが規定サイズに達するまでwaitするというのがあって、これで処理をブロックしてしまっていた。500ms ⇒ 10ms にすると、CPUを使い始めてスループットが3倍ぐらいになった。 ```bash # If the number of items in the process queue is less than {min_batch_size} the # queue processor thread will wait this many milliseconds before flushing the data # to C*. This is to prevent single chatty inserts. This only has effect when # data is trickling in to Kairos. kairosdb.queue_processor.min_batch_wait=500 ``` さらに系列数を1,000に落とすと、バッチサイズやキューサイズをへらす必要があった。 Xtsdbの実験で100万から1000万個に系列を増やすと急激に性能が低下した。キー数は2000万個だった。Redisってキー数1000万件ぐらいの事例ってあるかぐぐると次の記事がでてきた。キーではなくSETに1000万件突っ込む話だけど、おもしろかった。[[notes/system-engineering/Redis]]ならキー数が増えてもほぼ定数時間でアクセスできるはず...なんだけどな。 [Redisで1000万件のデータを圧縮しつつ定期的に洗い替えする - スペクトラム](https://ksss9.hatenablog.com/entry/2019/01/17/111408)