shmall、shmmax、shmminなどを設定する方法…一般的に、postgresqlの場合

私はPostgreSQLのドキュメントを使用して、たとえばこの構成を設定しました：

>>> cat /proc/meminfo 
MemTotal:       16345480 kB
MemFree:         1770128 kB
Buffers:          382184 kB
Cached:         10432632 kB
SwapCached:            0 kB
Active:          9228324 kB
Inactive:        4621264 kB
Active(anon):    7019996 kB
Inactive(anon):   548528 kB
Active(file):    2208328 kB
Inactive(file):  4072736 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:              3432 kB
Writeback:             0 kB
AnonPages:       3034588 kB
Mapped:          4243720 kB
Shmem:           4533752 kB
Slab:             481728 kB
SReclaimable:     440712 kB
SUnreclaim:        41016 kB
KernelStack:        1776 kB
PageTables:        39208 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     8172740 kB
Committed_AS:   14935216 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      399340 kB
VmallocChunk:   34359334908 kB
HardwareCorrupted:     0 kB
AnonHugePages:    456704 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       12288 kB
DirectMap2M:    16680960 kB

>>> ipcs -l          

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

------ Semaphore Limits --------
max number of arrays = 128
max semaphores per array = 250
max semaphores system wide = 32000
max ops per semop call = 32
semaphore max value = 32767

------ Messages Limits --------
max queues system wide = 31918
max size of message (bytes) = 8192
default max size of queue (bytes) = 16384

私が計算したsysctl.conf抽出：

kernel.shmall = 1079204
kernel.shmmax = 4420419584

postgresql.conf non defaults、私が計算：

max_connections = 60            # (change requires restart)
shared_buffers = 4GB            # min 128kB
work_mem = 4MB              # min 64kB
wal_sync_method = open_sync     # the default is the first option
checkpoint_segments = 16        # in logfile segments, min 1, 16MB each
checkpoint_completion_target = 0.9  # checkpoint target duration, 0.0 - 1.0
effective_cache_size = 6GB

これは適切ですか？そうでない場合（または必ずしもそうでない場合）、どの場合が適切ですか？

私たちはこの設定で素晴らしいパフォーマンスの改善に気づきました、どのようにそれを改善しますか？

カーネルメモリ管理パラメータの計算方法は？

誰かが実際にそれらを最初から設定する方法を説明できますか？

私はここで別の質問に対してこれに答えました：

Gitがエラー「メモリ不足」でプッシュに失敗する

ここではすべての質問に答えるのではなく、タイトルにある質問に答えます。

shmall、shmmax、shmmniなどを設定する方法…一般的に、postgresqlの場合

一部のカーネルディストリビューションでは、カーネルが最大メモリを単一プロセスに割り当てないようにする設定があります。

カーネルパラメータの設定

/etc/sysctl.confファイルを変更して、オペレーティングシステムに適した行を含めます。

# Red Hat Enterprise Linux 3.0 and CentOS 3.x 
kernel.shmmax = 2147483648
kernel.shmmni = 4096
kernel.shmall = 2097152
kernel.shmmin = 1
kernel.shmseg = 10

# semaphores: 
semmsl, semmns, semopm, semmni kernel.sem = 250 32000 100 128
fs.file-max = 65536

# Red Hat Enterprise Linux 4.0 and CentOS 4.x 
kernel.shmmax = 536870912
kernel.shmmni = 4096
kernel.shmall = 2097152

プロセスが制限を超えると、システムで使用可能な最大メモリが報告されていても、カーネルはプロセスを強制終了します。

注：これらの設定には注意してください。私たちの環境のサーバーから設定をプルしたので、おそらくその例の設定を使用したくないでしょう。

言及すべきいくつかの追加のメモ：

sysctlを使用してカーネル設定を更新およびテストするには、次のコマンドを使用します。

現在の設定を一覧表示します。

sysctl -A | grep shm
sysctl -w kernel.shmmax=<value> to write in sysctl.conf
sysctl -p /etc/sysctl.conf to read/reload the values from sysctl.conf

/etc/selinux/configファイルを編集してセキュアLinuxを無効にし、SELINUXフラグが次のように設定されていることを確認します。

SELINUX=disabled

これは適切ですか？そうでない場合（または必ずしもそうでない場合）、どの場合が適切ですか？

ISPプロバイダーが共有サーバー上のすべてのリソースを独占する単一の顧客プロセスを望まない場合、カーネル設定は通常、データセンター環境でより厳密に定義されます。

リソース不足によりカーネルによって強制終了されているプロセスがない限り、通常はカーネルメモリパラメータを設定する必要はありません。

場合によっては、postgresは共有メモリで利用可能なメモリよりも多くのメモリを特定のページサイズに割り当てることもできます。

* The PostgreSQL server failed to start. Please check the log output:
2011-11-04 05:06:26 UTC FATAL: could not create shared memory segment: Invalid
argument
2011-11-04 05:06:26 UTC DETAIL: Failed system call was shmget(key=5432001, size
=161849344, 03600).
2011-11-04 05:06:26 UTC HINT: This error usually means that PostgreSQL’s reques
t 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 161849344 bytes), reduce PostgreSQL’s shared
_buffers parameter (currently 19200) and/or its max_connections parameter (curre
ntly 53).
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 recon
figuring SHMMIN is called for.
The PostgreSQL documentation contains more information about shared memo
ry configuration.
…fail!

上記の例のようなエラーは、カーネルリソースの設定を調整することで解決できます。リソース設定を決定するための推奨設定と方法について、ここで詳しく説明します。

http://www.postgresql.org/docs/9.1/static/kernel-resources.html

ただし、postgresプロセスに関連するリソース不足の状況に遭遇しない限り、これらの設定に触れる必要はありません。これらの状況は、ほとんどの場合、リソースがほとんど割り当てられていない共有環境またはサーバーで発生します。

誰かが実際にそれらを最初から設定する方法を説明できますか？

Postgresのチューニングについては、これを読む必要があります：

http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server

ああ！！ここで、postgresqlサーバーのoptimus mem構成を計算するための素晴らしいツールを見つけました。

http://pgtune.leopard.in.ua/

これらのカーネル構成はグローバルであり、プロセス固有ではないため、で設定するのが適切sysctl.confです。

サーバーで何が実行されているかによって異なりますが、これが純粋なPostgreSQLサーバーである場合、PostgreSQLはこれらの設定を探すのに最適な場所です。
特定のメモリが必要な他のアプリケーション/サービスを実行している場合は、これらの異なるアプリケーション間で最適な設定を見つける必要があります。

データベースのパフォーマンスが向上し、他のアプリケーションのパフォーマンスが低下しない場合は、これについて心配する必要はありません。

一般に、データベースはメモリ設定に最も敏感です。データベースはアプリケーションパフォーマンスのボトルネックである可能性が高いため、DB用にシステムを最適化することは理にかなっています。