我们正在运行一个大约 38GB 的 Postgres DB,托管在 68GB 的 EC2 实例上。它一直运行良好,负载约为 0.7(在 8 核机器上),CPU 使用率很小,直到大约 16 小时前,CPU 使用率在几个小时内急剧上升,现在比以前高得多(约占总量的 20%),平均负载也相应增加(现在在 5 到 8 之间)。
根据 pg_stat_activity,该机器同时有 100 到 300 个连接。我们最大的表(包括索引)大约有 9.0GB。
以下是我们排除的可能:
- pg_top 显示始终有几个线程以较高的 CPU 百分比运行,而它们下面的其余线程看起来都很好。那里的 SELECT 和 INSERT 没有什么异常。
- IOWait 根本没有增加,而且似乎我们并没有更频繁地访问磁盘
- 据我们所知,使用模式没有改变;事实上,周一比周末慢
- 我们增加了 memcached 实例的大小,但无济于事
- 我们关闭了synchronous_commit,但这也没有多大帮助,
- 我们尝试过增加和减少共享缓冲区(目前设置为 2GB);4GB 和 1GB 都没有改善情况
- 重新启动 postgres 和所有 apache 服务器没有帮助
- 重新启动 pgbouncer(我们的 Apache/Django 盒子用它来与 Postgres 通信)也无济于事
- 我们所有的主要查询都有正确的索引,并且我们已经验证了 postgres 正在使用它们。为了安全起见,我们运行了 VACUUM ANALYZE,查询规划器看起来正在做正确的事情
- 查询在几秒钟内会很顺利,然后似乎被锁定了;通常需要 200 毫秒或更短时间的索引扫描将需要整整几秒钟。
关于如何进行或追踪此问题,您有什么想法吗?
答案1
如果可以,请短时间(约 10 分钟)打开完整日志记录。保存日志,然后让 pgfouine (http://pgfouine.projects.postgresql.org/)进行分析。您可能正在执行比以前更多的查询,或者您正在执行效率不高的查询。
接下来,您可能会遇到一些慢查询,从而对系统造成严重影响。查看当前正在运行哪些查询:
SELECT pg_stat_activity.procpid AS pid, pg_stat_activity.usename AS username, pg_stat_activity.waiting, now() - pg_stat_activity.query_start AS age, pg_stat_activity.current_query AS query FROM pg_stat_activity WHERE pg_stat_activity.current_query <> '<IDLE>'::text ORDER BY now() - pg_stat_activity.query_start DESC;
查找列表顶部的查询。其中一个查询是否已经运行了很长时间?如果您有一个交易已经打开了 16 个小时以上,它肯定会使速度变慢很多。