サーバーと仮想マシン

ホスティングにおけるCPUハイパースレッディング：利点とリスク

ホスティングにおけるCPUのハイパースレッディングは、1つの物理コアが2つのコアを処理できるため、スループットを向上させる。 論理コア とアイドル時間を埋める。同時に、サイドチャネル攻撃やパフォーマンス低下などのリスクも警告している。 シングルスレッド-ワークロード.

中心点

パフォーマンススレッド数が多いほどスループットが向上するが、2倍にはならない スピード.
セキュリティSMTはリソースを共有する。 サイドチャンネル.
チューニング測定プロファイル、ワークロードごとのハイパースレッディング 有効化/無効化.
仮想化vCPUの割り当てとスケジューリングの特徴 安定性.
コストコアあたりの利用率を向上させる ハードウェア.

ホスティングにおけるCPUハイパースレッディングとは？

ハイパースレッディングとは 同時マルチスレッド, 物理コアが2つのスレッドを同時にスケジューリングするものである。プロセッサは、この目的のために実行ユニットとキャッシュを共有する。 待ち時間 をメモリやパイプラインスロットに割り当てることができる。ホスティングでは、多くの小さなリクエストが並列に実行され、うまく分散できる場合に役立ちます。Intelは、作業負荷に応じて最大30パーセントの増加を見込んでおり、これは高度に並列化されたサーバーサービスでは現実的であると見ている[1][3]。私のアドバイスは、ハイパースレッディングは追加的な 物理コア.

ハイパースレッディングによるリクエストの高速化

Apache、Nginx、Node などのウェブサーバスタックでは、多くの短いタスクが カーン 非常に効率的です。ハイパースレッディングは、1つのスレッドがI/Oやメモリーを待っている間隙を利用し、2番目のスレッドを並列に実行させる。 スレッド を計算する。これにより、TLS、静的ファイルサービング、動的コードが混在するワークロードのレイテンシが短縮される。同じようなリクエストが何ダースも保留され、スケジューラがそれらを公平に分配すると、すぐに顕著な効果が見られる。キャッシュとマイクロアーキテクチャーについてもっと詳しく知りたい方は、以下のサイトで背景を知ることができます。 CPUアーキテクチャとキャッシュ, これは、ホスティングシナリオでの効果をうまく説明している。.

リスクと典型的な障害

すべてのソフトウェアにメリットがあるわけではない。 論理コア はパイプライン、キャッシュ、バンド幅を共有する。そして シングルスレッド-コードでは、2番目のスレッドがリソースを奪い、応答時間を長くする可能性がある。コアのスレッドがより多くのステートを共有するため、SpectreやMeltdownのようなサイドチャネル攻撃が有利になります[1]。OpenBSDでは、まさにこの理由からSMTをオフにしており、懸念の大きさを示している[1]。エネルギー要件も増加する可能性があり、測定では全負荷時に最大46%まで増加するケースもあり、データセンターのコストに影響する[1]。.

ハイパースレッディングとリアルコアの比較

私はいつもハイパースレッディングと直接比較している。 物理コア, なぜなら、そうでなければ期待値が滑ってしまうからだ。つの論理的なスレッドは、本格的なコア, 利用率のギャップを滑らかにするだけだ。ビルドジョブ、インメモリデータベース、圧縮などでは、多くの場合、実コアが明らかに有利です。一方、共有ホスティング環境では、論理コアの方が密度が高く、レイテンシも許容できるため有利です。以下の図は、違いを構造化し、決断を早めるのに役立ちます[1][7]。.

アスペクト	ハイパースレッディング（論理コア）	物理コア
パフォーマンス	マルチスレッドで最大～30%プラス[1]。	コアあたりのフルリソース
コスト	既存ハードウェアの有効活用	より多くのシリコン、より高い価格
リスク	サイドチャンネル、ロードコンフリクト	漏れの可能性が低い
用途	多くの小さな並列リクエスト	CPU負荷の高いシングルスレッド

仮想化、vCPU割り当てとオーバーコミット

VMでは、ハイパーバイザーのスケジューラー、論理的なコアを物理コアにマッピングします。あまり多くのvCPUをバインドしすぎると、スレッドごとの待ち時間が長くなり、約束の パフォーマンス が崩壊します。そのため、高密度に稼働しているホストではオーバーコミットを制限し、NUMAとの連携に注意を払っています。私はVMの準備完了時間を監視し、レイテンシーが脱線する前にvCPUクォータを調整する。典型的な落とし穴を理解したければ、以下を参照されたい。 CPUオーバーコミットメントそして、スケジューラーにおける不必要な混雑を避ける。.

サーバーのチューニング：BIOS、スケジューラー、制限

私はBIOSから始めて、ハイパースレッディングのオン・オフを切り替える。 ワークロード をテストします。Linuxでは lscpu, コアあたりいくつのスレッドがアクティブになっているかを確認し、htopでその分布を検証する。ボトルネックが発生した場合は、プロセスの優先順位やI/Oクラスを設定し、ウェブサーバーのアグレッシブなワーカープールを制限している。アフィニティは控えめに使い、スレッドをバインドするか、スケジューラに自由裁量を与えるかを意識的に決めている。これについては、以下のプロジェクトで詳しく書いている。 CPUピン止めこれは、ホスティング環境では多くの人が思っているほど価値がない。.

OSスケジューラ、コアスケジューリング、IRQアフィニティ

Linuxでは、CFSスケジューラが中心的な役割を果たしている。CFSスケジューラは、公平な分散を試みますが、常に 共有リソース コアの。コアスケジューリングを使えば、信頼できるスレッドだけに同じ物理コアを共有させることができる。レイテンシ・パスのために、重要なIRQ（NIC割り込みなど）を選択された カーン そして、RX/TXキューが同じSMT兄弟で衝突しないようにRPS/XPSを調整する。バッチやオフパスのタスクにはcpuset/group isolationを使い、クリティカルなコアをフリーにしておく。非常に厳しいレイテンシ・ターゲットがある場合は、nohz_full、isolcpus、固定CPUクォータを組み合わせて、定期的なジョブからの干渉を最小限に抑えます。.

荷重下での安全性と断熱性

SMTによるリスクに対しては、マイクロコードとカーネルによる緩和策を使う。 オーバーヘッド つまり。私はコンテナで隔離を強化する。 UID と制限的な機能を持つ。マルチテナント環境では、機密性の高いワークロードについては、コアスケジューリングとハード分離プールを検討する。クリティカルな暗号ジョブは、排他的なコアやホストにスケジューリングし、同じ物理コアに異なるスレッドが存在しないようにする。さらに、ファームウェア、ハイパーバイザー、オペレーティングシステムを常に最新の状態に保ち、リークを迅速に軽減します[1][5]。.

ワークロードマトリックス：いつHTを作動させるか？

多くのウェブサーバーでハイパースレッディングを有効にしている。同時リクエスト、APIゲートウェイ、プロキシ層、および混合CMSスタック。読み込みが多く、書き込みが中程度のデータベースの場合、SMTは通常、一貫した利得を提供する。CPU負荷の高い圧縮、暗号化シグネチャ、ビルド・パイプラインでは、読み込みごとのレイテンシを一定にするため、HTをオフにすることが多い。コアをセキュアにします。トレーディングゲートウェイやテレメトリーインジェストなど、レイテンシーに敏感なワークロードについては、本番負荷パターンで両方のモードをテストしている。厳格なSLOを持つシステムの場合は、専用の物理コアを計画し、バックグラウンドタスクをより厳密に制御します。.

ハイブリッド・アーキテクチャと未来

新しい世代のインテルは、PコアとEコアを組み合わせ、ハイパースレッディングを以下のように縮小している。 Pコア 一部のモデルでは、より効率的なEコアを搭載している[1]。ホスティングでは、これによってワット・パー・リクエスト比が下がり、並列処理速度が向上します。定員同じエネルギー予算で。AMDはSMTに固執しているが、ARMはbig.LITTLEでヘテロジニアス・コアで同様の目標を追求している。したがって、私はスレッド密度、ワットあたりの効率、セキュリティ機能によって将来のホストを評価する。決め手となるのは、スケジューラがPコアとEコアにどのようにスレッドを分散させるか、そしてどのQoSメカニズムが使えるかである[4]。.

モニタリングとキャパシティ・プランニング

CPUの使用率を定期的に測定している。コア, スケジューラの実行キュー長、コンテキストスイッチ、VMのスティール/レディ時間。p95/p99レイテンシ、エラー率、飽和時間などのメトリクスを使用する。 労働者プール 私はSMTの利点や欠点を認識することができる。Prometheus、Zabbix、eBPF-Exporter、Flamegraphsのようなツールは、数値がなければ見えないホットスポットを示してくれる。私は両方のモードでプロファイルを文書化し、後のアップグレードが健全であるようにしている。これに基づいて、私はリザーブを計画し、レイテンシーが顧客に打撃を与える前に新しいホストを決定します。.

ベンチマークの方法論と測定の誤りを避ける

私は合成テストと現実的なテストを分けている。合成テスト（例：圧縮、暗号化、JSONシリアライゼーション）は、2つのテストがどのように行われるかを明確に示す。 論理コア ポート、キャッシュ、メモリ帯域幅の競合。現実的な負荷がリクエストフロー全体を通して実行されます：TLSハンドシェイク、キャッシュヒット/ミス、データベース、テンプレート、ロギング。代表的な同時実行を選び、キャッシュをウォームアップし、数分間にわたって安定性を測定する。p50/p95/p99、エラー、リトライ、テールレイテンシの不規則性を記録します。また、IPC/CPIとL1/L2ミス率も追跡している。「メモリバウンド」の割合が増えれば、HTはレイテンシをまたいでスレッドをうまくスケジューリングできる。同一のシードと分離されたテストウィンドウで実行を繰り返し、不要なタイマーを停止し、ターボドリフトが結果を歪めないようにクロックと温度の条件を一定にします。.

コンテナとオーケストレーションの実践

コンテナでは、CPUリクエスト/リミットとCFSクォータに注意している。あまりにアグレッシブなクォータは、スロットリングのピークを発生させる。兄弟が遅くなる。私は、レイテンシが重要なポッドには専用のCPUセットを使い、残りのSMT兄弟でバッチワークロードを実行している。スタティック」モードのCPUマネージャーは、コアを排他的に割り当てるのに役立つ。水平方向では、スケジューラーがより細かく分散できるように、少数の大きなレプリカよりも、より多くの小さなレプリカをスケールさせることを好む。ネットワーク経路については、RSSキューを異なる カーン また、IRQが同じ物理コアを占有しないように、アプリのスレッドからイングレス/イグレスを分離しています。ストレージ側では、ロックの衝突を避けるために、NVMeの投入／完了キューを別々のコアに配置しています。.

言語、ランタイム、フレームワーク

JVMワークロードは、GCスレッドとアプリ・スレッドが物理コアと論理コアできれいに補完し合うと、しばしば恩恵を受ける。私は予測可能な休止時間を持つGCを使用し、HTが休止時間を短縮するか悪化させるかを観察する。Goでは、GOMAXPROCSを調整する。HTでは、すべてのゴルーチンがCPUバインドされない限り、高い値が有用である。Node.jsは、イベントループのI/O並列性と、CPU負荷の高いタスクのワーカースレッドに依存している。GILを使ったPythonは、CPUバウンドのコードでは恩恵が少ないが、I/Oヘビーなマルチプロセッシングや非同期ワークロードでは、オーバーラップ効果によりHTが活用される。C/C++のサービスでは、スレッドプールを意識的に制御している。ワーカーが多すぎると先取りやキャッシュ退避が発生し、少なすぎるとスループットが後回しになる。.

NUMA、メモリ帯域幅、I/O

NUMAの方がHTよりも決定的であることが多い。私はワークロードを NUMA-リモートメモリアクセスがレイテンシを超えないようにするためです。ソケットがすでに限界に達している場合、SMTスレッドを追加してもほとんどメリットはなく、L3とメモリコントローラへの負担を増やすだけだ。データ集約的なサービス（キャッシュ、アナリティクス）については、ソケットを介して水平方向に拡張し、クロスソケット・トラフィックを減らします。I/Oについては、非同期キュー、バッチサイズ、合体を使って、HTスレッドが常に同じロックを待つことがないようにしています。.

ターボ、エネルギー政策、サーマル

SMTは利用率を高め、廃熱を増加させる。私はパッケージの電力、温度、クロックレートをモニターしている。全負荷時には スレッド ターボは、アクティブなスレッドが1つだけの場合よりも低くなることが多い。エネルギーポリシー（P-/E-States、EPP）では、短いバーストと持続的なスループットのどちらを優先するかを定義する。高密度のラックでは、冷却のための予備を計画し、SMT負荷が恒久的に高くなり、長期間にわたって周波数がスロットリングされるのを避ける。その結果、私はリクエストあたりのワット数を評価する。SMTがここで改善された場合、私は統合の利益に対する追加コストを計算し、熱が制限要因になるとすぐに対応する[1]。.

クラウドにおけるライセンスとvCPUモデル

ライセンスについても考えている：多くのメーカーは フィジカルコア, スレッドごとではありません。したがって、SMTはライセンスあたりにより多くのスループットを提供できる。クラウドでは、1つのvCPUが1つのハイパースレッドに対応することが多い。つまり、2つのvCPUは必ずしも2つの物理コアを意味するのではなく、SMT2では1つのコアを意味する。ハードレイテンシーを伴うワークロードに対しては、物理コアの割り当てが保証されたインスタンスタイプを特に予約するか、利用可能であればHTをオフにする。両スレッドが同じコアスロットを共有するため、スロットリングはHTと衝突します。.

実践的トラブルシューティング・チェックリスト

p99はp50より増えているか？CPU%だけでなく、ランキューの長さとスロットリングもチェックしてください。
HT で IPC は著しく低下しますか？その場合、スレッドはクリティカル・ポート／実行ユニットを共有する。
LLCミス多発でメモリ拘束？HTは待ち時間をカバーするのに役立つ
IRQロードとアプリのスレッドを1つのコアに？IRQアフィニティーを分ける
NUMAリモートシェアが高いか？正しいメモリ接続
VM-Ready/Stealの時間が顕著？オーバーコミットおよびvCPUトポロジーの確認
サーマルスロットリングが見える？パワー/サーマルバジェットを調整するか、密度を下げるか。
セキュリティ対策は有効か？オーバーヘッドを考慮し、コアスケジューリングを検討する。

コスト、エネルギー、持続可能性

もし電気系統が パフォーマンス 例えば80WをSMTで使用する場合、追加コストは透明性を持って計算される。1kWhあたり0.30ユーロとすると、0.08kWのコストは1時間あたり約0.024ユーロ、月（720時間）あたり約17.28ユーロとなり、これがラックに加算される。スループットの向上と、以下のような統合の可能性に対して、これを評価する。 仮想マシン, これはライセンスとハードウェアの節約になる。SMTによって必要なホストの数が減れば、最終的にリクエストあたりの全体的なコストは下がることが多い。同時に、高密度が熱的制限を引き起こさないように、冷却とスロットリングに注意を払う [1]。.

持ち帰るべき主要メッセージ

をセットした。 CPUハイパースレッディング 特に、多くのスレッドがあり、スレッドが頻繁に待機するような場合だ。待ち時間が重要なタスクやCPUに負荷のかかるタスクでは、私はよく 物理コア SMTなしで。仮想化では、オーバーコミットを抑え、レディタイムを測定し、vCPUを慎重に配分しています。パッチ、分離、コアスケジューリングでセキュリティに対処し、クリーンプールの分離でリスクを軽減します。最終的に重要なのは測定値です。私は両方のモードを実際の負荷でテストし、直感ではなく数値で判断しています。.