最新のオペレーティングシステム：開発者が知っておくべきこと

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

今日、私たちはオペレーティングシステムに興味を持ちます-その内部、そこで何が起こっているのでしょうか...私たちが現在取り組んでいるアイデアを共有したいと思います。

私の意見では、最新のOSは悪いことです。

実際には、写真はNetmapサイトのグラフを示しています（これは、ネットワークアダプターパケットを非常に迅速にキャプチャして送信できるギズモです）。 この図は、最大3 GHzの異なるクロック速度を持つ単一コアで、Netmapが10 Gbps-1秒あたり1400万パケットを許可することを示しています。 すでに500 MHzで動作します。 青い線はpktgenです-一般的に、Linuxカーネル内で最速です。 これはそのようなものです-1つのパケットを受け取ってそれをアダプターに何度も送信するトラフィックジェネレーター、つまり コピーも新しいパッケージの作成もありません。つまり、一般に何もありません-同じパッケージをアダプタに送信するだけです。 そして今では、Netmap（ユーザー空間で行われていることはピンク色の線で示されています）に比べて大幅に低下しています。 したがって、非常に高速なネットワークアプリケーションで作業する人々は、Netmap、Pdpdk、PF_RINGに移行します。そのような技術は現在たくさんあります。

2番目のポイントは、データベースに関するものです。 これはネットワークに関するものであり、現在はデータベースに関するものです。 誰かがデータベースを調べた場合、MMAPを使用できることがわかり、O_DIRECTを使用できることがわかります。 大規模なデータベース（Postgres、MySQL、InnoDB）では、主にO_DIRECTを使用しますが、2007年にはLKMLで議論があり、O_DIRECTはダーティコレクションであると言われましたが、これは誤りです。 オペレーティングシステムのコード、強力なデータベースのコードを見ると、データベースがそれ自体のために大きなメモリ領域を取得し、管理していることがわかります。 彼女自身がページのプールを保持し、ページを操作し、ページを押し出し、破棄します。 オペレーティングシステムが仮想メモリレベル、ファイルシステムレベルなどで行うすべて

Linuxは、madviseを使用して作業するように言った。 Pyotr Zaitsevが尋ねました：「しかし、O_DIRECTなしではどうやって生きるのか？」 いつどのページにリセットするかを知る必要があるからです。」 答えはありませんでした。私たちは同じように生き続けています。

次のポイントは、アプリケーションのプログラミング方法です。 マルチスレッドネットワークデーモンを作成する場合、通常、次の質問があります。 プロセス、イベント、スレッド、そこで起動できるスレッドの数、各スレッドが多数のイベント、状態マシン、スレッドを処理できるようにマシン状態を作成する方法、またはErlangのようにコルーチンを使用する方法はありますか？」など これはかなり複雑な質問です。

「なぜイベントが悪いアイデアなのか」（Rob von Behren）と「SEDA：条件の整ったスケーラブルなインターネットサービスのアーキテクチャ」（Matt Welsh）という素晴らしい記事がありますが、これらは完全に矛盾しています。 スレッド上ですべてを行う必要があり、最新のOSはスレッドで非常にうまく機能し、必要な数のスレッドを提供し、それらを適切に同期するとすべてがうまく機能すると言う人もいます。 SEDAは、特定の数のスレッドを起動し、特定のタスク間でそれらを再分散する、より重いアーキテクチャについて話します。スレッドとこれらのスレッドのタスクをスケジューリングするためのかなり複雑なメカニズムがあります。

一般的には、hemoの問題に対処する必要があり、実際には、Boost.Asioなどの何らかのストリーミングフレームワークを使用するか、自分で手作業で行い、何が必要かを考える必要があります。 パフォーマンスが必要です。それについて考える必要があります。

私たちは、多くのメモリアロケーターが存在する世界に住んでいます。 簡単なものを書く場合は、mallocまたはC ++のnewを使用し、現在の状態と何が起こるかについては考えません。 高負荷に達するとすぐに、jemalloc、hoard、およびその他の既製のライブラリをドラッグし始めるか、メモリアロケータ（SLAB、プールなど）を作成します。 サーバーを作成する場合は、最初に単純なプログラムから始めてから、ユーザー空間でのOSの再実装に進みます。



迅速な入出力のためのバッファプールを作成し、独自のストリーム、何らかのスケジューリング、同期メカニズム、独自のメモリアロケータなどを作成します。

一方、デスクトップ。 昨日、私は自分のために何が実行されているかを見ました-私は120のプロセスを立ち上げましたが、それらの多くは私にも知られていない。 私は軽量のシステムが大好きで、原則として、自分にとって何が効果的かを理解しています。 KDEまたはGNOMEを実行すると、200から300のプロセスが大量に発生しますが、それが何であり、何をするのかさえわかりません。 彼らがシステムにどのような負荷をかけるかさえ推測していません。一般的に、それは私には関係ありません。 印刷し、コードをコンパイルします。一般に、デスクトップの最大ベンチマークには興味がありません。記録を設定する必要があるサーバーの最大ベンチマークに興味があります。

2つ目は、デスクトップの消費電力がかなり低くなったことです。通常のシングルプロセッサ、少しのコア、少しのメモリ、NUMAなし、つまり すべてが非常にシンプルで、すべてが非常に小さいです。 それにもかかわらず、Linuxは私たちの携帯電話と大規模なサーバーで動作することを知っています。 これはあまり正しくありません。

進歩的な世界がどのように生きているかを見ると...多分誰かが重いDDoSに遭遇したなら、彼らはこの兆候を知っています：



これは、トラフィックをフィルタリングするための大規模なデータセンターを構築した先駆者の1人によるデータプレートであり、ネットワークアクセラレータなしで通常のIntelハードウェアで動作し、人々は独自のOSを作成します。 赤色は削除したものを示し、基本的な安価なサーバーから10 Gbのトラフィックを削除できるデータを受け取りました。

そのようにLinuxを起動しただけなら、何も脱ぎません。 さらに、これらの人々はApplication Layer DDoSレベルでかなり深刻なフィルタリングを行います。 IP / TCPに登るだけでなく、通常のOSが行うことだけでなく、HTPを解析し、解析し、ある種の分類子を実行し、いくつかのプロセッササイクルで1つのパケットを解析します。すべてが非常に高速です。



なぜこれがLinuxとの共存なのかを答えようとするなら、うれしいです。 2000年代のどこかで、Solarisは確固たる地位を占めていました。Solarisは古く、重く、Linuxは速くて軽いという議論がありました。これはメーリングリストにも載っています。 これでSolarisにあったものがあります-Linuxは非常に大きく、コードは膨大であり、多くのオプションがあり、すべてを実行できます。やりたいことはすべて実行できます。 OpenBSD、NetBSDなどの他のOSもありますが、これらははるかに単純で、あまり使用されていませんが、Linuxは非常に強力なものです。

私はウィキペディアから上の写真を引きちぎりました-彼らはいくつかの文脈でLinuxを描写しようとしました。 垂直列があります-コア内のディレクトリに応じたサブシステムで、その下の列は上位から下位に移動しました。 これは非常に複雑なグラフです。 実際、たとえば100レベルのレベルでのI / O計画（青と青緑）を見てみると、すべてが表示されているわけではありません。 実際にはすべてがより複雑で、大きな接続、多くの異なるキュー、多くのロックがあり、これはすべて動作するはずです。すべてがゆっくり動作します。

縦の列を調べて、Linuxサブシステムと、問題が発生する可能性のあるサブシステムでできることを見てみましょう。 一部は管理者の観点から、一部はアプリケーションコードの開発者の観点から。



まず、プロセスとスレッドを操作します。 Linuxには、対数時間で機能する公平なI / Oスケジューラがあります。 彼は現在、デフォルトのスケジューラーであり、それ以前は一定時間動作するスケジューラーがありました。 スケジューラー自体を最適化してパフォーマンスを向上させるためにスケジューラーに入る必要はありませんでした。つまり、そこでどのように機能するかを知っていますが、最適化する必要はありませんでした。 そこですべてが何らかの形で計画されており、おそらく、うまく計画されています。 問題は通常どこかで発生します。

私が言ったように、デスクトップとサーバーは完全に異なる世界です。 1つのプロセッサ、8または16コアを持つサーバーがある場合-これは1つのオプションです。 それぞれが10コアの4つのプロセッサを備えたサーバーがある場合、システムには40のコアがあり、さらにハイパースレッディングがあるため、8つのスレッドがあります。 現在、プロセッサはより大規模になり、さらに多くの並列コンテキストが存在し、状況は完全に異なっています。

まず、スレッド、プロセス、イベントについて話す場合、次に選択するもの（スレッド、プロセス、またはステートマシン）については、すべてあなたの利便性についてです。

高速で記述したい場合は、何らかのフレームワークを使用して、Vent、またはBoost.Asioをストリームの束とともに使用します。

パフォーマンスが必要な場合は、単位時間あたりに何かできる鉄、核がある程度あることを正確に理解する必要があります。 1つのユニットにできる以上のことを強制し、1つのハードウェアストリームに多くのソフトウェアフローを与えた場合、何も起こりません。 最初のコンテキスト切り替えが発生します。 システムコールがある場合、コンテキストスイッチはここで安価です。 オペレーティングシステムには特別な最適化があり、アプリケーションプロセスがカーネルに移動してすぐに戻った場合、そのキャッシュはそれほど洗い流されず、キャッシュは無効になりません。 少し洗い流しますが、一般的に、私たちはよく生きています。 アプリケーションコンテキストのスケジュールが変更されると、すべてが非常に悪くなります。

• 最新のIntelプロセッサーでは、レベル1キャッシュを無効にする必要があります。 私たちの最も価値のあることは、私たちが最も小さくて最も高価なものであり、遅いメモリで本当に速く働くことを可能にすることです-私たちはそれを失います。 古いキャッシュL2、L3は単純に洗い流されます。 並行して実行される複数のスレッド、複数のプロセス、十分な量のデータを処理するプログラムがあり、それらのスケジュールが変更される場合、各プログラムまたは各スレッドが動作するメモリがキャッシュにロードされ、前のものがやったこと、それ自体のためにキャッシュを獲得していたもの。 逆コンテキストスイッチが発生すると、最初のプログラムが再び制御を取得すると、実際にはコールドキャッシュに切り替わり、メモリからデータをプルし始めます。動作時間の順序はまったく異なります。
• 以下。 デスクトップでもスマートフォンでも見られないものはNUMAです。 それ以前はAMDでしたが、現在はIntelである最新のX86は、非対称アーキテクチャになりました。 一番下の行は、OSスケジューラーとプロセッサーが異なるということです。これらは異なるノードです。 各ノードは独自の物理ローカルメモリで動作し、OSスケジューラーが1つのノードから移動することを決定した場合、1つのプロセッサーから別のプロセッサーにプロセスを移動すると、すべてが非常に悪くなります。 私たちの記憶は遅いチャンネルに広がっています。 幸いなことに、OSは実行しているカーネルのトポロジを認識しており、これを実行しようとしませんが、それでも考慮すべき事項があるため、実行しなければならない場合があります。
• 次。 共有データの操作方法のメカニズムは少し変更されました。 数年前に静かにスピンロックを取得し、これが最速であると想定できる場合、つまり いくつかの小さな変数を取り、サイクルでスピンし、この変数のいくつかの値でそれを期待しますが、今はそれができません。 80個のコアが1バイト、4バイトで壊れている場合、データバスに問題が生じ、すべてが非常に遅くなります。 以前に使用した同期メカニズムは使用できません。

「すべてのプログラマがメモリについて知っておくべきこと」（Ulrich Drepper）を読むことを強くお勧めします-素晴らしい本です。少し古いですが、一般的な概念は非常に優れており、どのように機能し、何ができるかを示しています。



最初の写真は、すべてが大衆に参入し始めたAMDの2008年または2009年です。 合計で2つのプロセッサがあります。 青いチャネルは、2つのコアが通信するチャネルです。 ここでは、2つのコアを持つ2つのプロセッサがあります。 2つのコア間では非常に高速な転送が行われ、異なるプロセッサー間では非常に低速です。 したがって、0.3カーネルがある場合、同じロック、同じintで動作し、これらの4バイトを遅いメモリチャネルで駆動し始めます-これは非常に遅いです。 同じint変数を持つP0とP1が機能する場合、すべてが非常に高速です。

現代のアーキテクチャでは、それらは近づいてきました。おそらく、4つのプロセッサを搭載した写真よりもさらに進んだのでしょう。 ここにフラット構造がある場合-高速プロセッサと低速チャネルの2つのプロセッサがあり、すでにすべてのコアとすべてが通信しているわけではなく、3次元設計になっています。 たとえば、P3はP4と通信せず、2ホップする必要があります。 つまり P4からP3のデータが必要な場合、最初にP0に移動し、次にP0がすでにP4に移動します。 転送には別のプロセッサを使用する必要があります。

最新のIntelのi7アーキテクチャ-非常に深刻なバスとKPIを備えています。 実際、このインフラストラクチャ、コア通信、データ同期があります。 彼らは、TCP / IP、すなわち マルチレベル通信プロトコルがあり、それらのパケットはプロセッサ間のデータバスで実行されます。かなり複雑なことと、より高速な転送があり、低速で非常に難しい最新のi7を理解することです。 Numactlはノードの距離を示します。 つまり、斜めに見ると、このコア自体はいくつかの重さ、いくつかのオウムです-最も安い価格です。 彼が他のノードに行くのはすでに難しいです。 すでに21の重みが考慮されています。

ハードウェアのトポロジを表示するユーティリティでも、アクセスするコアはすべて同じ価格であると考えられます。 実際、これは少し間違っていますが、NUMAを使用する場合、ローカルプロセッサではすべてが高速で、他の誰かではすべてが低速であると仮定する方が簡単です。



コードを高速に動作させるために何ができ、何が正しいのでしょうか？ まず、スピンロック、さまざまなデータ構造、ロックフリー、これは2010年代に非常に普及しました。 さまざまなロックフリーのキューやものは、大きなマシンでは機能しません。 最近、「ここには2万のストリームがあり、その人は、データをすばやく挿入および収集できるように、クイックキューを作成したかった」と尋ねられました。 それはそのようには動作しません、すなわち すべてが非常に遅くなります。 20,000のスレッドがキャッシュされ、不可解なアトミックな命令、データ、そしてすべてが非常に遅くなります。 したがって、NUMAシステム用のコードを作成する場合、マシン内、鉄片の中に小さなクラスターがあり、小さなマシン、1つのプロセッサ、マルチコアであるようにソフトウェアを構築すると考えます。 -16コアで、彼女は自分のことをローカルで行い、時々見知らぬ人と通信します。 そして、マシンのクラスターを組み合わせると、通信がさらに遅くなります。 このようなクラスターの階層（高速クラスターと低速クラスター）を取得します。

共有データの良い例は、C ++がshared_ptrの場合、つまり共有データを使用するのは良くないということです。 データへのポインターがあります-これらはスマートポインターであり、参照カウンターがあります。これは、ポインターのコピーごとにそれぞれ変化します。ロードされたサーバーを作成すると、shared_ptrは使用できません。

たとえば、ブーストロバが存在する理由の1つは、shared_ptr、スマートポインター、およびアクションを大幅に遅くするその他の高レベルなものを非常に多く使用するため、サーバー上で優れたパフォーマンスが得られないことです。 この高レベルのオブジェクトコードは、可能な限り迅速に未加工の鉄で動作することを期待していません。

さらに。 偽りの共有。 さまざまな高レベルプログラミング言語では、1バイト、2、4、8バイトで動作します。 プロセッサは64バイトで動作します-これはプロセッサの1キャッシュラインです。 つまり 変数が64バイトで同じキャッシュラインに格納されている場合、プロセッサの場合は1つの変数であり、2つの変数に対してすべてのアルゴリズムを正確に実行します。 何らかの理由で2つのホット変数、たとえば2つのスピンロックが完全に異なり、イデオロギー的に同じキャッシュラインに収まる場合、大きな問題が発生します。 異なるコアがありますが、同じデータを求めて戦い始めますが、並行して動作するはずです。 そして、あなたは、実際には、2つのロックを持っているという事実に気付きますが、それらは1つのロックとして機能します。

バインディングプロセスは、NUMAの場合のみです。 かなり古いテスト。 4コアの4プロセッサのマシンがありました。 まず、ddを実行してncに送信すると、ddが一方のコアで実行され、ncが他方のコアで実行されます。 その瞬間、何らかの理由で、OSは「プロセッサが異なるため、アプリケーションプロセスを異なるプロセッサに分散させる方が良い」と判断し、1つのプロセスを1つのプロセッサに、別のプロセスに別のプロセスを与え、かなり低いパフォーマンスを得ました。 両方のプロセスが同じプロセッサ上で動作する必要があると厳密に記述すると、転送が大幅に増加します。 つまり OSはスケジューリングプロセスにおいて常に良いことを行うとは限らず、常に賢いことを行うとは限りません。

もう1つ-異なるサーバー、つまり すべてが回転しているデスクトップがあり、それが何であるかはわかりません。 apache、nginx、MySQL、ルーターなどが機能するサーバーがあります。 そのようなプレハブのホッジポッジがあります。 しかし、高性能クラスターを構築している場合、大企業の構築方法を見ると、原則としてクラスターがあり、レベルがあり、最初のレベルがあります-たとえば、10台のマシンにnginxがあり、各マシンにはnginxとOSしかありません。 次のレベル-いくつかのスクリプトを備えたApacheがあり、次のレベル-MySQLがあります。 1台のマシンが1つの高レベルのタスクであることがわかりました。 これは完全に異なるアプローチであり、このシナリオでは、アプリケーション、nginxまたはapacheは、すべてのリソースを所有しているという事実に依存することができ、OSが提供する仮想化を必要としません-仮想メモリであり、これはすべてのプログラムが考慮するアドレス空間の分離です未知の量のCPUで動作すること。 たとえば、Webサーバーを起動するときに、コアの数に等しいワーカー、または2倍のワーカーを起動できます。 私たちは基づいています-コアの数に労働者の数。 これは、マシン全体を完全に利用する1つのアプリケーションがある例です。



メモリについて。 要するに、より多くのメモリを使用すればするほど、あなたにとっては悪いことです。 写真を見ると、これが仮想メモリの仕組みです。 アドレスがあります（これは上の行です）-0から63ビットで、仮想アドレス空間で作業し、物理アドレス空間を持つハードウェアがある場合、いつものように、仮想アドレス空間を物理にマッピングします。 したがって、2つのプログラムが機能する場合、変数アドレスは同じかもしれませんが、これらのアドレスは異なる物理メモリセルを参照します。 これが仮想メモリの原理です。 したがって、プロセッサが特定のアドレスにアクセスする場合、この仮想アドレスを物理アドレスに解決する必要があります。

ページテーブルは私たちのために働いています-示されているもの。 ページテーブルは4つのレベルで構成されています。 最初の4つのレベルがあり、そこから39〜47番目のビットが参照されます-これはページです。 このページはプレートであり、インデックスはビットでエンコードされた数値であり、次のレベルにジャンプしてから、ビットの次の部分を解決します。 これは、1つのページ、1つのレベルが次のレベルにリンクするフラット構造を示しています。 第1レベルでは、原則としてプログラムの上級住所が一致することは明らかです。

OSは、メモリ割り当てを行うときに、使用可能なアドレスに可能な限り近い最小のアドレスを選択します。 木を取得します。 最初のグレーのルーラーは1つ、2つ目は1つ、3つ目のレベルでは2つ、最後のレベルではレベル全体を完全に使い始めます。 メインページにルートを持つそのようなツリーを取得してから、分岐します。 したがって、メモリを多く使用すればするほど、分岐するツリーが増えます。もちろん、これもどこかに保存する必要があり、これは物理メモリでもあります。 次に、これがどのように使用されているか、そして何よりもメモリ消費量を確認します。

二番目。 ある種のバイナリツリーを作成するとします。青いノードと緑のノードがあり、そこに行きたいと考えています。 私たちにとって、これはツリーであり、OSにとっては、ツリー内のツリー、つまり キーaを渡すと、最初のレベルから2番目のレベルまで、ツリーを介して転送が行われ、ツリーの4つのレベルを完全に通過します。 次に、次の瞬間、2番目のレベルから3番目のレベルにジャンプします。 繰り返しますが、ツリーは解決されます。 ツリーの最上部から下に移動するために、8つのメモリ転送があります-これはたくさんあります。

幸いなことに、TLBキャッシュがあります。 実際、これはかなり小さなキャッシュであり、合計約1000個のアドレスがそこに配置されています。 ページに対応する変換テーブル。 4 Kbページ、1000ページ-4 Mb、つまり 4 MBは、TLBにキャッシュしたものです。 アプリケーションが4 MBを超えるとすぐに、ツリーの周りを走り始めます。最新のアプリケーションの4 MBは、一般的には何もありません。 そして、あなたはかなり頻繁にTLBキャッシュから抜け出します。 使用するメモリが多いほど、パフォーマンスが低下します。



ページの混雑について。 私たちのデータベースはこれを行うとすでに述べましたが、実際、一部のメカニズムはデータベースとOSで非常に似ており、LinuxはLRUの二重リストを保持しています。 アクティブリストと非アクティブリストがあります。 したがって、ページは、割り当てのみを行うか、ページで何かを行うと、アクティブリストに配置されます。 その後、しばらくして、非アクティブリストにプッシュされます。 kswapdデーモン、psを作成すると、kswapdが表示されます-コアごとに1つずつ、これらはページ間転送を行っています。 また、ページが2回目に完全に期限切れになると、非アクティブリストから既に絞り出されており、たとえばmallocなどの匿名ページの場合はスワップに移行します。 ファイルされたファイルの場合、ページは単に破棄され、ファイルされたファイルに移動します。

アクティブおよび非アクティブのリストがあるという事実に加えて、ページは汚れてきれいになる可能性があります。 つまり ページを読むだけなら、きれいです。 何かを書き留めた場合、二次ストレージにダンプされるまでそれは汚れています-スワップされるか、ファイルに書き戻されます。 メモリに何かを書き込むたびに、すべてをディスクにダンプしたくありません。 明らかに、これにより作業が遅くなります。 しかし、場合によってはリセットする必要があります。大量の負荷がある場合、今すぐすべてを書き込み、メモリに書き込み、どこにもダンプしないと、十分なメモリがないためです。 1バイトのメモリにレコードが到着し、アクティブリセットを開始し、これらのリストを調べて、これをすべてディスクにダンプすると、通常は立ち上がります。

したがって、ライトバックプロセスがあり、ファイルシステムはこのプロセスに作業を追加します。 また、ライトバックは、ダーティページをセカンダリリポジトリにダンプするだけです。

sysctl変数があります。 sysctlにはカーネル内のドキュメントを使用します。常に手元にカーネルがあり、そこを調べます。カーネルには、各sysctlが何をするかがよく書かれたドキュメントがあります。

したがって、dirty_background_ {ratio、bytes}は遅延障害の開始点です。 ファイルシステムがライトバックのために作業を行う必要があると判断したとき、書き込みバイト数、ダーティバイト数、またはクリーンページから取得したダーティページの割合について、このデータのダンプを開始します。ドライブ。

dirty_ {ratio、bytes}は、プロセスがデータを書き込み、新しいダーティページを作成するときであり、その時点で既にあるダーティページの数を調べます。 それらがたくさんある場合、彼自身がセカンダリストレージにそれらをすぐにダンプし、それらが少ない場合は、ライトバックのためにこれを残します。 これは、非常に集中的に書き込みを行うときに状況から逃れようとする方法ですが、ライトバックストリームにはすべてをリセットする時間がありません。

Writeback_centisecsは、ページがどのようにシートを通過するか、およびシートがポップされる頻度を制御します。

Cache_presureは、どのデータをプッシュするかの間の妥協です。 つまり これが何らかの種類のファイルサーバーである場合、多くのiノードと多くのディレクトリライターが必要です。 これが単なるメモリの大きな領域に配置されたデータベースである場合、iノードは必要ありません。 たとえば、ngnixはファイルを開き、そのファイルをキャッシュに保持します。ディレクトリは必要ありません。inodeが必要な場合がありますが、ほとんどの場合必要ではなく、ページキャッシュが重要です。



ラージページについて。 私たちのページテーブルは4 KBページで機能すると言いますが、実際、TLBでは4 MBしかアドレス指定できないことがわかりました-これでは十分ではありません。 したがって、カーネルレベルとプロセッサレベルで最適化が行われます-これは大きなページです。 プロセッサがどのように動作するかは正直わかりませんが、最終的には、ページを割り当てた場合、2 MBまたは1 GBの物理ページがないことになります。 物理的には、まだ4 KBです。 そして、大きなページを割り当てると、実際、OSは4 KBの連続ブロックを探します。これにより、この大きなページになります。 この大きなページは、ページテーブルの1つのオカレンスとTLBの1つのオカレンスのみで構成されます。

ここでの問題は、通常のページに第1レベルのTLBがある場合-これは約1000エントリであり、大きなページでは-これはおそらく2 MBで約8、GBで1-2であるということです。 これに基づいて、大きなデータベースがある場合、大きなページはあなたに合わないかもしれません、そしてあなたが1バイトだけを書くと、このバイトに1GBが割り当てられ、それがファイルからひきつり、最終的にあなたにとって有益ではなくなります。 比較的小さなデータの非常に激しいスタックを保持している場合、つまり MySQLを40 GBのメモリに上げるようなものではありませんが、文字通り1 GBから2-4 MBの小さなデータベースがあり、これがデータ構造で非常に難しい場合は、ヒューページを使用するのが理にかなっています。

素晴らしい点は、Linux 2.6.38が透明な大きなページを導入したことです。 しばらくの間、大きなページに煩わされ、それを使用するために特別なファイルシステムをマウントする必要がありましたが、今ではLinuxがすべてを単独で実行できます。 メモリ領域を指定する場合は、madviseを実行します。このメモリ領域で大きなページを使用したいので、たとえばmmap largeでページを選択すると、Linuxは大きなページを割り当てようとします。 割り当てられない場合は、4 Kbまでスライドしますが、このために可能なすべてのことを行います。 大きなページのサポートは、xdpyinfoで表示できます。



ディスクの入出力について。 ここには、2つの大きな興味深いカテゴリに分類できる3つのオプションがあります。1つ目はコピー付きファイルI / O、2つ目はコピーなしです。

写真は通常の動作を示しています。 open, read, write, , .. page cache. - , , , , kswapd, writeback- , , . . , read write, , page cache, .. . , , O_DIRECT -, page cache, , , mmap' - .

– mmap. , O_DIRECT read write , mmap - - - , , . , , , , , O_DIRECT'a.

mmap. , X86, , , 128 , 10 – , - . , , , page 3, 128 , mmap, 128 – - .



, - n , mmap , . つまり , , , mmap.



. - , page table . .., page table – , 128 256 page table, .. , .



. - . , . , , , - . , , , , , . つまり , .

. , , , , - . – . .

, Linux' -. .., , , , , , . , CPU -, .. .

Deadline – , , , - , .. . , .

CFQ – , , , , , , , -, . , .



. sysctl , , , , . .… , , , , . , , , read , .

Read_ahead – , - , . , , . , InnoDB , , , .

, , .



. zero-copy , , zero-copy a. つまり htp , , , , - user space firewall , .

, user space , .. , , . , , , , . 64 . 64 , 4-5 . , , 100 , zero-copy , .

, . , zero-copy, TCP/IP . , , TCP . .., , . .., . , , 64 TCP, 128 . , 64 , 64 , , , , - , . つまり , TCP , .



. , , . つまり grep /proc/interrupts ethernet , , 16, 24, 40, , . , , . つまり 20-40 , .., , .

c RPS, .. , , , , . , , .. IP- , TCP, TCP, IGP .. . , , , , -, , , . RPS, , - .



Offloading. Jumbo frames, , . , GRO GSO . , , 64 , , . , GSO, GRO 64 , , , , 64 . , Jumbo frames, a , , .



Qdisc – . Linux' , , , wi-fi , - . , , , , IP-, – , .. , . - , ( ) – , – , , , . Qdisc , . livejournal – www.linuxjournal.com/content/queueing-linux-network-stack .



Sysctl , . , , nginx, , sysctl, , .

連絡先

» ak@natsys-lab.com
» NatSys Lab.

— HighLoad++ Junior . 2016 — HighLoad++ , 7 8 .

(, ) — " Linux Kernel Extension for Databases ".

- HighLoad.Guide — , , , . 30 . !