Linux OSのジッタを体系的に削減する黒魔術

  • このエントリーをはてなブックマークに追加

      2015/08/10

Linux OSのジッタを体系的に削減する黒魔術
低遅延性の求められるトレードシステムにおいて、ジッタの原因をどのように体系的に発見してひとつずつ削除するのか?この質問はmechanical-sympathyのメーリングリストで提示されました。
アズール・システムズの技術担当副社長兼CTOであり、共同創業者であるGil Tene氏はこの質問に対して豊富な実経験から生まれた、蓄積された知恵を用いて回答しました。それは広く共有されるべき回答ですので、ここに紹介します。
Linuxシステムにおける一次的中断 (“hiccup”) やジッタの原因を見つけることはほぼ魔術と言えます。人々はしばしば急なCPU使用率の上昇を見て「この原因は一体何だろう」と想像をめぐらせます。

私の場合は、経験上の証拠(これまで手掛けた数十個のサイトに共通する)や他の技術者との情報交換に基づき、私の好みに合わない設定になっていて、かつシステムレベルの一時的中断が発見された場合に原因の「常習犯」リストを作って参照しています。これらの設定を始めから行っておくことにより、多くの試行錯誤を減らすことができます。(そして、これは「優先事項」ではありません。さらなるアドバイスを探す前に、適切に設定を行っておくべきことです。)
Linuxシステムにおいて数ミリ秒レベルの一時中断瞬断を避けようとするときに、現在私が最初にやることを以下にまとめます。

  1. THP (Transparent Huge Pages)をオフにすること
  2. vm.min_free_kbytesを少なくとも1GB(大規模のシステムでは8GB)に設定すること
  3. Swappinessを0に設定すること
  4. zone_reclaim_modeを0に設定すること

上記1~4のデフォルト値はLinux上では「間違い」であって、それぞれが、(独立して)数ミリ秒単位の一時的中断を引き起こします。私がそのことを知っているのは、実際に個人的にそれらの一時的中断に遭遇したことがあるからです。(例えばTHPが不正を働いた痕跡を示すカーネルスタックトレースがある状態で現行犯逮捕するようなものです。)

加えて、私は通常次を推奨しています。

5. HT(ハイパースレッディング)をONにすること。(Vcoreの実行待ち行列 (run queues) を2倍にするとCPUを待つ可能性は数倍低くなります。)

HT=Offがしばしば推奨されていますが、それはジッタが発生する可能性を著しく増加させてしまう未熟なスピード最適化技法です(数ミリ秒の停滞をジッタと見なすのであれば)。ハイパースレッディングをOFFにすることはシステムにより引き起こされた一時的中断を減らす助けにはなりません(少なくとも20マイクロ秒レベルより大きいレベルの場合には)。HTをOFFにすることはスレッドの実行の線速度を高めることの助けになる場合とならない場合があります。しかし、それはOSについて利用可能な実行待ち行列の数を半分にするという代償のもとに起こるものであって、もし実行可能なスレッドがコアよりも多い状態が数ミリ秒でも存在すれば、スケジューラのクォンタムレベルでの一時的中断が起こる可能性を著しく増大させます。これがシステムから一時的中断がなくなるまで通常HTをONにしておく理由です。その後、HTをOFFにして実験を行うことにより(a)一時的中断が再び起こらないか(b)何か他の測定基準が良くなったかを見るために実験を行うことができます。

numactl, taskset,isolcpusを使用することは、個別のスレッドすべてでジッタや一時的中断の発生(更に、キャッシュの挙動など)を防止する助けになります。同じことが、irqbalanceについても言えます。それらはすべてより高度なものですが、私はまずシステムをクリーンアップし、その後にコアのみを割り当てるやり方が好きです。それに加えて、コアなどを割り当てたら、関心のあるコア(またはコアのセット)上の一時的中断やジッタを個々に測定し始めるべきです。例えば、プロセスをnumactlとともにノード1にロックする場合には、jHiccup(または使用している他のあらゆるツール)の実行が同じノードに制限されるようにする必要があります。

一時的中断やジッタをコントロールするためには、使用しているコアに負荷をかけないようにすることが、特定のコアにワークロードを割り当てることよりもずっと重要なことです。定番のワークロードを避けて、残りのシステムにコアを割り当てること(例えば、initの起動やそれにともないブート後に来るすべてものなど)は、注意深くどのコアがどのワークロードのスレッドを実行するかを考えることよりも決定的に重要なことなのです。

しばしばスレッドがコアに注意深く配置されているシステムを見かけます。しかし、これらのコアはシステムにおいてきちんと割り当てがされていないようなプロセスと共有されています。(そう、これは愚かなことのように見えますが、非常に一般的に見受けられることです。)私がよく最初にお勧めするのは、「全体のシステム」を一つのソケットで実行させ続ける(例えばノード0)ことです。そして、遅延に敏感なプロセスを「もう一方のソケット」(例えばノード1)で実行させます。この状態で実行が適切かつクリーンに行われるようになり、不都合で除去が必要なほど大きな一時的中断がないことが見えてくると、望んでいるソケット内でコアを選択し始めることが可能になります。ただし、大体の場合はそこまで徹底的にやらなくてもよいことの方が多いです。

Isolcpusの場合は幾分(完全にではありませんが)異なります。Isolcpusにより、誰も「偶然に」あなたのコアを共有しないことを知るという利益を得ることができます。しかし、また同時にisolcpusのコアに割り当てるスレッドに関するスケジューラのコア負荷分散機能を失ってしまいます。特定のスレッドをisolcpusのコアで使用することを選択することは時々有益ですが、残りのプロセス(例えば、「JVMの残り」のように、プロセス内でバックグラウンドワーカーとともに稼働するもの)は一時的中断の少ないシステムやノードから依然利益を得ることになります。その利益は、重要なisocpusが割り当てられたスレッドの上にまで代わりに現れることになります。例えば、JVMにおいてisolcpusが割り当てられたスレッドの最も悪い一時的中断でさえも全てのJVMスレッドをまたがるセーフポイントのタイミングのようなものがほとんどになります。そしてisolcpuが割り当てられたスレッドやコアの外部で遅延の影響を依然受けやすい状態になってしまいます。

原文:http://highscalability.com/blog/2015/4/8/the-black-magic-of-systematically-reducing-linux-os-jitter.html(2015-4-8)
※元記事の筆者には直接翻訳の許可を頂いて、翻訳・公開しております。

 -Tech, プログラミング

FAworksではプロのコンサルタントが案件をお探しします

  関連記事

MySQL Cluster―MySQLはいかに2億QPSのスケーリングを実現したか

この記事は、オラクル社MySQL主任プロダクトマネージャ、アンドリュー・モルガン氏からのゲスト投稿で

エンジニアがもっと働きやすい環境に!エンジニアに嬉しい福利厚生と導入企業まとめ

IT関連企業を筆頭に、今やどこの企業の求人を見ても「エンジニア募集中」の文字。優秀なエンジニアを獲得

node.js における stream の歴史とそれぞれの問題点

node.js における stream の歴史とそれぞれの問題点

内容 前史(stream API以前のstream) stream1 stream全盛期、ユーザラン

1家に1人!旦那がエンジニアだと便利な5つのこと

よく便利なものに対して「1家に1台」とか言いますよね。 まさしくエンジニアはその「1家に1人」の便利

Dockerコンテナとイメージの仕組みを視覚化してみた

この記事は、Docker 102レベルを意図して書かれている。Dockerが何か分からない、または仮

広告あるある 〜第一弾〜

by Klearchos Kapoutsis こんにちは、今回はネット広告について、あるあるを書きま

フルスタックエンジニアを目指すには。

フルスタックエンジニアを目指すには。

by Shunsuke Kobayashi 習うより慣れろと言うことわざがありますが、 エンジニアで

「AIって何?」なんて今さら聞けない!最低限抑えておきたいこれからの技術トレンド4つ(最新版)

【関連記事】 ❏これから必ず伸びる!最低限抑えておきたい技術トレンド3つ(2015年度版) ❏海外エ

待ち遠しい次の祝日がコマンドラインでわかる!‐cal‐ 端末にカレンダーを表示しよう

待ち遠しい次の祝日がコマンドラインでわかる!‐cal‐ 端末にカレンダーを表示しよう

これは“コマンドライン・マンデー”シリーズの最初の投稿です。このシリーズでは、毎週月曜日に使えるコマ

なぜあなたのインターネットは遅いのか?問題を切り分けて特定するトラブルシューティング

はじめに 家庭、コーヒーショップ、またはオフィスでの作業中に「インターネット(インフラ)にまつわる問