PostgreSQL を最適化するための Linux カーネル オプションの構成

PostgreSQL の最適なパフォーマンスは、正しく定義されたオペレーティング システム パラメータに依存します。 OS カーネル設定が適切に構成されていないと、データベース サーバーのパフォーマンスが低下する可能性があります。 したがって、これらの設定をデータベース サーバーとそのワークロードに応じて構成することが不可欠です。 この記事では、データベース サーバーのパフォーマンスに影響を与える可能性があるいくつかの重要な Linux カーネル パラメーターとその構成方法について説明します。

SHMMAX / SHMALL

SHMMAX Linux プロセスが割り当てることができる単一の共有メモリ セグメントの最大サイズを決定するために使用されるカーネル パラメータです。 バージョン 9.2 より前の PostgreSQL では、SHMMAX 設定が必要な System V (SysV) が使用されていました。 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).

HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter. 
You can either reduce the request size or reconfigure the kernel with larger SHMMAX. To reduce the request size (currently 2072576 bytes),
reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.

If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter,
in which case raising the request size or reconfiguring SHMMIN is called for.

The PostgreSQL documentation contains more information about shared memory configuration. child process exited with exit code 1

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

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

HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter.

You can either reduce the request size or reconfigure the kernel with larger SHMMAX.; To reduce the request size (currently 14385152 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.

If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter,
in which case raising the request size or reconfiguring SHMMIN is called for.

The PostgreSQL documentation contains more information about shared memory configuration.

定義の違いを理解する

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

PostgreSQL は Linux 上のラージ ページのみをサポートします。 Linux はデフォルトで 4 KB のメモリ ページを使用するため、メモリ操作が多すぎる場合は、より大きなページを設定する必要があります。 2 MB から最大 1 GB までの大きなページを使用すると、パフォーマンスの向上が見られます。 大きいページ サイズはブート時に設定できます。 次のコマンドを使用すると、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 に設定されています。これは、ラージ ページが無効になっていることを意味します。

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

この単純なスクリプトは、必要な数のラージ ページを返します。 PostgreSQL の実行中に Linux サーバーでスクリプトを実行します。 環境変数が次であることを確認してください $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 これは、データベースのパフォーマンスに影響を与える可能性があるもう 0 つのカーネル パラメータです。 このオプションは、Linux でのスワップネス (メモリ内およびメモリ外のページのスワップ) の動作を制御するために使用されます。 値の範囲は 100 ～ 100 です。ページングまたはページアウトされるメモリの量が決まります。 XNUMX は交換なしを意味し、XNUMX は積極的な交換を意味します。

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

新しいカーネルでこれを 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 未満の値は効果がない可能性があり、一部のカーネルはそれをサポートしていません。 ほとんどの Linux システムでは 10 がデフォルトです。 書き込み集中型の操作のパフォーマンスをより小さい係数で向上させることができます。これは、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