PostgreSQL のパフォーマンスを向上させるための Linux チューニング。 イリヤ・コスモデミャンスキー

Ilya Kosmodemyansky による 2015 年のレポート「PostgreSQL のパフォーマンスを向上させるための Linux チューニング」の転写

免責事項: このレポートの日付は 2015 年 4 月であることに注意してください。9.4 年以上が経過し、かなりの時間が経過しています。 レポートで説明されているバージョン 4 はサポートされなくなりました。 過去 5 年間で、PostgreSQL の 15 つの新しいリリースがリリースされ、Linux カーネルの XNUMX バージョンがリリースされました。 これらの部分を書き直すと、別のレポートが作成されることになります。 ただし、ここでは、今日でも重要な PostgreSQL 用の基本的な Linux チューニングについて考えます。

私の名前はイリヤ・コスモデミャンスキーです。 私は PostgreSQL コンサルティングで働いています。 ここで、データベース全般と特に PostgreSQL に関連して Linux をどうするかについて少し話します。原理は非常に似ているからです。

何を話しましょうか？ PostgreSQL と通信する場合は、ある程度は UNIX 管理者である必要があります。 それはどういう意味ですか？ Oracle と PostgreSQL を比較すると、Oracle では 80% が DBA データベース管理者、20% が Linux 管理者である必要があります。

PostgreSQL の場合はもう少し複雑です。 PostgreSQL を使用するには、Linux がどのように動作するかをより深く理解する必要があります。 同時に、機関車の少し後ろを走ります。最近はすべてが非常にうまく更新されているためです。 そして、新しいカーネルがリリースされ、新しい機能が登場し、パフォーマンスが向上します。

なぜ Linux について話しているのでしょうか? それは、私たちが Linux カンファレンス Peter に参加しているからではありません。現代の状況において、データベース全般、特に PostgreSQL を使用するのに最も正当なオペレーティング システムの XNUMX つが Linux であるからです。 残念なことに、FreeBSD は非常に奇妙な方向に発展しているからです。 そして、パフォーマンスや他の多くのことの両方で問題が発生するでしょう。 Windows 上の PostgreSQL のパフォーマンスは、通常、Windows には UNIX と同じ共有メモリがないという事実に基づく別の深刻な問題ですが、PostgreSQL はマルチプロセス システムであるため、すべてこれに関係しています。

そして、誰もがソラリスのようなエキゾチックにはあまり興味がないと思うので、行きましょう。

最新の Linux ディストリビューションには、カーネルの構築方法に応じて 1 を超える syctl オプションがあります。 同時に、さまざまなナットに注目すると、さまざまな方法で何かを調整することができます。 それらをマウントする方法については、ファイル システム パラメーターがあります。 BIOS で何を有効にするか、ハードウェアの構成方法など、起動方法に関する質問がある場合は、

これは、XNUMX つの短いレポートではなく、数日かけて議論できる非常に大ボリュームですが、ここでは重要なことに焦点を当てます。つまり、Linux でのデータベースの適切な使用を確実に妨げるレーキを回避する方法です。修正しないでください。 同時に、重要な点は、多くのデフォルト パラメーターがデータベースにとって正しい設定に含まれていないということです。 つまり、デフォルトでは、うまく動作しないか、まったく動作しません。

Linux にはどのような従来のチューニング ターゲットがありますか? 皆さんは Linux の管理を扱っているので、ターゲットが何かについては特に説明する必要はないと思います。

以下を調整できます。

• CPU。
• メモリ。
• ストレージ。
• 他の。 これについては最後に軽食をとりながらお話します。 たとえば、省エネ ポリシーなどのパラメータでさえ、非常に予測不可能で、あまり快適とは言えない形でパフォーマンスに影響を与える可能性があります。

PostgreSQL とデータベース全般の詳細は何ですか? 問題は、個々のナットを微調整してもパフォーマンスが大幅に向上したことを確認できないことです。

確かにそのようなガジェットはありますが、データベースは複雑です。 サーバーが持つすべてのリソースと対話し、最大限に対話することを好みます。 ホスト OS の使用方法に関する Oracle の現在の推奨事項を見ると、それはモンゴルの宇宙飛行士についてのジョークのようなものになるでしょう - 犬に餌を与えて何も触らないでください。 データベースにすべてのリソースを与えましょう。データベース自体がすべてを整理します。

原則として、状況はある程度まで PostgreSQL とまったく同じです。 違いは、データベースがまだすべてのリソースを自分自身で取得できないことです。つまり、Linux レベルのどこかで自分ですべてを整理する必要があります。

主なアイデアは、単一のターゲット (メモリ、CPU など) を選択してチューニングを開始するのではなく、ワークロードを分析し、優れたプログラマーが作成した負荷をできるだけ軽減してスループットを向上させることです。ユーザーを含む私たちにとっても。

これが何であるかを説明するための写真です。 Linux OS バッファ、共有メモリ、PostgreSQL 共有バッファがあります。 Oracle とは異なり、PostgreSQL はカーネル バッファを介してのみ直接動作します。つまり、ディスクからのページが共有メモリに入るには、まったく同じ状況でカーネル バッファを通過して戻る必要があります。

ディスクはこのシステムの下に存在します。 これを円盤として描きました。 実際には、RAID コントローラーなどが存在する可能性があります。

そして、この入出力は何らかの形でこの問題を通じて起こります。

PostgreSQL は古典的なデータベースです。 中にページがあります。 すべての入出力はページを使用して行われます。 ページを使用してブロックをメモリに上げています。 そして、何も起こらなければ、単にそれらを読み取るだけで、その後徐々にこのキャッシュや共有バッファーから消えていき、最終的にはディスクに戻ります。

どこかを置き換えると、ページ全体がダーティとしてマークされます。 ここではそれらを青でマークしました。 これは、このページがブロック ストレージと同期する必要があることを意味します。 つまり、ダーティにしたとき、WAL にエントリが作成されました。 そして素晴らしい瞬間に、チェックポイントと呼ばれる現象が起こりました。 そして彼が到着したという情報がこのログに記録されていました。 これは、その時点でこれらの共有バッファーにあったすべてのダーティ ページが、カーネル バッファーを介して fsync を使用してストレージ ディスクと同期されたことを意味します。

なぜこれが行われるのでしょうか? 電圧が失われた場合でも、すべてのデータが失われるという状況は発生しませんでした。 誰もが私たちに話した永続記憶は、これまでのところデータベース理論の中にあります。これは明るい未来であり、もちろん私たちはそれを目指しており、それを気に入っていますが、今のところ、それらはマイナス20年で生きます。 そしてもちろん、これらすべてを監視する必要があります。

スループットを最大化するタスクは、これらすべての段階で微調整して、すべてが迅速に前後に進むようにすることです。 共有メモリは基本的にページ キャッシュです。 PostgreSQL では、選択クエリなどを送信すると、このデータがディスクから取得されます。 これらは最終的に共有バッファーに置かれました。 したがって、これをより適切に動作させるには、大量のメモリが必要です。

これらすべてが適切かつ迅速に機能するためには、すべての段階でオペレーティング システムを正しく構成する必要があります。 また、バランスのとれたハードウェアを選択してください。どこかに不均衡があると、大量のメモリを作成できますが、十分な速度で処理できなくなるからです。

これらの各ポイントを見てみましょう。

これらのページの行き来を高速化するには、次のことを達成する必要があります。

• まず、メモリをより効率的に使用する必要があります。
• 第 XNUMX に、メモリからページがディスクに移動するときのこの移行がより効率的になるはずです。
• そして第三に、良好なディスクが存在する必要があります。

サーバーに 512 GB の RAM があり、そのすべてがキャッシュなしの SATA ハード ドライブに置かれる場合、データベース サーバー全体が単なるカボチャではなく、SATA インターフェイスを備えたカボチャになります。 直接遭遇することになります。 そして何もあなたを救ってはくれません。

XNUMX つ目の記憶に関する点ですが、人生を非常に困難にする要因が XNUMX つあります。

その最初のものはNUMAです。 NUMA はパフォーマンスを向上させるために作られたものです。 ワークロードに応じて、さまざまなことを最適化できます。 また、現在の新しい形式では、ページ キャッシュ共有バッファを集中的に使用するデータベースなどのアプリケーションにはあまり適していません。

一言で言えば。 NUMA に問題があるかどうかはどうすればわかりますか? ある種の不快な衝撃があり、突然一部の CPU が過負荷になります。 同時に、PostgreSQL のクエリを分析すると、類似したクエリが存在しないことがわかります。 これらのクエリは CPU をそれほど集中的に使用するべきではありません。 これなら長く釣れますね。 PostgreSQL 用の NUMA の構成方法については、最初から正しい推奨事項を使用する方が簡単です。

本当に何が起こっているのでしょうか？ NUMA は Non-Uniform Memory Access の略です。 ポイントは何ですか？ CPU があり、その隣にはローカル メモリがあります。 そして、このメモリ相互接続は他の CPU からメモリをプルアップできます。

走れば numactl --hardware、そうするとこのような大きなシートが得られます。 とりわけ、距離フィールドがあります。 10〜20のような数字が表示されます。 これらの数値は、このリモート メモリを取得してローカルで使用するためのホップの数にすぎません。 原則的には良いアイデアです。 これにより、さまざまなワークロード下でパフォーマンスが大幅に高速化されます。

ここで、XNUMX つの CPU が最初にそのローカル メモリを使用しようとしていて、次に何かのためにインターコネクト経由で別のメモリを取得しようとしていると想像してください。 そして、この CPU は PostgreSQL ページ キャッシュ全体を取得します。つまり、数ギガバイトです。 通常、CPU のモジュール自体にはメモリがほとんどないため、常に最悪のケースが発生します。 そして、サービスされるすべてのメモリは、これらの相互接続を経由します。 それは遅くて悲しいことがわかります。 そして、このノードにサービスを提供するプロセッサは常に過負荷状態になります。 そして、このメモリのアクセス時間は悪く、遅いです。 これをデータベースに使用している場合、これは望ましくない状況です。

したがって、データベースにとってより正しいオプションは、Linux オペレーティング システムがそこで何が起こっているかをまったく認識しないことです。 そのため、メモリにアクセスするのと同じようになります。

何故ですか？ それは逆であるべきだと思われるでしょう。 これは XNUMX つの単純な理由で発生します。それは、ページ キャッシュに大量のメモリ (数十、数百ギガバイト) が必要であるということです。

そして、これらすべてを割り当ててそこにデータをキャッシュした場合、キャッシュを使用することで得られる利益は、メモリへのこのようなトリッキーなアクセスによる利益よりも大幅に大きくなります。 したがって、NUMA を使用してより効率的にメモリにアクセスすることと比べて、比較にならないほどのメリットが得られます。

したがって、明るい未来が到来し、データベース自体がどの CPU で実行されているのか、どこから何かを取得する必要があるのか​​を把握できないまで、現時点では XNUMX つのアプローチがあります。

したがって、正しいアプローチは、NUMA を完全に無効にすることです。たとえば、再起動時などです。 ほとんどの場合、賞金は桁違いに大きいため、どちらが良いかという問題はまったく生じません。

別のオプションもあります。 クライアントがサポートを求めて私たちに来たとき、サーバーを再起動するのはクライアントにとって大きな問題となるため、最初のクライアントよりも頻繁にこのクライアントを使用します。 彼はそこでビジネスをしています。 そして、NUMA が原因で問題が発生します。 したがって、再起動よりも侵襲性の低い方法で無効にしようとしますが、無効になっていることを確認するように注意してください。 経験からわかるように、親 PostgreSQL プロセスで NUMA を無効にするのは良いことですが、それが機能する必要はまったくありません。 彼女が本当にスイッチを切ったのかどうかを確認する必要があります。

Robert Haas による良い投稿があります。 これは PostgreSQL コミッターの XNUMX 人です。 すべての低レベルのモツの主要な開発者の XNUMX 人。 この投稿のリンクをたどると、NUMA が人々の生活をいかに困難にしたかについて、いくつかの多彩なストーリーが説明されています。 データベースが正常に動作するためにサーバー上で何を構成する必要があるかについて、システム管理者のチェックリストを調べてください。 これらの設定は書き留めて確認する必要があります。そうしないと、あまり良い結果が得られません。

これはこれから説明するすべての設定に適用されることに注意してください。 ただし、通常、データベースはフォールト トレランスのためにマスター/スレーブ モードで収集されます。 いつか事故に遭ってスレーブに切り替わり、スレーブがマスターになってしまうので、スレーブ側でこれらの設定を行うことを忘れないでください。

緊急事態が発生したとき、すべてが非常に悪く、電話が鳴り続け、上司が大きな棒を持って走ってくるとき、確認することを考える時間はありません。 そして、その結果は非常に悲惨なものになる可能性があります。

次のポイントは巨大ページです。 巨大なページを個別にテストするのは困難であり、これを実行できるベンチマークはありますが、テストすることに意味はありません。 Google に簡単にアクセスできます。

ポイントは何ですか？ たとえば、30 GB 以上の大量の RAM を搭載した、それほど高価ではないサーバーを使用しているとします。 巨大なページは使用しません。 これは、メモリ使用量に関して確実にオーバーヘッドがあることを意味します。 そして、このオーバーヘッドは決して快適なものではありません。

何故ですか？ どうしたの？ オペレーティング システムはメモリを細かく分割して割り当てます。 それはとても便利です、歴史的にはそうなったのです。 さらに詳しく説明すると、OS は仮想アドレスを物理アドレスに変換する必要があります。 また、このプロセスは最も単純ではないため、OS はこの操作の結果を Translation Lookaside Buffer (TLB) にキャッシュします。

TLB はキャッシュであるため、この状況ではキャッシュに固有の問題がすべて発生します。 まず、大量の RAM があり、すべてが小さなチャンクに割り当てられている場合、このバッファは非常に大きくなります。 また、キャッシュが大きい場合、キャッシュ内の検索は遅くなります。 オーバーヘッドは正常であり、それ自体がスペースを占有します。つまり、RAM が何か間違ったものによって消費されています。 この時。

XNUMX つ目は、このような状況でキャッシュが増大するほど、キャッシュ ミスが発生する可能性が高くなります。 そして、このキャッシュの効率は、サイズが大きくなるにつれて急速に低下します。 そこで、オペレーティングシステムはシンプルなアプローチを考案しました。 Linuxでは古くから使われてきました。 それは少し前に FreeBSD に登場しました。 しかし、私たちは Linux について話しています。 これらは巨大なページです。

ここで注目すべきは、アイデアとしてのヒュージ ページは当初、Oracle や IBM を含むコミュニティによって推進されたものでした。つまり、データベース メーカーは、これがデータベースにも役立つと強く考えていました。

そして、これを PostgreSQL とどのように連携させることができるでしょうか? まず、Linux カーネルでヒュージ ページを有効にする必要があります。

次に、sysctl パラメータでそれらの数を明示的に指定する必要があります。 ここの数字は古いサーバーからのものです。 巨大なページがそこに収まる共有バッファーの数を計算できます。

また、サーバー全体が PostgreSQL 専用である場合は、RAM の 25% を共有バッファに割り当てるか、データベースがこの 75% に確実に収まると確信している場合は 75% を割り当てるのが良い開始点です。 出発点 256。 64 GB の RAM がある場合、それに応じて XNUMX GB の大容量バッファがあることを考えてください。 この数値をどの程度に設定するかについて、ある程度の余裕を持って概算してください。

バージョン 9.2 より前 (私の記憶が間違っていなければ、バージョン 8.2 以降) は、サードパーティのライブラリを使用して PostgreSQL を巨大なページに接続することができました。 そして、これは常に行われるべきです。 まず、カーネルが巨大なページを正しく割り当てることができる必要があります。 そして 5 番目に、それらと連携するアプリケーションがそれらを使用できるようにするためです。 ただそのように使われるわけではありません。 PostgreSQL はシステム XNUMX スタイルでメモリを割り当てたため、これは libhugetlbfs を使用して実行できます。これはライブラリの完全名です。

9.3 では、メモリを操作する際の PostgreSQL のパフォーマンスが向上し、システム 5 のメモリ割り当て方法が廃止されました。 誰もがとても満足していました。そうしないと、9.3 台のマシンで XNUMX つの PostgreSQL インスタンスを実行しようとしてしまい、共有メモリが足りないと言われました。 そして、sysctlを修正する必要があると彼は言います。 そして、まだ再起動する必要があるようなsysctlがあります。一般に、誰もが満足していました。 しかし、mmap のメモリ割り当てにより、巨大ページの使用が中断されました。 ほとんどのクライアントは大規模な共有バッファを使用しています。 また、XNUMX ではオーバーヘッドが適切な割合で計算されるようになったため、XNUMX に切り替えないことを強くお勧めします。

しかし、コミュニティはこの問題に注目し、9.4 ではこのイベントを非常にうまく作り直しました。 9.4 では、try をオンまたはオフにできるパラメータが postgresql.conf に追加されました。

試してみるのが最も安全なオプションです。 PostgreSQL が起動すると、共有メモリが割り当てられるときに、このメモリを巨大ページから取得しようとします。 それが機能しない場合は、通常の選択に戻ります。 FreeBSD または Solaris をお持ちの場合は、いつでも安全に試してみることができます。

オンの場合、巨大なページから選択できない場合は単に起動しません。 ここでは、誰が、何がより優れているかについてはすでに話されています。 ただし、試してみたら、間違いの余地がたくさんあるため、本当に必要なものが強調表示されているかどうかを確認してください。 現在、この機能は Linux でのみ動作します。

次に進む前に、もう 32 つ小さな注意事項を記載します。 透過的な巨大ページはまだ PostgreSQL に関するものではありません。 彼はそれらを正常に使用することができません。 また、このようなワークロードに透過的ヒュージ ページを使用すると、大規模な共有メモリが必要な場合、非常に大容量の場合にのみ利点が得られます。 テラバイト規模のメモリがある場合は、これが有効になる可能性があります。 もっと日常的なアプリケーションについて話している場合、マシンに 64、128、256、XNUMX GB のメモリがある場合、通常の巨大ページは問題なく、単に透過を無効にします。

そして最後の記憶については、果物とは直接関係がありません。それは本当にあなたの人生を台無しにする可能性があります。 すべてのスループットは、サーバーが常にスワップしているという事実によって大きく影響されます。

そして、これはさまざまな意味で非常に不快なものとなるでしょう。 そして主な問題は、最新のカーネルの動作が古い Linux カーネルとは若干異なることです。 そして、これを踏むのは非常に不快です。なぜなら、スワップに関するある種の作業について話すとき、それはOOMキラーの時機を超えた到着で終わるからです。 そして、OOM キラーがタイムリーに到着せず、PostgreSQL をドロップしたのは不快です。 これについては、最後のユーザーまで誰もが知ることになります。

何が起こっていますか？ そこには大量の RAM があり、すべてがうまく動作します。 しかし、何らかの理由でサーバーがスワップでハングし、これが原因で速度が低下します。 メモリがたくさんあるように見えますが、これが起こります。

以前は、vm.swappiness をゼロに設定する、つまりスワップを無効にすることをお勧めしました。 以前は、32 GB の RAM とそれに対応する共有バッファは膨大な量だと思われていました。 交換の主な目的は、落ちた場合にクラストを捨てる場所を確保することです。 そしてそれはもはや特に満たされていませんでした。 それで、この皮をどうするつもりですか？ これは、特にこのようなサイズのスワップが必要な理由があまり明確ではないタスクです。

しかし、より新しい、つまりカーネルの第 XNUMX バージョンでは、動作が変わりました。 そして、スワップをゼロに設定すると、つまりスワップをオフにすると、たとえ RAM がいくらか残っていたとしても、遅かれ早かれ、OOM キラーがやって来て、最も集中的なコンシューマーを殺すことになります。 なぜなら、そのようなワークロードではまだ少し残っているので、システムプロセスを特定するのではなく、それほど重要ではないものを特定するために飛び出すだろうと彼は考えるからです。 このそれほど重要ではないものは、共有メモリを集中的に消費するもの、つまりポストマスターになります。 あとは拠点を復旧しなくても良いです。

したがって、現在のデフォルトは、私が覚えている限り、ほとんどのディストリビューションは 6 前後です。つまり、メモリの残量に応じて、どの時点でスワップの使用を開始する必要があります。 現在、vm.swappiness = 1 を設定することをお勧めします。これは実際には無効にしますが、予期せず到着して全体を破壊する OOM キラーと同じ効果は得られません。

次は何ですか？ データベースのパフォーマンスについて話し、徐々にディスクに移行すると、誰もが頭を抱え始めます。 なぜなら、ディスクは遅く、メモリは速いという真実は、子供の頃から誰もが知っているからです。 そして、データベースにディスク パフォーマンスの問題が発生することは誰もが知っています。

ディスクが遅いため、チェックポイントのスパイクに関連する主要な PostgreSQL パフォーマンス問題は発生しません。 これは、メモリとディスクの帯域幅のバランスが取れていないことが原因であると考えられます。 ただし、場所によってはバランスが取れない場合があります。 PostgreSQL が構成されておらず、OS も構成されておらず、ハードウェアも構成されておらず、ハードウェアが正しくありません。 そして、この問題は、すべてが想定通りに起こった場合、つまり、負荷がないか、設定とハードウェアが適切に選択されている場合にのみ発生するわけではありません。

それは何ですか、またどのように見えますか? 通常、PostgreSQL を扱う人はこの問題に何度か関わったことがあるでしょう。 説明します。 先ほども述べたように、PostgreSQL は定期的にチェックポイントを作成して、共有メモリ内のダーティ ページをディスクにダンプします。 大量の共有メモリがある場合、チェックポイントは fsync でこれらのページをダンプするため、ディスクに集中的な影響を及ぼし始めます。 これはカーネル バッファに到着し、fsync を使用してディスクに書き込まれます。 このビジネスの量が多い場合、ディスクの使用量が非常に多くなるという不快な影響が観察される可能性があります。

ここに90枚の写真があります。 それが何なのか、これから説明していきます。 これらは 90 つの時間相関グラフです。 最初のグラフはディスク使用率です。 こちらは現時点でほぼ100％に達しております。 物理ディスクでデータベース障害が発生し、RAID コントローラーの使用率が XNUMX% になっている場合、これは悪い知らせです。 これは、もう少し進むと XNUMX に達し、I/O が停止することを意味します。

ディスクアレイを使用している場合は、少し話が異なります。 それは、構成方法、アレイの種類などによって異なります。

そして並行して、内部 postgres ビューからのグラフがここで構成され、チェックポイントがどのように発生するかを示します。 ここの緑色は、その時点で同期のためにこのチェックポイントに到着したバッファ (ダーティ ページ) の数を示しています。 そして、これがここで知っておくべき重要なことです。 ここには大量のページがあり、ある時点でボードに到達しました。つまり、書き続けました。ここでは、ディスク システムが明らかに非常にビジーになっています。 そして、チェックポイントはディスクに非常に強い影響を与えます。 理想的には、状況は次のようになるはずです。つまり、ここでは録音が少なくなります。 そして、この状態が継続するように設定で修正することができます。 つまり、リサイクルは小さいですが、どこかでここに何か書いています。

この問題を克服するには何をする必要がありますか? データベースで IO を停止した場合、リクエストを実行するために来たすべてのユーザーが待機することになります。

Linux の観点から見た場合、適切なハードウェアを使用し、正しく構成し、これらのチェックポイントの頻度を減らし、時間の経過とともに相互に分散するように PostgreSQL を正常に構成した場合、デフォルトの Debian パラメータに踏み込むことになります。 ほとんどの Linux ディストリビューションでは、vm.dirty_ratio=20、vm.dirty_background_ratio=10 のようになります。

それはどういう意味ですか？ カーネル 2.6 からはフラッシングデーモンが XNUMX つ出現しました。 Pdglush は、誰がどれを使用しているかに応じて、カーネル バッファからのダーティ ページのバックグラウンドでの破棄と、バックグラウインドでの破棄が役に立たない場合にどうしてもダーティ ページを破棄する必要がある場合に破棄します。

背景はいつ来るのですか？ サーバー上で使用可能な合計 RAM の 10% がカーネル バッファ内のダーティ ページによって占有されている場合、特別なライトオフ関数がバックグラウンドで呼び出されます。 なぜ背景なのでしょうか？ パラメータとして、消去するページ数が考慮されます。 そして、彼は N ページを書き捨てたとします。 そしてしばらくの間、これは眠りに落ちます。 そして彼女は再びやって来て、さらにいくつかのページをコピーしました。

これは非常に単純な話です。 ここでの問題は、プールの場合と同じで、水が XNUMX つのパイプに注ぎ込まれると、別のパイプに流れ込みます。 チェックポイントが到着し、破棄するためにいくつかのダーティ ページを送信した場合、徐々に全体がカーネル バッファー pgflush から適切に解決されます。

これらのダーティ ページが蓄積し続けると、最大 20% まで蓄積されます。その後、電源が落ちてすべてが悪くなるため、OS の優先事項はすべてをディスクに書き込むことです。 たとえば、このデータは失われます。

コツは何ですか？ 重要なのは、現代世界におけるこれらのパラメータは、マシン上の合計 RAM の 20% と 10% であり、ディスク システムのスループットという観点から見ると、まったく巨大なものであるということです。

128 GB の RAM があると想像してください。 12,8 GB がディスク システムに到着します。 そして、そこにどんなキャッシュがあっても、どんな配列があっても、それらはそれほど長くは続きません。

したがって、RAID コントローラーの機能に基づいてこれらの数値をすぐに調整することをお勧めします。 私はすぐに、512 MB のキャッシュを備えたコントローラーをここで推奨しました。

すべてが非常に単純であると考えられています。 vm.dirty_background をバイト単位で指定できます。 そして、これらの設定は前の XNUMX つの設定をキャンセルします。 どちらかの比率がデフォルトであるか、バイトを持つ比率がアクティブ化されている場合は、バイトを持つ比率が機能します。 しかし、私は DBA コンサルタントであり、さまざまなクライアントと仕事をしているため、バイト単位であれば、バイト単位でストローを描くようにしています。 優秀な管理者がサーバーにメモリを追加したり再起動したりしないと、数値が変わらないという保証は誰もしませんでした。 すべてが保証されてそこに収まるように、これらの数値を計算するだけです。

適合しない場合はどうなりますか? フラッシングは効果的に停止されると書きましたが、実際にはこれは比喩です。 オペレーティング システムには大きな問題があります。多くのダーティ ページがあるため、クライアントが生成する IO は実質的に停止されます。つまり、アプリケーションはデータベースに SQL クエリを送信しに来て待機しています。 データベースはチェックポイントによって占有されているため、データベースへの入力/出力の優先度は最も低くなります。 そして彼女がいつ終わるのかは完全に不明だ。 そして、非バックグラウンド フラッシュを達成すると、すべての IO がそのフラッシュによって占有されることを意味します。 そしてそれが終わるまで、あなたは何もしません。

ここにはさらに XNUMX つの重要な点がありますが、このレポートの範囲を超えています。 これらの設定は、postgresql.conf の設定、つまりチェックポイント設定と一致する必要があります。 また、ディスク システムが適切に構成されている必要があります。 RAID 上にキャッシュがある場合は、バッテリーが必要です。 人々はバッテリーなしで、優れたキャッシュを備えた RAID を購入します。 RAID に SSD がある場合、それはサーバー用のものである必要があり、そこにコンデンサがなければなりません。 詳細なチェックリストは次のとおりです。 このリンクには、PostgreSQL でパフォーマンス ディスクを構成する方法に関する私のレポートが含まれています。 これらすべてのチェックリストがそこにあります。

他に人生を非常に困難にするものは何ですか？ これらは XNUMX つのパラメータです。 比較的新しいものです。 デフォルトでは、これらはさまざまなアプリケーションに含めることができます。 また、誤ってオンにすると、同じように生活が困難になる可能性があります。

比較的新しいものがXNUMXつあります。 それらはすでに第 XNUMX コアに登場しています。 これは、ナノ秒単位の sched_migration_cost と、デフォルトで XNUMX である sched_autogroup_enabled です。

そして、それらはどのようにあなたの人生を台無しにするのでしょうか？ sched_migration_cost とは何ですか? Linux では、スケジューラはプロセスをある CPU から別の CPU に移行できます。 また、クエリを実行する PostgreSQL については、別の CPU への移行はまったく不透明です。 オペレーティング システムの観点からは、openoffice とターミナルの間でウィンドウを切り替える場合、これは良いことかもしれませんが、 データベースにとって、これは非常に悪いことです。 したがって、適切なポリシーは、migration_cost を何らかの大きな値 (少なくとも数千ナノ秒) に設定することです。

これはスケジューラーにとって何を意味しますか? この間、プロセスはまだ高温であると考えられます。 つまり、長時間何かを実行している長時間実行トランザクションがある場合、スケジューラはこれを理解します。 このタイムアウトが経過するまでは、このプロセスをどこにも移行する必要はないと想定します。 同時にプロセスが何かを実行した場合、そのプロセスはどこにも移行されず、割り当てられた CPU 上で静かに動作します。 そして結果は素晴らしいです。

XNUMX 番目のポイントは自動グループです。 最新のデータベースに関係のない特定のワークロードに対しては、プロセスを起動元の仮想端末ごとにグループ化するという良いアイデアがあります。 これは一部のタスクに便利です。 実際には、PostgreSQL は単一の端末から実行されるプリフォークを備えたマルチプロセス システムです。 ロック ライターとチェックポイントがあり、すべてのクライアント リクエストが CPU ごとに XNUMX つのスケジューラにグループ化されます。 そして彼らは、お互いに干渉して彼をより長く占領し続けるために、彼が自由になるまで一斉にそこで待ちます。 このような負荷の場合は全く不要なのでオフにする必要があるという話です。

私の同僚の Alexey Lesovsky は、単純な pgbench を使用してテストを行い、そこで、migration_cost を一桁増やし、autogroup をオフにしました。 不良ハードウェアではその差はほぼ 10% でした。 postgres メーリング リストにはディスカッションがあり、クエリ速度に対する同様の変更の結果が報告されています。 50%に影響を与えた。 そういう話は結構多いです。

最後に、節電政策についてです。 良いのは、ラップトップでも Linux を使用できるようになったことです。 そして、おそらくバッテリーをよく使います。 しかし、突然、これがサーバーでも発生する可能性があることが判明しました。

さらに、どこかのホスティング会社からサーバーを借りている場合、「良い」ホスティング会社はあなたのパフォーマンスが優れているかどうかを気にしません。 彼らの任務は、鉄をできるだけ効率的に利用することです。 したがって、デフォルトでは、オペレーティング システムでラップトップの省電力モードを有効にすることができます。

データベースの負荷が高いサーバーでこれを使用する場合は、acpi_cpufreq + permormance を選択します。 オンデマンドであっても問題は発生します。

Intel_pstate は少し異なるドライバーです。 そして今では、後からのものでより良く機能するため、これが優先されます。

したがって、知事はパフォーマンスにすぎません。 オンデマンド、省電力、その他すべてはあなた次第ではありません。

省電力を有効にすると、PostgreSQL の Explain 分析の結果が数桁異なる場合があります。これは、実際にはデータベースの CPU がまったく予測できない方法で実行されるためです。

これらの項目はデフォルトで含まれている場合があります。 デフォルトでオンになっているかどうかを注意深く確認してください。 これは非常に大きな問題になる可能性があります。

そして最後に、この問題で日々前進している、PosgreSQL-Consulting DBA チームの Max Boguk と Alexey Lesovsky に感謝の意を表したいと思います。 そして、私たちはクライアントにとってすべてがうまくいくように、クライアントのためにできる限りのことをしようと努めています。 航空安全に関する指示と似ています。 ここにあるものはすべて血で書かれています。 これらのナッツはそれぞれ、何らかの問題の過程で見つかります。 皆さんと共有できることを嬉しく思います。

質問：

ありがとう！ たとえば、企業がコストを節約してデータベースとアプリケーション ロジックを XNUMX つのサーバーに配置したい場合、または企業が PostgreSQL をコンテナ内で実行するマイクロサービス アーキテクチャの流行のトレンドに従っている場合です。 コツは何ですか？ Sysctl はカーネル全体にグローバルに影響します。 sysctl がコンテナ上で個別に動作するように何らかの形で仮想化されているという話は聞いたことがありません。 cgroup だけがあり、そこにはコントロールの一部しかありません。 これでどうやって生きていけますか？ それとも、パフォーマンスが必要な場合は、別のハードウェア サーバーで PostgreSQL を実行して調整しますか?

私たちはあなたの質問にXNUMXつほどの方法で答えました。 調整できるハードウェア サーバーの話ではない場合は、安心してください。これらの設定がなくてもすべてが正常に動作します。 これらの設定を行う必要があるほどの負荷がある場合は、これらの設定よりも早くアイアン サーバーにアクセスすることになります。

何が問題ですか？ これが仮想マシンの場合、たとえば、ほとんどの仮想マシンではディスクの遅延がまったく一貫していないなど、多くの問題が発生する可能性があります。 ディスクのスループットが良好であっても、チェックポイント時または WAL への書き込み時に発生した平均スループットに大きな影響を及ぼさない I/O トランザクションが XNUMX 回失敗すると、データベースはこれによって大きな影響を受けます。 そして、これらの問題に遭遇する前に、これに気づくでしょう。

同じサーバー上に NGINX がある場合も、同じ問題が発生します。 彼は共有された記憶を求めて戦うだろう。 そして、ここで説明されている問題に遭遇することはありません。

しかし一方で、これらのパラメータの中には、依然として重要なものもあります。 たとえば、それほどおかしくないように sysctl を使用して Dirty_ratio を設定します。いずれにせよ、これは役に立ちます。 いずれにせよ、ディスクと対話することになります。 そしてそれは間違ったパターンに従ってしまうでしょう。 これは通常、私が示したパラメータのデフォルトです。 そして、いずれにせよ、それらを変更する方が良いでしょう。

ただし、NUMA に問題がある可能性があります。 たとえば、VmWare は、まったく逆の設定を使用した NUMA で適切に動作します。 そしてここで、鉄製サーバーか非鉄製サーバーかを選択する必要があります。

Amazon AWS に関する質問があります。 事前に構成されたイメージがあります。 そのうちの XNUMX つは Amazon RDS と呼ばれます。 オペレーティング システム用のカスタム設定はありますか?

設定はありますが、別の設定です。 ここでは、データベースがこれをどのように使用するかという観点からオペレーティング システムを構成します。 そして、整形など、今どこに行くべきかを決定するパラメーターがあります。 つまり、非常に多くの資源が必要なので、それを今すぐに食べてしまうのです。 この後、Amazon RDS はこれらのリソースを強化し、そこでパフォーマンスが低下します。 人々がこの問題にどのように干渉し始めているかについては、個別の話があります。 場合によっては非常に成功することさえあります。 ただし、これはOSの設定とは関係ありません。 クラウドをハッキングするようなものです。 それは別の話です。

Huge TLB と比較して、Transparent huge Page が効果がないのはなぜですか?

あげないで。 これはさまざまな方法で説明できます。 しかし実際には、彼らはただそれを与えません。 PostgreSQLの歴史は何ですか? 起動時に、大きな共有メモリが割り当てられます。 透明かどうかは全く関係ありません。 彼らが最初に目立つという事実がすべてを説明します。 また、大量のメモリがあり、shared_memory セグメントを再構築する必要がある場合は、透過的なヒュージ ページが関連します。 PostgreSQL では、最初に巨大なチャンクに割り当てられるだけで、それだけで、その後は特別なことは何も起こりません。 もちろん使用できますが、何かを再割り当てするときにshared_memoryが破損する可能性があります。 PostgreSQL はこれについて知りません。

出所： habr.com