サーバーで何が起こっているかを理解する方法

アレクサンダー・クリザノフスキー（ krizhanovsky 、 NatSys Lab。 ）

この写真は長い間Web上で実行されてきました。少なくともFacebookでよく見かけました。







Googleで入力したところ、それを作成した人がLinuxのパフォーマンスの最適化に取り組んでいることがわかりました。彼には素晴らしいブログがあります。 この画像が存在するプレゼンテーションだけでなく、約3つのプレゼンテーションがあり、他のドキュメントもあります。 このブログに行くことをお勧めします。この写真にリストされているすべてのユーティリティについてよく説明しています。 再話したくなかったので、プレゼンテーションへのリンク-http://www.brendangregg.com/linuxperf.htmlを提供します 。



一方、彼はプレゼンテーションに非常に圧縮されたストリームを持ち、これらの各ユーティリティについて1時間のプレゼンテーションがあります-実際には、man'eで見つけることができるのと同じこと、または単にそれぞれの名前を入力するだけですGoogleでこれらのユーティリティの。 ボトルネックを見つけて、何が起こっているのかを理解する方法について、いくつか例を挙げたいと思いました。



Greggは、ボトルネックの見つけ方の議論から始まる方法論、5つの「なぜ」質問などを提供します。 方法論を使用したことはありません。ただ見て、何かをして、何ができるかを見せたいです。







残念ながら、プレゼンテーションを準備していたとき、ソフトウェア、ベンチマーク、つまり スクリプト全体を繰り返すことができませんでした。 持っていたログ、チャット、ラップトップ、仮想マシンでいくつかのスクリプトを再現しようとしたので、いくつかの数字が疑わしい場合は、本当に疑わしいので、少し見てみましょう。指。 数字の順序とその見方、認識方法は、私たちにとってより重要です。



最初の主な例は、カスタムアプリケーションがあり、nginxモジュール、非常に重いモジュールがありましたが、アプリケーションロジックは考慮しません。 人々は多くの接続を望んでいたという問題がありましたが、多くの接続がうまくいかず、すべてがそこで止まりました。 入力トラフィックは1秒あたり約250 MBで、このようなかなり控えめなトラフィックでは多くの並列接続が行われました。 リソースを完全に消費しましたが、何も起こりませんでした。 新しい接続、新しい要求は単に破棄されました。



見ました。 最初に行うことは、netstatを確認し、grepを実行し、別のgrepを実行することです。 netstatには2万を超える接続があり、これらのストリームがそこにあります。 パフォーマンスの問題が発生すると、システムが非常に悪く感じることは明らかです。 そして、netstatを実行すると、grepで非常に長時間ハングするため、可能であれば、procを使用することをお勧めします。実際には常に存在し、パイプでは機能しないがすぐに読み取るawkスクリプトを記述します。 procの文字列がそれを解析し、カウントした結果を提供します。 作業が少し速くなり、快適になります。



何が起こっているのかを理解するために2番目に行うことは、単に着信パケットをカウントすることです。 ここでは複雑なものは使用しませんでした。パケットカウンター、バイトカウンターを使用します。 実際、これらの数値はどのように取得されますか？変動を平準化するために10秒間スリープし、一方から他方を減算して10で除算します。







次に、Top normalを実行します。 Topにはある種の写真があります。一般に、犯罪者はいません。 nginxはプロセッサの100％を消費しません。平均も基本的に正常です。 システム時間が33％で、ソフトウェア割り込み（si-ソフトウェア割り込み）-52％であることが疑われます。 つまり 実際、nginxはほとんど役に立ちませんが、OSカーネルには多くのことができます。 また、2つのksoftirqdスレッドがあることもわかります。これを仮想マシン内で再現しましたが、コアは2つしかありませんでした。 2つのネットワークハンドラスレッドがトップになりました。







上部に便利なボタンがあります-「1」を押す必要があります。 プロセッサーの要約統計は表示されませんが、プロセッサーごとに個別に表示されます。 ここでは、一般的に、プロセッサが均等に動作する、良い画像を見ることができます。 1つのプロセッサが100％ねじを外され、他のプロセッサが横たわっている場合、明らかに負荷分散に問題があります。 パケットが主に1つのコア、1つの割り込みに送られる場合、残りには残りがあります。 ここで私たちは良い分布がありました。







私はそれを使うのが大好きです。 これは良くありません、それは農民の方法ですが、一般的にGDBは非常に強力なインターフェースを提供します。 ループ内のすべてのnginxプロセスでGDBのスクリプトを設定し、それらで何が行われるかを確認できます。 ここでは、スタックの一番上、つまり最初と2番目の関数を見ていきますが、原則として、より興味深いことを行うことができます。バックトレースを収集できるだけでなく、変数を出力することもできます。 これは、サーバーの内部をリアルタイムで確認し、サーバーで何が行われているか、そのステータスを確認できるほど強力なメカニズムですが、あまり停止しないでください。 このスクリプトは、実際にはスローダウンし、nginxが悪化していることは明らかですが、一般的には動作し、リアルタイムで実行できます。



このスクリプトを数回実行すると、一般に、複数のプロセス、複数のスレッドだけでも、ほとんどの場合、一部のスレッドが1つまたは2つの機能に時間を費やしていることがわかります。これが単なるボトルネックです。 関心のあるスレッドまたはプロセスが1つしかない場合は、それを数回実行するだけで、これが非常に単純なサンプリングであることを理解できます。



この場合、私たちはここで単にエポールを見るとはまだ言っていません。 Epollはあまりおもしろくはありません。ユーザー空間のコードを見れば、もっとおもしろいです。 開始した場合、ユーザースペースコードがあり、処理した正規表現があり、ボトルネックがありました。



次は、問題がnginxではなくシステムの問題であることがわかったため、システムに進みます。 OSがどのように感じるかを確認します。 つまり 現時点では、すでに検索領域を分割し、分割しており、OSで既に検索しています。







便利なperf topユーティリティがあります。これはカーネルトレーサーであり、システム内のすべてのプロセス、特定のプロセッサ、特定のプロセス、そのcall_traceを表示できます。 ここでは、ほとんどの時間がnf_conntrackで費やされていることがわかります。 一般的に、それはあまり明確ではありません。 最後の2行がnginxであることがわかります。 nginxはもはやボトルネックではないことがわかっているため、アプリケーションコードには何らかの種類があることを理解しています。 私たちが探しているのは、OSの内部を探していることです。最初の3つの呼び出しに興味があります。



最初の nf_ct_tuple_equalが何であるかを見つけるには、カーネルソースを手元に置いておくと便利です。 私は誰もがそれを理解する必要があるという事実については話していませんが、カーネル内でgrepを実行するだけです-私がしたこと-あなたは非常に簡単に理解することができます。または、perfに表示される呼び出しをGoogleに入力することができます。 最初はわかりにくいかもしれませんが、どのようなサブシステムであるかをすぐに見つけることができます。 このシステムコールが何をするのか、このカーネル関数を正確に知る必要はありません。カーネルの速度が低下するサブシステムの種類を理解するだけです。



grepを実行するだけです。 ディレクトリ内で一般的な再帰grepを作成し、Kconfigが存在する場所を見つけ、そこに人間の説明があります-カーネル構成で得られるもの、このサブシステムが行うこと。 次にGoogleにアクセスし、conntrackとは何かを見て、conntrackがシステムの速度を低下させている多くのメッセージを確認します。これらは、特にhtpサーバーの場合、着信トラフィックには意味がありません。



すべてがすべてのデータ、すべてのデータが一致することを確認するために、conntrackが放牧している接続の数を出力します。そこには、確立された接続の数とほぼ同じ数が表示されます。 LinuxのConnectrackは、接続を監視するファイアウォールサブシステムです。 FTPの鮮明な例では、接続が1つある場合にポートが与えられ、ファイアウォールは最初と2番目の両方の接続を取得して接続する必要があります。 そして、このサブシステムには、すべての接続と一致し始めるかなり遅い機能があり、アイドル状態で動作するだけで、何もしないため、オフにすることができます。



最初のボトルネックを見つけました。次を見てみましょう。







Intel_idle 正直なところ、Intelカードからだと思ったのは初めてです。 繰り返しますが、カーネル内でgrepを実行します。 Kconfigでは、常にオンになっているため、すでに何もありませんが、Intel開発者はソース内で適切なコメントを作成するように注意しており、プロセッサが無駄になる時間はスレッド内で費やしています。 このスレッドは優れています。つまり、プロセッサがしばらくアイドル状態であり、私たちはそれで何もしていません。







次のポイント。 再度grepを実行し、。/ block / cfq-ioスケジューラーがあることを確認し、I / Oスケジューラーを処理していることを理解しています。 だから、おそらく、nginxは何かを入力/出力しています。 同時に、ブロックIO-これは、ネットワーク部分ではなくファイルシステムがあることを意味します。 ネットワーク部分はネットにあります。



これが発生した場合、I / O統計を確認したいので、iostatがこれを支援します。 大量の記録があり、ディスクが何らかの形で15〜20％使用されていることがわかります。 それほど多くはありませんが、時間が無駄になります。



さらに、perf topを見ると、実際にOSがI / Oで行っていることがわかりました。 これは、nginxがこれを行うことを意味するものではなく、何かを出力するkswapdである可能性があり、cronに上がって何らかのデータベース更新を開始するUpdatedbデーモンである可能性があります。更新など 良い意味で、システムのI / Oに負荷がかかっていることがわかった場合、誰がこれを行っているかを見るのはまだ良いことです。







そして、iotopがあります-通常のtop'aの類似物ですが、入出力用です。 このような入出力を生成するユーザーを示しています。 nginxが表示されます。







次に行うことは、nginxがI / Oで行うことを確認することです。 OSとアプリケーションプロセスの間のインターフェイスにあるstraceアプリケーションユーティリティがあります。 すべてのシステムコールにフックを出力します。 書き込みと書き込みを設定する必要があると考えました。 わざと何もしていませんでした。 実際、多くのシステムコールはありません。 ここでそれは正しかった-「-e write、write w」と、おそらくそれだけです。 つまり ファイルI / Oの速度が低下していることがわかっている場合は、かなり少ない数のシステムコールに関心があります。



2番目のオプション。 ここで私は幸運になった、私は明確な結論を持っている。 本当にたくさんのwrite'ovがありました。 実際には、非常に悪い状況に陥る可能性があります。システムコールのごくわずかなものを見ただけで、エポールが発生し、ソケットから何らかの読み取りが行われ、書き込みが発生することがあり、一般に、それが何であるかを理解するのは困難です。



straceを実行することもできます。 straceをファイルに入れてから、システムコールの統計を作成するスクリプトでこのファイルを処理します。 Topにあるシステムコールを理解しているため、システムコールのTopでレコードのシステムコールを探しています。これは書き込みになります。 書き込みによって、書き込みの最初の引数としてファイル記述子8があることがわかります。



lsofを使用するのは正しいことですが、使用方法はまだ学習していません。docfsを使用しています。 fdディレクトリに移動し、8番目の記述子の内容を確認します。 このaccess.logは驚くことではありません。







最後のシナリオは、トップが沈黙している場合、良い数値を示している場合、一般的にはシステム内のすべてが正常であるが、それが良くないことを知っています。



そのような例。 私はちょうどベンチマークを取りました-これは、ミューテックスで同期キューをロードするベンチマークであり、Topの言うことを見ました。 Topによると、アイドル状態は非常に大きく、CPUごとの統計情報を表示しない場合、プロセッサ使用率は約130％になりますが、400になるはずです。 統計はすべて良好であることがわかりますが、そのイデオロギーにより、ベンチマークはすべてのリソースを完全に利用すべきであり、そうではありません。



何が起こるか見てみましょう。







ここで再びstraceを実行しますが、既に-pと-cを使用して呼び出しています。 -sを使用すると、システムコールに関する統計を収集できます。



なぜnginxに対してこれを行わなかったのか、何らかのスクリプトを使用してstraceからの出力を解析する必要があると言ったのはなぜですか？ 事実、straceは実行するプログラムの最後にこれらの統計を生成し、トレースします。nginxを実行していて、それを中断したくない場合は、これらの統計を取得しないため、統計を自分で収集する必要があります。



ここで、straceは、トレース、よく呼び出すシステムコール、これらのシステムコール内の時間を示しており、futexがあることがわかります。 man futexと入力すると、これがユーザー空間の同期に使用されるOCメカニズムであり、これらがmutexであることがわかります。 そして、pathReadロック、条件変数はこの単一のfutex呼び出しのみを使用します-これは、pathRead同期に問題があることを意味します。



一般的に、I / Oが良好で、プロセッサは良好で、すべてが正常で、メモリは良好であるような画像が表示されても、RPSの数に達していないため、原則としてロック競合、この数字はわずか130％です-ランダムではありません。 つまり ロックの競合中に、1つのロックを求めて4つのプロセッサを使用している場合、一度に1つのプロセッサしか使用できません。 つまり、実際には、4つのプロセッサのいずれかを取得します。 そして、プランナーの追加費用と100％を少し超えるものを犠牲にしてのみ、30％を追加しますが、これは競合の性質です。

連絡先

» Ak@natsys-lab.com

「Abrander onHabré： クリザノフスキー

» NatSys Labブログ

このレポートは、負荷の高いシステムHighLoad ++ Juniorの開発者のトレーニング会議で行われた最高のプレゼンテーションの1つです。



また、これらの資料の一部は、高負荷システムHighLoadの開発に関するオンライントレーニングコースで使用されますガイドは、特別に選択された文字、記事、資料、ビデオのチェーンです。 私たちの教科書にはすでに30以上のユニークな資料があります。 接続してください！



さて、主なニュースは、 HighLoad ++ Juniorを含む8つの会議を含む春祭り「 Russian Internet Technologies 」の準備を開始したことです。 アレクサンドラは間違いなく再びスピーカーを呼び出します