我们最近将我们的Postgres数据库的EC2实例升级为具有244GB内存的i2.8xlarge（这是为了利用它附带的大量临时存储）。自升级以来，我们在Postgres中出现了一些延迟问题，这些问题似乎是由于Linux内核中发生的内存压缩造成的。
我们在最近运行以下（希望相关的子集）配置的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而未发现任何问题，因为thp_*中的nr_anon_transparent_hugepages统计信息和/proc/vmstat统计数据永远不会增加。
我们的问题是我们在/proc/vmstat（compact_*频繁增加的所有统计数据）中看到持续的内存压缩（失败和成功）事件，其中一些导致相当严重的失速随着时间的推移变得更糟（可能是因为内存碎片变得更糟）并且对我们的应用程序产生了影响。我们正在跟踪来自/sys/kernel/debug/extfrag/unusable_index的统计信息，并且当我们看到导致失败的事件时，我们经常会看到不同页面顺序之间的一系列移动。
我们想知道这是否仅仅是Postgres版本，Linux内核版本和必须处理大量内存的某种组合（显然大部分内存使用都是文件缓存，因此Linux可能正在做事情因为Postgres并不高兴，但是除了假设更新版本的Postgres（9.4或9.5）之外，还有其他任何东西可以提出任何原因，可能会出于某种原因完全避免这个问题。 / p>
$ 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
答案 0 :(得分：0)
在对DBA StackExchange进行单独讨论之后，建议尝试使用非Trusty（3.13）内核，因此我们使用Trusty上的Xenial HWE（4.4）内核进行了测试，并且事情得到了显着改善，因此它似乎是由于（可能是更新版本的）3.13内核在Trusty中（我们已经在这个内核上使用了一段时间，最近才遇到问题，所以可能已经引入了一些内容）。