PostgreSQLは、すべてのRAM

Question

PostgreSQL 9.4.1サーバーでパフォーマンスの問題が発生しています。通常のベストプラクティス（pgtune + google）を使用してサーバーを調整しました。関連する設定は次のとおりです。

# <snip> the default config above

default_statistics_target = 50
maintenance_work_mem = 960MB
constraint_exclusion = on
checkpoint_completion_target = 0.9
effective_cache_size = 11GB
work_mem = 96MB
wal_buffers = 8MB
checkpoint_segments = 16
shared_buffers = 4GB
max_connections = 200

autovacuum = on
log_autovacuum_min_duration = 10000
autovacuum_max_workers = 5
autovacuum_naptime = 1min
autovacuum_vacuum_threshold = 50
autovacuum_analyze_threshold = 25
autovacuum_vacuum_scale_factor = 0.2
autovacuum_analyze_scale_factor = 0.1
#autovacuum_freeze_max_age = 200000000
autovacuum_vacuum_cost_delay = 20ms
autovacuum_vacuum_cost_limit = -1

#log_statement='mod'
#log_statement='all'

logging_collector = on

ただし、高負荷時にはクエリのパフォーマンスが非常に低下します。同時に、RAMの合計使用量は4GBです（16GBのうち利用可能）。

これら二つの問題が関係していると思わずにはいられません。そして、pgが利用可能なRAMのより多くを利用するだけなら、そのパフォーマンスは向上します。

サーバーはIntel（R）Xeon（R）CPU E3-1240 v3 @ 3.40GHz、16GB RAMです。 2つのディスク（WDC WD1003FBYZ-0）がありますが、RAIDはありません。パフォーマンスの問題があるDBは、テーブルスペースを使用してこれらのディスク間で分割されます。 OSはDebian 7.5です。

それで、私が見逃した明らかなことはありますか？私は間違った木を吠えていますか？それとも、ここには本当に怪しいものがありますか？

Answer 1

PostgreSQLは、ほとんどのキャッシュでオペレーティングシステムのディスクキャッシュに依存しています。このキャッシュは通常、ほとんどのツールで「空き」と報告されますRAMほとんどのツールでは、最新のオペレーティングシステムは現在空​​き容量の少ないものをすべて使用しているため、RAMキャッシュ。

これは正常です。

確認するには、本当に空きメモリとは別にバッファ/キャッシュを表示する、より優れたツールを使用します。 Linuxでは、free -mに詳細情報が表示されます。

また、ほとんどのシステムでは、共有メモリのアカウンティングは、PostgreSQLプロセスで報告されるメモリ使用量がかなり偽であることを意味します。それらは、プロセスが使用するすべての共有メモリをカウントする傾向があるため、各共有メモリページを何回もカウントします。または、共有メモリをまったくカウントせず、完全に無視する傾向があります。 PostgreSQLの実際のメモリ使用量を見積もる最良の方法は、各プロセスの非共有メモリ使用量を取得し、それらを合計して、合計にshared_buffersサイズを追加することです。

ところで、shared_buffersは2次レベルのキャッシュです。そこにクリーンなバッファがあると、OSのディスクキャッシュにあるものと重複する可能性があります。したがって、最適なシステムとワークロード固有のサイズがあります。小さすぎて、読み込むための空きページを見つけるのに苦労し始めているか、効率的な書き込みを組み合わせるにはダーティバッファを早すぎるものに強制している。大きすぎて、OSのディスクキャッシュからクリーンページをダブルキャッシュしすぎる。