Linux OSのジッタを体系的に削減する黒魔術 | FAworksブログ
低遅延性の求められるトレードシステムにおいて、ジッタの原因をどのように体系的に発見してひとつずつ削除するのか？この質問はmechanical-sympathyのメーリングリストで提示されました。 アズール・システムズの技術担当副社長兼CTOであり、共同創業者であるGil Tene氏はこの質問に対して豊富な実経験から生まれた、蓄積された知恵を用いて回答しました。それは広く共有されるべき回答ですので、ここに紹介します。 Linuxシステムにおける一次的中断 (“hiccup”) やジッタの原因を見つけることはほぼ魔術と言えます。人々はしばしば急なCPU使用率の上昇を見て「この原因は一体何だろう」と想像をめぐらせます。 私の場合は、経験上の証拠（これまで手掛けた数十個のサイトに共通する）や他の技術者との情報交換に基づき、私の好みに合わない設定になっていて、かつシステムレベルの一時的中断が発見され
コスいチューニング - フツーな日常
全く本質的でなく効果も小さいものばかりだけど、最後のひと絞りにどうぞ。 Hardware HT無効 今時サーバでNetBurstもないだろうけど、使っているなら切った方が速い。並列実行度が高くなるには違いないが、spin lockとHTは相性がよろしくないし、そもそもNetBurstのHTは速くなる局面が少なすぎる。いっぱいプロセッサが見えるのは気持ちいいが、実効性能を考えると無効の方が速い。 RAID1+0 ブロックサイズは大きめで(256KBとか)にする。"1つのレコードの大きさ ＜＝ RIADのブロックサイズ"である状態だと、RAIDを構成する複数のディスクのうち1個へのリクエストで処理が完結するので具合が良い。逆に"1つのレコードの大きさ ＞ RAIDのブロックサイズ"であると、1レコードの読み出しにも2個のディスクがその処理にかかり切りになってしまう。HDDの毎秒の処理回数は上限
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
