最近、PostgresデータベースをホストするEC2インスタンスを244GBのi2.8xlargeにアップグレードしました。これは、大量の短命ストレージを利用するためです。アップグレード以来、我々はLinuxカーネルで起こっているメモリ圧縮によるものと思われる、Postgresの待ち時間にいくつか問題がありました。Ubuntu Linuxでのメモリ圧縮中のPostgresの待ち時間の問題
私たちは、次の（うまくいけば、関連するサブセット）を実行している最近のUbuntu 14.04のカーネルコンフィグでPostgreSQL 9.3を使用している：
max_connections = 1000
effective_cache_size = '220GB'
shared_buffers = '24GB'
work_mem = '25MB'
maintenance_work_mem = '1024MB'
fsync = off
full_page_writes = on
synchronous_commit = off
私たちは、このサーバー上完全に無効に透明の巨大なページを持っている（/sys/kernel/mm/transparent_hugepage/enabledと/sys/kernel/mm/transparent_hugepage/defragは両方ともneverに設定し、/sys/kernel/mm/transparent_hugepage/khugepaged/defragを0に設定します）thp_*の統計情報とnr_anon_transparent_hugepagesの統計情報/proc/vmstatが増えないため、THPの結果として問題が発生していないことがわかりました。
私たちの問題はメモリの断片化が悪化おそらくとして（私たちは時間をかけて一定のメモリコンパクション（失敗と成功）/proc/vmstatのイベント（compact_*下のすべての統計情報が頻繁にインクリメント）と悪化これらの原因はかなり深刻な屋台のいくつかを見ることです）、アプリケーションへの影響。 Googleは統計情報を/sys/kernel/debug/extfrag/unusable_indexから追跡しており、ストールを引き起こしているイベントが発生したときに、さまざまなページ注文の間に慌ただしい動きがあることがよくあります。
これは、Postgresのバージョン、Linuxカーネルのバージョン、そして大量のメモリを扱う必要があるのかどうか疑問に思っています。（もちろん、メモリの大半はファイルキャッシュなので、LinuxはPostgresが幸せではないこと）、Postgres（9.4または9.5）のより新しいバージョンが何らかの理由で問題を完全に回避するかもしれないと仮定する以外の何かを思い付くことができませんでした。
$ uname -a
Linux db-01 3.13.0-85-generiC#129-Ubuntu SMP Thu Mar 17 20:50:15 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
$ dpkg -l postgresql-9.3
postgresql-9.3 9.3.12-1.pgdg14.04+1
私たちの設定によれば、 'effective_cache_size' +' shared_buffers' =合計インスタンスメモリーだと思うので、Postgresにメモリの大部分がファイルキャッシュに使用されているとは分かりません複雑なクエリの間に、または一度にDBへの多くの接続があるときに 'work_mem'をスケールアップする必要がある場合。 – WheresWardy
これはhttp://dba.stackexchange.comの方が適しているので、この質問を議論の対象外とすることに投票しています – e4c5
好奇心の漂う、DBのサイズは？同時ユーザーの平均数最大同時ユーザー数？ PostgreSQL 9.5.3を同じ規模のインフラでテストする能力がないと思いますか？ PostgreSQL 9.5にはセッションレベルのフットプリントが小さくなり、何らかのプーリングメカニズムを使用せずに> 500ユーザセッションを推奨しない傾向があります。 – d1ll1nger