この記事は、私が今年OSCON会議で発表したプレゼンテーションに基づいています。 テキストをより簡潔になるように編集すると同時に、スピーチ後に受け取ったフィードバックを考慮しました。



彼らはよくGoについて、サーバーに適していると言います：静的バイナリ、 並行性の開発、および高性能があります。 この記事では、最後の2つのポイントについて説明します。言語とランタイムにより、Goプログラマーが簡単にスケーラブルなサーバーを作成でき、スレッド制御やI / O操作のブロックについて心配する必要がありません。

言語パフォーマンスの議論

しかし、技術的な詳細に移る前に、Go言語の市場セグメントを特徴付ける2つのステートメントを作成します。

ムーアの法則

誤って引用されたムーアの法律によると、水晶の単位面積あたりのトランジスタ数は約18か月ごとに2倍になります。 しかし、完全に異なる特性に依存する動作周波数は、Pentium 4のリリースにより、数十年前にすでに成長を停止し、それ以降は徐々に減少しています。

空間的制約からエネルギーへ

^{Sun Enterprise e450-バー冷蔵庫とほぼ同じサイズの電力を消費}



これがSun e450です。 私のキャリアが始まったばかりの頃、これらのコンピューターは業界の主力製品でした。 彼らは巨大だった。 3個の上に1個置くと、19インチラック全体を占有します。 同時に、それぞれ約500ワットしか消費しませんでした。



過去10年間で、データセンターの主な制限は利用可能なスペースではなく、エネルギー消費のレベルになりました。 最後の2つのケースでは、私がデータセンターの立ち上げに参加したとき、ラックをほぼ3分の1に満たしたときにすでに十分なエネルギーがありませんでした。 計算能力の密度は非常に速くなったため、機器の設置場所を考えることができなくなりました。 同時に、現代のサーバーははるかに少なくなりましたが、はるかに多くの電力を消費し始めました。 これは冷却を非常に複雑にし、その品質は機器の動作にとって重要です。



エネルギー制限の効果が現れました：

• マクロレベルでは、1200ワットの1Uサーバーでラック操作を提供できるものはほとんどありません。
• マイクロレベルでは、これらの数百ワットはすべて、熱の形で小さなシリコン結晶に散らばっています。

このようなエネルギー消費の増加の理由は何ですか？

^{CMOSインバーター}



これは、最も単純な論理ゲートの1つであるインバーターです。 入力Aが高い場合、出力Qは低く、逆も同様です。 現代のすべての家庭用電化製品は、 CMOSロジック上に構築されています（CMOSは、相補型金属酸化物半導体構造です）。 ここでのキーワードは「相補的」です。 プロセッサ内の各論理要素は、トランジスタのペアを使用して実装されます。一方がオンになると、もう一方がオフになります。



インバーター出力が高または低の場合、VssからVddに電流は流れません。 しかし、スイッチング中、 両方のトランジスタが電流を伝導する短い期間があり、短絡が発生します。 そして、エネルギー消費、ひいては熱放散は、1秒あたりのスイッチング数、つまりプロセッサーのクロック速度に直接比例します。



CMOSのエネルギー消費は、スイッチング中の短絡だけではありません。 シャッターの出力容量の充電に貢献しています。 さらに、トランジスタのサイズが小さくなると、ゲートリーク電流が増加します。 これについての詳細はリンクで読むことができます： one 、 two 。



プロセッサ要素のサイズを縮小することは、主に消費電力を削減することを目的としています。 これはエコロジーのためだけでなく、主な目的は、プロセッサーへの損傷を防ぐために許容可能なレベルで熱放散を維持することです。



クロック速度と消費電力は減少していますが、生産性の向上は主にマイクロアーキテクチャと難解なベクトル命令の改善に関連しており、一般的なコンピューティングには特に役立ちません。 その結果、各マイクロアーキテクチャ （5年サイクル）は前世代を10％超えて超えず、最近では4-6％にほとんど達していません。

「景品は終わりました」

鉄が速くなってきていないことを理解してください。 パフォーマンスと規模が重要な場合は、少なくとも一般的に認められている意味では、機器だけでは問題を解決することはできないことに同意するでしょう。 サッターの紋章で述べたように-「 景品は終わりました」。



生産性の高いプログラミング言語が必要です。なぜなら、非効率的な言語は、スケーリングや設備投資という点で、広範な使用での使用を正当化するものではないからです。

並列プログラミング言語の議論

2番目の引数は最初の引数から続きます。 プロセッサは速くなりませんが、厚くなります。 トランジスタがこの方向に発展していることは、あなたにとって驚くべきことではありません。







Intelが呼んでいる同時マルチスレッディングまたはハイパースレッディングでは、小さなハードウェアバインディングを追加することにより、単一のコアが命令の複数のスレッドを並列に実行できます。 インテルは、ハイパースレッディングテクノロジーを使用してプロセッサ市場を人為的にセグメント化し、オラクルと富士通は自社製品で積極的に使用し、ハードウェアスレッドの数をコアあたり8または16にしました。



デュアルプロセッサマザーボードは、Pentium Proが登場した1990年代後半に登場しました。 現在では標準的なソリューションであり、ほとんどのサーバーは2プロセッサまたは4プロセッサ構成をサポートしています。 トランジスタの密度の増加により、単一のチップ上に複数のコアを配置することさえ可能になりました。 デュアルコアプロセッサはモバイルセグメント、4コア-デスクトップセグメント、サーバーセグメントではさらに多くのコアに定着しました。 実際、今日のサーバーのコア数は予算によってのみ制限されています。



そして、これらのすべてのコアを活用するには、高度な並列処理を備えたプログラミング言語が必要です。

プロセス、スレッド、およびゴルーチン

Goの並列処理は、いわゆるゴルーチンに基づいています。 少し脱線して、それらの発生の履歴を思い出しましょう。

プロセス

明け方、バッチ処理モデルでは、コンピューターは一度に1つのタスクしか実行できませんでした。 1960年代には、よりインタラクティブな形式のコンピューティングが求められていたため、マルチプロセスオペレーティングシステム、またはタイムシェアリングモードで動作するシステムが開発されました。 1970年代に、このアイデアはサーバー、FTP、Telnet、rlogin、そして後にTim Berners-LeeのCERN httpdに浸透しました。 すべての着信ネットワーク接続の処理には、子プロセスの分岐が伴いました。



タイムシェアリングシステムでは、OSはアクティブなプロセス間でプロセッサリソースをすばやく切り替えることにより、並列処理の錯覚を維持します。 これを行うには、まず現在のプロセスの状態を記録してから、別のプロセスの状態を復元します。 これは、コンテキストスイッチングと呼ばれます。

コンテキストスイッチ

コンテキストスイッチングには、3つの主要なコスト項目があります。

• カーネルは、最初に1つのプロセスのすべてのプロセッサレジスタの内容を保存してから、別のプロセスの値を復元する必要があります。 プロセス間の切り替えはいつでも発生する可能性があるため、OSはすべてのレジスタの内容を保存する必要があります。これは、現在どのプロセスが使用されているかわからないためです。 もちろん、これは非常に単純化された説明です。 場合によっては、OSは、浮動小数点またはMMX / SSEレジスタへのアクセスが割り込み（障害）を引き起こすような方法でプロセスを開始することにより、頻繁に使用されるアーキテクチャレジスタの保存と復元を回避できます。 そのような状況では、カーネルはプロセスがこれらのレジスタを使用し、それらを保存および復元する必要があることを理解しています。
• カーネルは、仮想メモリアドレスを物理アドレス（ TLB、連想変換バッファ ）と一致させるためにキャッシュをクリアする必要があります。 一部のプロセッサは、いわゆるタグ付きTLBを使用します。 この場合、OSは、各エントリをグローバルとして扱うのではなく、プロセスIDから取得した識別子を特定のバッファエントリに割り当てるようにプロセッサに命令する場合があります。 これにより、目的のプロセスがすぐに同じコアに戻る場合、プロセスが切り替わるたびにキャッシュからエントリを削除する必要がなくなります。
• コンテキスト切り替えのOSオーバーヘッド、およびプロセッサに作業を提供する次のプロセスを選択するときのスケジューラー機能のオーバーヘッド。

これらの費用はすべて、機器の観点からは比較的一定ですが、これらの費用が正当化されるかどうかは、切り替え操作間で実行される作業量によって異なります。 頻繁に切り替えると、それらの間で行われる作業量が無効になります。

ストリーム

これにより、共通アドレス空間を使用する同じプロセスであるスレッドが出現しました。 このため、プロセスよりも計画が簡単で、作成がより高速であり、より迅速に切り替えることができます。



それでも、スレッドのコンテキストスイッチングのコストは非常に高くなります。 州に関する多くの情報を保存する必要があります。 ゴルーチンは、実際にはフローの概念をさらに発展させたものです。

ゴルチン

コアに所要時間を管理する責任を委ねる代わりに、ゴルーチンは協調マルチタスクを使用します。 それらの間の切り替えは、Goランタイムスケジューラによって明示的な呼び出しが行われる明確に定義された瞬間にのみ発生します。 ゴルーチンがスケジューラに制御を返す主な状況：

• ブロックにつながる場合、チャネルからの送受信。
• go func（...）命令を呼び出しますが、新しいゴルーチンへの切り替えがすぐに行われるという保証はありません。
• ファイル操作やネットワーク操作などのシステムコールのブロック
• 実行を停止してガベージコレクションサイクルを実行した後。

つまり、ゴルーチンに作業を続けるのに十分なデータがないか、データを記録するためにより多くのスペースが必要な状況について話しているのです。



その過程で、Goランタイムスケジューラは、同じオペレーティングシステムスレッド内のいくつかのゴルーチンを切り替えます。 これにより、作成とそれらの切り替えのコストが削減されます。 1つのプロセスで数万のゴルーチンが実行され、数十万のゴルーチンが実行されるという、まったく正常な状況です。



言語の観点からは、計画は関数呼び出しのように見え、同じセマンティクスを持ちます。 コンパイラは、使用されるレジスタを認識し、自動的に保存します。 スケジューラーはスレッドを呼び出して、特定のgoroutinスタックを処理しますが、戻るとスタックが異なる場合があります。 これをマルチスレッドアプリケーションと比較してください。マルチスレッドアプリケーションは、いつでも命令を実行したときに、いつでもスレッドを強制的に削除できます。



これはすべて、各GoプロセスのOSスレッドが比較的少ないという事実につながります。 Goランタイムは、すぐに実行できるゴルーチンを解放してOSスレッドに割り当てます。

スタック管理

前のセクションでは、goroutinesが複数の並列フロー（時には数十万に達することもあります）を管理するオーバーヘッドを削減する方法について説明しました。 ゴルーチンの話には別の側面があります-スタック管理。

プロセスアドレス空間

この図は、一般的なプロセスメモリカードを示しています。 ここでは、ヒープとスタックを配置することに興味があります。 プロセスのアドレス空間内では、通常、ヒープはメモリの下部、プログラムコードのすぐ上にあり、成長します。 スタックは仮想アドレス空間の最上部にあり、下に向かって成長します。







ヒープとスタックが互いに上書きすると、災害になります。 したがって、OSは、それらの間にアクセスできないメモリのバッファゾーンを割り当てます。 ガードページと呼ばれ、実際にはプロセススタックのサイズを制限します。通常は数メガバイト以内です。

フロースタック

ストリームは1つの共通アドレススペースを使用します。 各スレッドには、個別の監視ページを持つ独自のスタックが必要です。 各スレッドのニーズを予測するのは難しいため、各スタックに大量のメモリを予約する必要があります。 これで十分であり、ウォッチページにアクセスできないことを願うだけです。



このアプローチの欠点は、プログラム内のスレッドの数が増えると、使用可能なアドレス空間の量が減少することです。

Goroutinスタック管理

プロセスモデルの以前のバージョンでは、プログラマはヒープとスタックがそれを心配しないほど十分に大きいと考えるかもしれません。 ただし、サブタスクのモデリングは複雑で高価になりました。



スレッドの導入により、状況はわずかに改善されました。 ただし、プログラマは最適なスタックサイズを推測する必要があります。 少なすぎる-プログラムがクラッシュし、多すぎる-仮想アドレス空間が終了します。



Goスケジューラが少数のスレッド内で多数のゴルーチンを実行することは既に確認しました。 これらのゴルーチンのスタックサイズ要件はどうですか？

Goroutinスタックの成長

最初に、各ゴルーチンにはヒープから割り当てられた小さなスタックがあります。 そのサイズは言語バージョンに応じて変化しました; Go 1.5では、デフォルトで2キロバイトが割り当てられます。 ウォッチページを使用する代わりに、Goコンパイラは各関数呼び出しの一部であるチェックを挿入します。



このチェックにより、スタックサイズが機能を実行するのに十分かどうかを確認できます。 はいの場合、機能は正常に実行されます。 スタックが小さすぎる場合、ランタイムはヒープ上により大きなセグメントを割り当て、そこに現在のスタックの内容をコピーし、それを解放して、関数を再起動します。



このメカニズムのおかげで、非常に小さな初期ゴルーチンスタックを作成できます。 これにより、ゴルーチンを安価なリソースと見なすことができます。 スタックの十分な部分が未使用のままである場合、スタックのサイズを縮小するメカニズムもあります。 削減手順は、ガベージコレクション中に実行されます。

統合ネットワークポーラー

2002年、Dan Kegelは「 Problem c10k 」というタイトルの記事を公開しました。 簡単に言えば、当時利用可能な安価な機器で少なくとも10,000のTCPセッションを処理できるサーバーソフトウェアを作成することに専念していました。 この記事を書いた後、高性能サーバーにはネイティブスレッドが必要であるという一般的な考えがありました。 最終的に、イベントループが代わりになりました。



計画とメモリ消費のコストの観点から、スレッドには高いコストがかかります。 イベントループの状況は改善されていますが、コールバックに基づく複雑な作業原理に関連して、独自の要件があります。



Goは、これら2つのアプローチのすべてを最大限に活用しました。

c10k問題への回答に行く

Goシステムコールは通常、操作をブロックしています。 このような呼び出しには、ファイル記述子の読み取りと書き込みが含まれます。 Goスケジューラは、フリースレッドを見つけるか、新しいスレッドを作成することにより、これらのケースを処理します。これにより、元のスレッドがブロックされている間、ゴルーチンの提供を継続できます。 これは、少数のブロッキングスレッドがローカルI / Oスループットをすぐに使い果たす可能性があるため、実際にはファイル操作に適しています。



ただし、ネットワークソケットはそれほど単純ではありません。 いつでも、ほとんどすべてのゴルーチンはネットワークI / Oが完了するのを待ってブロックされます。 プリミティブな実装の場合、そのようなゴルーチンごとに1つのスレッドを実行する必要があり、ネットワークトラフィックを見越してそれらすべてがブロックされます。 Go統合ネットワークポーラーは、このような状況に対処するのに役立ち、言語ランタイムとネットパッケージ間の相互作用を提供します。



Goの古いバージョンでは、ネットワークポーラーは1つのゴルーチンであり、kqueueまたはepollを使用して準備通知を要求していました。 このようなゴルーチンは、チャネルを通じて待機中のゴルーチンと通信しました。 これにより、各システムコールにスレッドを割り当てることは避けられましたが、チャネルに書き込むことで一般化された起動メカニズムを使用する必要がありました。 これは、計画者が覚醒の原因や重要性を認識していなかったことを意味します。



Goの現在のバージョンでは、ネットワークポーラーはランタイム自体（ランタイム）に統合されています。 環境はソケットの準備が整うのを待機しているゴルーチンを知っているため、パケットの到着時に同じプロセッサコアでゴルーチンを実行し続けることができ、待ち時間を短縮してシステムスループットを向上させることができます。

ゴルーチン、スタック管理、統合ネットワークポーラー

まとめると。 ゴルーチンは強力な抽象化であり、そのおかげでスレッドプールやイベントループを心配することはできません。



ゴルーチンスタックは必要に応じて大きくなります。スタックやスレッドプールのサイズを変更する必要はありません。



統合されたネットワークポーラーは、華やかなコールバックベースのスキームの使用を回避します。 これには、OSから取得できる最も効率的なI / Oロジックが含まれます。



ランタイムは、すべてのゴルーチンを処理し、プロセッサコアをロードするために必要なだけのスレッドが存在することを確認します。



そして、これらの機能はすべてGoプログラマーに対して完全に透過的です。