カーネルパラメータの設定 Linux PostgreSQLを最適化する

PostgreSQLの最適なパフォーマンスは、オペレーティングシステムのパラメータが適切に設定されているかどうかに左右されます。カーネルパラメータの設定が不適切だと、データベースサーバーのパフォーマンスが低下する可能性があります。そのため、データベースサーバーとそのワークロードに合わせてこれらのパラメータを適切に設定することが不可欠です。この記事では、重要なカーネルパラメータについて解説します。 Linuxこれはデータベースサーバーのパフォーマンスや設定方法に影響を与える可能性があります。

SHMMAX / SHMALL

SHMMAX — は、プロセスが割り当て可能な単一の共有メモリセグメントの最大サイズを決定するために使用されるカーネルパラメータです。 Linuxバージョン9.2より前は、PostgreSQLはSystem V（SysV）を使用しており、SHMMAX設定が必要でした。バージョン9.2以降、PostgreSQLはPOSIX共有メモリに切り替わりました。これにより、必要なSystem V共有メモリのバイト数が少なくなりました。

バージョン 9.3 より前は、SHMMAX が最も重要なカーネル パラメータでした。 SHMMAX 値はバイト単位で指定します。

同様に シュモール を決定するために使用される別のカーネルパラメータです。
システム全体の共有メモリ ページのボリューム。 現在の SHMMAX、SHMALL、または SHMMIN 値を表示するには、次のコマンドを使用します。 ipcs.

SHM*の詳細 — Linux

$ ipcs -lm

------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 1073741824
max total shared memory (kbytes) = 17179869184
min seg size (bytes) = 1

SHM* 詳細 - MacOS X

$ ipcs -M
IPC status from  as of Thu Aug 16 22:20:35 PKT 2018
shminfo:
	shmmax: 16777216	(max shared memory segment size)
	shmmin:       1	(min shared memory segment size)
	shmmni:      32	(max number of shared memory identifiers)
	shmseg:       8	(max shared memory segments per process)
	shmall:    1024	(max amount of shared memory in pages)

PostgreSQL が使用するもの System VIPC 共有メモリを割り当てます。 このパラメータは、最も重要なカーネル パラメータの XNUMX つです。 次のエラー メッセージが表示される場合は、古いバージョンの PostgreSQL が使用されており、SHMMAX 値が非常に低いことを意味します。 ユーザーは、使用する共有メモリに応じて値を調整および増加することが期待されます。

構成ミスの可能性があるエラー

SHMMAX が正しく構成されていない場合、次のコマンドを使用して PostgreSQL クラスターを初期化しようとすると、エラーが発生する可能性があります。 initdb.

initdb の失敗
DETAIL: Failed system call was shmget(key=1, size=2072576, 03600).

ヒント: このエラーは通常、PostgreSQL の共有メモリ セグメント要求がカーネルの SHMMAX パラメータを超えたことを意味します。 
リクエスト サイズを小さくするか、SHMMAX を大きくしてカーネルを再構成することができます。リクエストサイズ（現在2072576バイト）を減らすには、
PostgreSQL の共有メモリ使用量を削減します。たとえば、shared_buffers または max_connections を減らします。

リクエストサイズがすでに小さい場合は、カーネルのSHMMINパラメータよりも小さい可能性があります。
その場合、要求サイズを増やすか、SHMMIN を再構成する必要があります。

PostgreSQL のドキュメントには、共有メモリの構成に関する詳細情報が記載されています。子プロセスは終了コード1で終了しました

同様に、次のコマンドを使用して PostgreSQL サーバーを起動すると、エラーが発生する場合があります。 pg_ctl.

pg_ctl の失敗
DETAIL: Failed system call was shmget(key=5432001, size=14385152, 03600).

ヒント: このエラーは通常、PostgreSQL の共有メモリ セグメント要求がカーネルの SHMMAX パラメータを超えたことを意味します。

リクエスト サイズを減らすか、SHMMAX を大きくしてカーネルを再構成することができます。リクエスト サイズ (現在 14385152 バイト) を減らすには、shared_buffers または max_connections を減らすなどして、PostgreSQL の共有メモリの使用量を減らします。

リクエストサイズがすでに小さい場合は、カーネルのSHMMINパラメータよりも小さい可能性があります。
その場合、要求サイズを増やすか、SHMMIN を再構成する必要があります。

PostgreSQL のドキュメントには、共有メモリの構成に関する詳細情報が記載されています。

定義の違いを理解する

SHMMAX/SHMALLパラメータの定義は、 Linux およびmacOS X：

• Linux: kernel.shmmax、kernel.shmall
• MacOS X: kern.sysv.shmmax、kern.sysv.shmall

チーム sysctl 値を一時的に変更するために使用できます。 定数値を設定するには、エントリを追加します。 /etc/sysctl.conf。 詳細は以下の通りです。

MacOS X でのカーネル設定の変更

# Get the value of SHMMAX
sudo sysctl kern.sysv.shmmax
kern.sysv.shmmax: 4096

# Get the value of SHMALL
sudo sysctl kern.sysv.shmall 
kern.sysv.shmall: 4096

# Set the value of SHMMAX
sudo sysctl -w kern.sysv.shmmax=16777216
kern.sysv.shmmax: 4096 -> 16777216

# Set the value of SHMALL 
sudo sysctl -w kern.sysv.shmall=16777216
kern.sysv.shmall: 4096 -> 16777216

カーネルパラメータを変更する Linux

# Get the value of SHMMAX
sudo sysctl kernel.shmmax
kernel.shmmax: 4096

# Get the value of SHMALL
sudo sysctl kernel.shmall
kernel.shmall: 4096

# Set the value of SHMMAX
sudo sysctl -w kernel.shmmax=16777216
kernel.shmmax: 4096 -> 16777216

# Set the value of SHMALL 
sudo sysctl -w kernel.shmall=16777216
kernel.shmall: 4096 -> 16777216

忘れないでください: 変更を永続的にするには、これらの値を /etc/sysctl.conf に追加します。

巨大なページ

В Linux デフォルトでは、BSDでは4KBのメモリページが使用されます。 スーパーページとで Windows - 大きなページ。 ページは、プロセスに割り当てられた RAM の一部です。 メモリ要件に応じて、プロセスには複数のページが含まれる場合があります。 プロセスが必要とするメモリが増えるほど、より多くのページが割り当てられます。 OS はプロセスのページ割り当てテーブルを維持します。 ページ サイズが小さくなるほど、テーブルが大きくなり、そのページ テーブル内でページを見つけるのに時間がかかります。 したがって、大きなページを使用すると、オーバーヘッドを削減しながら大量のメモリを使用できるようになります。 ページビューが減り、ページフォールトが減り、より大きなバッファ上での読み取り/書き込み操作が高速化されます。 その結果、パフォーマンスが向上します。

PostgreSQL は、大きなページのみをサポートしています。 Linux。 デフォルト Linux 4KBのメモリページを使用するため、メモリ操作が多い場合は、より大きなページを設定する必要があります。2MBから最大1GBの大きなページを使用すると、パフォーマンスが向上します。大きなページサイズは起動時に設定できます。大きなページの設定とその使用状況は、簡単に確認できます。 Linux-コマンドを使用するコンピュータ 猫 /proc/meminfo | grep -i 巨大です.

大きなページに関する情報を取得する（ Linux)

Note: This is only for Linux, for other OS this operation is ignored$ cat /proc/meminfo | grep -i huge
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

この例では、ラージ ページのサイズは 2048 (2 MB) に設定されていますが、ラージ ページの総数は 0 に設定されています。これは、ラージ ページが無効になっていることを意味します。

大きなページの数を決定するためのスクリプト

このシンプルなスクリプトは、必要な数の大きなページを返します。サーバー上でスクリプトを実行してください。 LinuxPostgreSQL の実行中。環境変数を確認してください。 $PGDATA PostgreSQLデータディレクトリを指定します。

必要なラージページの数を取得する

#!/bin/bash
pid=`head -1 $PGDATA/postmaster.pid`
echo "Pid:            $pid"
peak=`grep ^VmPeak /proc/$pid/status | awk '{ print $2 }'`
echo "VmPeak:            $peak kB"
hps=`grep ^Hugepagesize /proc/meminfo | awk '{ print $2 }'`
echo "Hugepagesize:   $hps kB"
hp=$((peak/hps))
echo Set Huge Pages:     $hp

スクリプトの出力は次のようになります。

スクリプト出力

Pid:            12737
VmPeak:         180932 kB
Hugepagesize:   2048 kB
Set Huge Pages: 88

大きなページの推奨値は 88 なので、88 に設定する必要があります。

大きなページのインストール

sysctl -w vm.nr_hugepages=88

ここでラージ ページを確認すると、ラージ ページが使用されていないことがわかります (HugePages_Free = HugePages_Total)。

大きなページに関する詳細情報（ Linux)

$ cat /proc/meminfo | grep -i huge
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
HugePages_Total:      88
HugePages_Free:       88
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

次に、$PGDATA/postgresql.conf で huge_pages パラメータを「on」に設定し、サーバーを再起動します。

そしてまた大きなページに関する情報 ( Linux)

$ cat /proc/meminfo | grep -i huge
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
HugePages_Total:      88
HugePages_Free:       81
HugePages_Rsvd:       64
HugePages_Surp:        0
Hugepagesize:       2048 kB

これで、大きなページがほとんど使用されていないことがわかります。 次に、データベースにデータを追加してみましょう。

大きなページをリサイクルするための一部のデータベース操作

postgres=# CREATE TABLE foo(a INTEGER);
CREATE TABLE
postgres=# INSERT INTO foo VALUES(generate_Series(1,10000000));
INSERT 0 10000000

以前よりも多くの大きなページを使用しているかどうかを見てみましょう。

大きなページに関する情報（ Linux)

$ cat /proc/meminfo | grep -i huge
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
HugePages_Total:      88
HugePages_Free:       18
HugePages_Rsvd:        1
HugePages_Surp:        0
Hugepagesize:       2048 kB

これで、大きなページのほとんどが使用されていることがわかります。

注: ここで使用されている HugePages の推定値は非常に低く、製品環境を実行しているマシンの通常の値ではありません。 システムに必要なページ数を見積もり、負荷とリソースに基づいて適切に設定してください。

vm.swappiness

vm.swappiness — は、データベースのパフォーマンスに影響を与える可能性のあるもう 1 つのカーネル パラメータです。このパラメータは、スワッピング動作 (メモリへのページの出し入れ) を制御するために使用されます。 Linux値の範囲は0から100です。これは、どれだけのメモリをスワップアウトするかを決定します。0はスワップなし、100は積極的なスワップを意味します。

より低い値を設定すると、良好なパフォーマンスが得られます。

新しいカーネルで値を 0 に設定すると、OOM Killer (メモリ クリーンアップ プロセス) が Linux) はプロセスを強制終了します。したがって、スワッピングを最小限に抑えたい場合は、値を 1 に設定しても安全です。デフォルト値は Linux - 60。値が大きいほど、MMU（メモリ管理ユニット）はRAMよりも多くのスワップ領域を使用し、値が小さいほど、より多くのデータ/コードがメモリに保持されます。

PostgreSQL のパフォーマンスを向上するには、値を低くすることをお勧めします。

vm.overcommit_memory / vm.overcommit_ratio

アプリケーションはメモリを取得し、不要になったらメモリを解放します。 ただし、場合によっては、アプリケーションが過剰なメモリを取得し、それを解放しないことがあります。 これにより、OOM キラーが発生する可能性があります。 可能なパラメータ値は次のとおりです vm.overcommit_memory それぞれの説明付き:

1. ヒューリスティックなオーバーコミット (デフォルト)。 カーネルベースのヒューリスティック
2. とにかくオーバーコミットを許可する
3. やりすぎたり、オーバーコミット率を超えたりしないでください。

参考： https://www.kernel.org/doc/Documentation/vm/overcommit-accounting

vm.overcommit_ratio — 過負荷に利用可能な RAM の割合。 50 GB の RAM を搭載したシステムで 2% の値を指定すると、最大 3 GB の RAM を割り当てることができます。

vm.overcommit_memory の値を 2 にすると、PostgreSQL のパフォーマンスが向上します。 この値により、OOM キラー プロセスによって強制終了される重大なリスクを負うことなく、サーバー プロセスの RAM 使用量が最大化されます。 アプリケーションはオーバーランの制限内でのみ再ロードできます。これにより、OOM キラーによってプロセスが強制終了されるリスクが軽減されます。 したがって、値 2 を指定すると、デフォルト値の 0 よりもパフォーマンスが向上します。ただし、範囲外のメモリが過負荷にならないようにすることで、信頼性を向上させることができます。 これにより、OOM キラーによってプロセスが強制終了されるリスクが排除されます。

スワップのないシステムでは、vm.overcommit_memory が 2 に等しいという問題が発生する可能性があります。

https://www.postgresql.org/docs/current/static/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT

vm.dirty_background_ratio / vm.dirty_background_bytes

vm.dirty_background_ratio これは、ディスクに書き出す必要があるダーティページで占められているメモリの割合です。この書き込み処理はバックグラウンドで行われます。このパラメータの値の範囲は0～100ですが、5未満の値は効果がない場合があり、一部のカーネルではサポートされていません。ほとんどのシステムでは、デフォルト値は10です。 Linux比率を小さくすることで、書き込み集中操作のパフォーマンスを向上させることができます。 Linux バックグラウンドで不要なページを消去します。

値を設定する必要があります vm.dirty_background_bytes ドライブの速度によって異なります。

これら 5 つのパラメータはどちらもハードウェアに依存するため、「適切な」値はありません。 ただし、vm.dirty_background_ratio を 25 に設定し、vm.dirty_background_bytes をディスク速度の 25% に設定すると、ほとんどの場合、パフォーマンスが最大 XNUMX% 向上します。

vm.dirty_ratio/dirty_bytes

それと同じです vm.dirty_background_ratio/dirty_background_bytesただし、リセットがワーカー セッションで実行され、アプリケーションがブロックされる点が異なります。 したがって、vm.dirty_ratio は vm.dirty_background_ratio。 これにより、バックグラウンド プロセスがより早く開始され、アプリケーションのブロックが可能な限り回避されます。 ディスク I/O 負荷に応じて、これら XNUMX つの比率の差を調整できます。

合計

他の設定を調整してパフォーマンスを向上させることもできますが、改善は最小限であり、あまりメリットは見られません。 すべてのオプションがすべての種類のアプリケーションに適用されるわけではないことに注意する必要があります。 一部のアプリは、設定を調整するとより適切に動作するものと、そうでないものがあります。 予想されるワークロードとアプリケーションの種類に合わせてこれらの設定を構成する際の適切なバランスを見つける必要があり、チューニングする際には OS の動作も考慮する必要があります。 カーネル パラメータの構成はデータベース パラメータの構成ほど簡単ではなく、推奨事項を作成するのがより困難です。

出所： habr.com