问题描述

公司项目测试环境调用某些接口的时候，服务器立即崩溃，并一定时间内无法提供服务。

问题排查

服务器配置不够

第一反应是服务器需要升配啦，花钱解决一切！毕竟测试服务器配置确实不高，2CPU + 4Gib，能干啥？不过问题是今天突然发生的，而且说崩就崩。凭着严谨的态度，还是要刨根问底地找下问题。

查看服务器负载

free -m

内存占用并不大，忘记截图了，反正看下来不是内存过高导致的崩溃

top

数据库占用CPU过高

连接数过多

业务高峰活跃连接陡增，活跃的连接数是否比平时多很多

SELECT 
  COUNT(*) 
FROM 
  pg_stat_activity 
WHERE 
  STATE NOT LIKE '%idle';

查询下来只有3个连接，所以不是连接数导致的CPU过高

慢SQL

如果活跃连接数的变化处于正常范围，则可能是当时有性能很差的SQL被大量执行。

select 
  datname, 
  usename, 
  client_addr, 
  application_name, 
  state, 
  backend_start, 
  xact_start, 
  xact_stay, 
  query_start, 
  query_stay, 
  replace(
    query, 
    chr(10), 
    ' '
  ) as query 
from 
  (
    select 
      pgsa.datname as datname, 
      pgsa.usename as usename, 
      pgsa.client_addr client_addr, 
      pgsa.application_name as application_name, 
      pgsa.state as state, 
      pgsa.backend_start as backend_start, 
      pgsa.xact_start as xact_start, 
      extract(
        epoch 
        from 
          (now() - pgsa.xact_start)
      ) as xact_stay, 
      pgsa.query_start as query_start, 
      extract(
        epoch 
        from 
          (now() - pgsa.query_start)
      ) as query_stay, 
      pgsa.query as query 
    from 
      pg_stat_activity as pgsa 
    where 
      pgsa.state != 'idle' 
      and pgsa.state != 'idle in transaction' 
      and pgsa.state != 'idle in transaction (aborted)'
  ) idleconnections 
order by 
  query_stay desc 
limit 
  5;

可以看到，确实有一条慢SQL，而且属于奇慢无比，执行了接近1分钟还没执行完毕，基本可以定位，是慢SQL导致的CPU占用陡增。

问题解决

对于上面的方法查出来的慢SQL，首先需要做的是Kill掉他们，使业务先恢复。

select pg_cancel_backend(pid) from pg_stat_activity where  query like '%%' and pid != pg_backend_pid();
select pg_terminate_backend(pid) from pg_stat_activity where  query like '%%' and pid != pg_backend_pid();

如果这些SQL确实是业务上必需的，则需要对他们做如下优化：

对查询涉及的表，执行ANALYZE 或VACUUM ANZLYZE ，更新表的统计信息，使查询计划更准确。为避免对业务影响，最好在业务低峰执行。执行explain 或explain (buffers true, analyze true, verbose true) 命令，查看SQL的执行计划（前者不会实际执行SQL，后者会实际执行而且能得到详细的执行信息），对其中的Table Scan涉及的表，建立索引。重新编写SQL，去除掉不必要的子查询、改写UNION ALL、使用JOIN CLAUSE固定连接顺序等，都是进一步深度优化SQL的手段，这里不再深入说明。总结在查询语句中，尽量减少不必要的子查询，公司使用的ORM框架是Spring JPA，针对一些特别慢的HQL，可以采用直接执行SQL的方式来优化查询效率。 @Query(value = "select count(*) from example_table where example_id = :exampleId", nativeQuery = true) int exampleNativeQuery(@Param("exampleId") Long exampleId); 参考 PostgreSQL/PPAS CPU使用率高的原因及解决办法阅读原文内容投诉免责声明： ① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的，并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据，供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。 ② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341 软考中级精品资料免费领历年真题答案解析备考技巧名师总结高频考点精准押题资料下载历年真题 2024上半年软考中级软件测评师考试基础知识真题 193.9 KB下载数265 2024上半年软考中级软件设计师考试基础知识真题 191.63 KB下载数245 2023下半年-系统集成项目管理工程师-真题考点汇总（完整版） 143.91 KB下载数1148 2023年下半年系统集成项目管理工程师第一、二、三批次真题考点整理(考友回忆版) 183.71 KB下载数642 2023年上半年软考中级《系统集成项目管理工程师》-基础知识-考试真题及答案 644.84 KB下载数2756 2024年上半年信息系统项目管理师第二批次真题及答案解析（完整版）难度 813人已做查看【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析难度 354人已做查看【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析难度 318人已做查看 2024年上半年软考高项第一、二批次真题考点汇总（完整版）难度 435人已做查看 2024年上半年系统架构设计师考试综合知识真题难度 224人已做查看相关文章发现更多好内容软考中项会降分吗？2024下半年系统集成项目管理工程师合格分是多少？软考信监会降分吗？2024下半年信息系统监理师合格分是多少？软考中级多少分过？软考中级合格标准分数线软考初级多少分过？软考初级合格标准分数线 2024下半年软考中项成绩合格标准是多少？软考多少分过？软考合格标准分数线软考网络员会降分吗？2024下半年网络管理员合格分是多少？软考信安会降分吗？2024下半年信息安全工程师合格分是多少？软考信息系统员会降分吗？2024下半年信息系统运行管理员合格分是多少？ 2024下半年软考高级成绩合格标准是多少？猜你喜欢 AI推送时光机记一次Postgres CPU爆满故障数据库2020-03-22 记一次磁盘空间爆满导致的持久化报错数据库2024-04-02 记一次线程爆满导致服务器崩溃的问题排查及解决数据库2022-11-13 记一次由mysql触发器引发的故障数据库2024-04-02 一次Mysql update sql不当引起的生产故障记录数据库2024-04-02 HP-UX上一次Oracle软件安装目录磁盘空间满导致的故障数据库2024-04-02 记一次存储故障导致数据库坏块处理过程数据库2024-04-02 位置：首页-资讯-数据库咦！没有更多了？去看看其它编程学习网内容吧首页课程资料下载问答资讯

文章详情

记一次Postgres CPU爆满故障

问题描述

问题排查

服务器配置不够

查看服务器负载

数据库占用CPU过高

连接数过多

慢SQL

问题解决

总结

参考

软考中级精品资料免费领

相关文章

猜你喜欢

记一次Postgres CPU爆满故障

记一次磁盘空间爆满导致的持久化报错

记一次线程爆满导致服务器崩溃的问题排查及解决

记一次由mysql触发器引发的故障

一次Mysql update sql不当引起的生产故障记录

HP-UX上一次Oracle软件安装目录磁盘空间满导致的故障

记一次存储故障导致数据库坏块处理过程