「CPUコア（またはその他）の機能として」正常なコンテキストスイッチの数はいくつですか？
Linux/UNIX Overlords様
Linuxサーバーで（プロセッサーコアあたり）コンテキストスイッチの数がNormalであるという経験則はありますか？
ここの私の大学はそれを育てました、そして、彼は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
誰かが尋ねた場合に備えて、さらに役に立たない情報。
- サーバーが動作するストレージは0.5TB SAN FC経由
- 8GBのRAMがあり、ほとんどがキャッシュです-スワッピングはありません。
これは、実行するアプリケーションのタイプに大きく依存します。非常にトリガーに満足するWRT syscallであるアプリケーションがある場合、大量のコンテキスト切り替えが発生することが予想されます。ほとんどのアプリケーションがアイドル状態にあり、ソケットで何かが発生したときにのみウェイクアップする場合、コンテキストスイッチレートが低いことが予想されます。
システムコール
システムコールは、独自の性質によりコンテキストスイッチを引き起こします。プロセスがシステムコールを実行すると、基本的には、カーネルに現在の時点とプロセスから引き継ぐように指示し、プロセスが実行する特権がないものを実行し、完了したら同じ場所に戻ります。
Linuxからのwrite（2）syscallの定義を見ると、これは非常に明確になります。
NAME write-ファイル記述子に書き込みます 構文 #include ssize_t write（int fd、const void * buf、size_t count）; DESCRIPTION write（）は、bufが指すバッファから参照されるファイル に最大countバイトを書き込みますファイル記述子fd。 [..] 戻り値 成功すると、書き込まれたバイト数が返されます（ゼロは 何も書き込まれなかったことを示します）。エラーの場合は-1が返され、errnoが適切に設定されます。 [..]
これは基本的に、プロセスに操作を引き継ぐようにカーネルに指示し、*bufが指すメモリアドレスから現在のプロセスのファイル記述子countまで、fdバイトまで移動します。その後、プロセスに戻り、それがどのように行われたかを彼に伝えます。
これを示す良い例は、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には コンテキストスイッチ と システムコール についての素敵な記事があります。 Wikipedia には、一般的な情報とシステムコールに関するニースリンクコレクションがあります。
私の適度にロードされたWebサーバーは、ほとんどの場合2番目に100〜150台のスイッチにあり、ピークは数千台に達します。
高いコンテキストスイッチ率自体は問題ではありませんが、より重大な問題への道を示している可能性があります。
編集：コンテキストスイッチは症状であり、原因ではありません。サーバーで何を実行しようとしていますか？マルチプロセッサマシンを使用している場合は、メインサーバープロセスのCPUアフィニティを設定してみてください。
または、Xを実行している場合は、コンソールモードにドロップダウンしてみてください。
再度編集：1秒あたり16k csで、各CPUはミリ秒あたり2つのスイッチを平均化します。これは、通常のタイムスライスの半分から6分の1です。彼は多くのIOバインドされたスレッドを実行していますか？
投稿グラフを再度編集：確かに見えるIOバインドされています。コンテキストの切り替えが高い場合、システムはほとんどの時間をSYSで費やしていますか？
もう一度編集してください：その最後のグラフのiowaitとシステムが高い-ユーザー空間を完全に覆い隠しています。 IO問題があります。
どのFCカードを使用していますか？
編集：うーん。デッドタイム中にSAN bonnie ++またはdbenchでアクセスしていくつかのベンチマークを取得する可能性はありますか？同様の結果が得られるかどうかを確認します。
編集：週末にこれについて考えていて、ボニーが「一度に1バイトずつ書き込む」パスを行っているときに、同様の使用パターンが見られました。書き込みごとに個別のsyscallが必要になるため、大量の切り替えが行われていることを説明できます。
このようなことが、サーバーのパフォーマンスベースラインを維持する必要がある理由です。これにより、突然気づいたことと過去に記録したことを比較できます。
とは言っても、私はサーバーを実行しています（主に非常にビジーなOracleサーバーではありません）。私のサーバーの場合、それは正常です。他の人のサーバーの場合は、低すぎるか高すぎる可能性があります。
データをどこまでさかのぼることができますか？
どのようなCPU情報を提供できますか？
私は、システム状態のCPU使用率について心配する傾向があります。 10％以上に近い場合は、コンテキストの切り替えにOSが時間を費やしすぎていることを意味します。一部のプロセスを別のマシンに移動するのはかなり遅いですが、それに値するものです。
経験則はありません。コンテキストスイッチは、CPUがあるスレッドの処理から別のスレッドの処理に移行するだけです。多くのプロセス（またはいくつかの高度にスレッド化されたプロセス）を実行すると、より多くのスイッチが表示されます。幸い、コンテキストスイッチの数を気にする必要はありません。コストは小さく、多かれ少なかれ不可避です。