我们遇到了一个问题，那就是我们的Linux机器（Ubuntu 10.04 LTS，在EC2上运行，具有四倍大小，68GB RAM和8个虚拟核心，每个3.25GHz）每隔几秒就冻结一次。 在ssh会话中键入将会冻结，并在运行的Postgresql进程之一上运行strace通常会显示：
02:37:41.567990 semop(7831581, {{3, -1, 0}}, 1 在它进行之前几秒钟（它总是卡在那个semop）。
OProfile显示，大部分时间都花在内核（60％）上，而Postgresql中只有37％。
这些暂停（前一天突然开始）的结果是，箱子上的负载已经从0.7增加到了10+，并导致我们整个栈缓慢完成。
任何想法如何追查是怎么回事？ iostat不显示磁盘特别慢或超负荷，并且顶部显示每当这些备份发生时，用户CPU峰值从8％到大约40％。
我怀疑你的系统没有信号量了。 检查ipcs -l的当前设置。 这里有一些关于调整postgresql的信号量的信息 。 特别是我会尝试增加系统信号（SEMMNS）的最大数量和每套信号（SEMMSL）的最大数量。 您可以使用sysctl -p来修改这些设置。
看看这个问题Linux 256GB的mem / 48内核 – 机器开始thrashing /窒息与大量的内存剩下 ，看看有关大量的内存有关mysql和交换疯狂的链接有帮助。
既然你已经把大部分时间花在内核上了，我build议启用CONFIG_LATENCYTOP并运行latencytop来查看更多内容。 也可以用oprofile完成，但是latencytop方式更方便。
考虑到“68GB内存”，我怀疑这与虚拟机效率低下有关。 你有没有尝试重新启动Postgresql或重新启动？
当我们首次将我们的Oracle服务器部署在96Gb内存的服务器上时，我们遇到了类似的问题（不同之处在于间隔时间相差很远）。 我们最终跟踪了内核进程，负责识别可能被调出的内存。 设置进程检查更小的块更经常照顾到这个问题。
发生这种情况时请检查您的可用熵：
cat / proc / sys / kernel / random / entropy_avail
Ubuntu似乎有一个坏习惯，在不需要的时候需要系统中真正的随机数字，这可能会导致这样的情况。 试着让硬件随机数发生器工作，如果你有问题，它会使问题消失。
我们最终将其追踪到PostgreSQL设置：“work_mem”，它设置每个Postgres进程得到的RAM数量。 我们正在泄露（微小的）默认值，这使系统碰到了磁盘，这是EC2上的死亡之吻（并且磁盘活动突然激增，迅速爆发了内核）。