「通常」（CPUコア（またはその他）の機能として）のコンテキストスイッチはいくつありますか？

こんにちはLinux / UNIX Overlords、

Linuxサーバーでコンテキストスイッチが（プロセッサコアごとに）通常いくつあるかについての経験則はありますか？

ここで私の大学はそれを育て、彼は8コアマシンで16Kを見ていx86_64ます。

ここ数日間のsarfaceの統計をいくつか紹介します...

代替テキストhttp://src.autonomy.net.au/imagebin/81895e338fae67d3d205c09db44a81e6-Picture_10.png

そして、プロセス作成の統計を見るために、同じグラフの対数ビューがあります...

代替テキストhttp://src.autonomy.net.au/imagebin/7481f7e52bead4effc90248fc23c72fe-Picture_11.png

そして、8つのコアは退屈しています...

代替テキストhttp://src.autonomy.net.au/imagebin/0e94326652e977fd74edcd840f94200f-Picture_12.png

CS vs IOwait（x10000スケール）

代替テキストhttp://src.autonomy.net.au/imagebin/a52a2a8a120394849c0da4045933e306-Picture_13.png

誰もが尋ねる場合のより無駄な情報..

• サーバーが動作するストレージは、FC経由の0.5TB SANです
• 8GBのRAMがあり、ほとんどがキャッシュです-スワッピングはありません。

これは、実行するアプリケーションのタイプに大きく依存します。非常にトリガーに適したWRT syscallであるアプリケーションがある場合、大量のコンテキストスイッチングが予想されます。ほとんどのアプリケーションがアイドル状態であり、ソケットで何かが発生したときにのみウェイクアップする場合、低いコンテキストスイッチレートが期待できます。

システムコール

システムコールは、それ自体の性質によりコンテキストスイッチを引き起こします。プロセスがシステムコールを実行すると、基本的にはカーネルに現在の時点とメモリから処理を引き継ぐように指示し、プロセスが実行する権限のない処理を行い、処理が完了したら同じ場所に戻ります。

Linuxのwrite（2）システムコールの定義を見ると、これは非常に明確になります。

名
       書き込み-ファイル記述子への書き込み

あらすじ
       ＃含める 

       ssize_t write（int fd、const void * buf、size_t count）;

説明
       write（）は、bufが指すバッファーからファイルにcountバイトまで書き込みます
       ファイル記述子fdによって参照されます。[..]

戻り値
       成功すると、書き込まれたバイト数が返されます（ゼロは
       何も書かれていなかった）。エラーの場合、-1が返され、errnoが設定されます
       適切に。
       [..]

これは基本的に、カーネルにプロセスから操作を引き継ぎ、現在のプロセスのファイル記述子countによって示されるメモリアドレスから開始してバイトまで移動し、プロセスに戻り、どのように処理したかを伝えます。*buffd

これを示す良い例は、Valve Sourceベースのゲーム専用ゲームサーバーhldsです。http://nopaste.narf.at/f1b22dbc9は、プレイヤーがいないゲームサーバーの単一インスタンスによって実行される1秒のシステムコールを示しています。このプロセスは、Xeon X3220（2.4Ghz）で約3％のCPU時間を必要としますが、これがどれほど高価なのかを感じてもらうためです。

マルチタスク

コンテキストスイッチングのもう1つのソースは、syscallを実行しないが、他のプロセスのためのスペースを確保するために特定のCPUから移動する必要があるプロセスです。

これを視覚化する良い方法はcpuburnです。cpuburnはシステムコール自体を実行せず、自身のメモリを反復処理するだけなので、コンテキストの切り替えは発生しません。

アイドルマシンを取得し、vmstatを起動してから、システムに搭載されているすべてのCPUコアに対してburnMMX（またはcpuburnパッケージとは異なるテスト）を実行します。それまでにシステムを完全に使用する必要がありますが、コンテキスト切り替えはほとんどありません。その後、さらにいくつかのプロセスを開始してみてください。プロセスがCPUコアを巡って競合し始めると、コンテキストスイッチング率が増加することがわかります。切り替えの量は、プロセス/コア比とカーネルのマルチタスク解像度によって異なります。

参考文献

linfo.orgには、コンテキストスイッチとシステムコールについての優れた記事があります。ウィキペディアには、一般的な情報と、システムコールに関する素晴らしいリンク集があります。

私の適度にロードされたWebサーバーは、2番目に多くのピーク時に数千のピークで100〜150のスイッチに座っています。

コンテキスト切り替え率が高いこと自体は問題ではありませんが、より重要な問題への道を示す場合があります。

編集：コンテキストスイッチは症状であり、原因ではありません。サーバーで何を実行しようとしていますか？マルチプロセッサマシンを使用している場合は、メインサーバープロセスのCPUアフィニティを設定してみてください。

または、Xを実行している場合は、コンソールモードにドロップダウンしてみてください。

もう一度編集：1秒あたり16k csで、各CPUは1ミリ秒あたり2つのスイッチを平均化しています。これは、通常のタイムスライスの半分から6分の1です。彼は多くのIOバウンドスレッドを実行できますか？

ポストグラフの再編集：確かにIOバウンドに見えます。コンテキストの切り替えが多い場合、システムはほとんどの時間をSYSに費やしていますか？

もう一度編集します。最後のグラフのiowaitとシステムが高い-ユーザースペースを完全に覆います。IOの問題があります。
どのFCカードを使用していますか？

編集：うーん。デッドタイム中にbonnie ++またはdbenchを使用してSANアクセスでベンチマークを実行する可能性はありますか？それらが同様の結果をもたらすかどうかに興味があります。

編集：週末にこれについて考えていたし、ボニーが「一度に1バイトを書き込む」パスを行っているときに同様の使用パターンを見てきました。書き込みごとに個別のsyscallが必要になるため、大量の切り替えが行われていることを説明できます。

私は、システム状態のCPU占有率を心配する傾向があります。10％に近い場合は、OSがコンテキストの切り替えに多くの時間を費やしていることを意味します。一部のプロセスを別のマシンに移動するのは非常に遅くなりますが、そうする価値があります。

このようなことが、サーバーのパフォーマンスベースラインを維持しようとする理由です。そうすることで、突然気づいたことを過去に記録したことと比較できます。

とは言っても、サーバーを実行しています（主にOracleサーバーはそれほど忙しくありません）。私のサーバーの場合、それは普通のことです。他の人のサーバーの場合は、低すぎるか高すぎるかもしれません。

データをどこまで戻すことができますか？

どのようなCPU情報を提供できますか？

経験則はありません。コンテキストスイッチは、あるスレッドの処理から別のスレッドへのCPUの移動にすぎません。多くのプロセス（またはいくつかの高度にスレッド化されたプロセス）を実行すると、より多くのスイッチが表示されます。幸いなことに、コンテキストスイッチがいくつあるかを心配する必要はありません。コストは小さく、多かれ少なかれ避けられません。