postgresql某一个进程占用大量
CPU，问题排查，目前服务器cpu为4核，内存8G
1.查下是不是我们的业务SQL
SELECT
procpid,
START,
now() – START AS lap,
current_query
FROM (SELECT
backendid,
pg_stat_get_backend_pid(S.backendid) AS procpid,
pg_stat_get_backend_activity_start(S.backendid) AS START,
pg_stat_get_backend_activity(S.backendid) AS current_query
FROM (SELECT pg_stat_get_backend_idset() AS backendid) AS S) AS S
WHERE current_query <> ‘<IDLE>’ AND procpid = 35500
ORDER BY lap DESC;
2.linux root shell下面执行updatedb
updatedb 是重建本地文件索引，没有影响
3.locate x2fca82f6
x2fca82f6是占用大量CPU的进程名称，大概是99%左右。
4.查询进程文件所在的目录。
find / -name x2fca82f6
/tmp/x2fca82f6 文件所在的目录和文件名。
5.cat /tmp/x2fca82f6
打开后里面是乱七八糟的内容，该文件很可疑！！！
6.尝试先修改这个文件的执行权限，让他不可运行，然后杀进程，看看对业务有没有影响。
在tmp下面打chmod 600 x2fca82f6 修改成不可修改，该执行文件变成白色。
7.执行ps -ef | grep x2fca82f6 返回进程号35500。
用root用户执行kill语句 kill -9 35500，cpu立马降下来了，变为0.2%左右。
8.CPU肯定是恢复了，现在只需要确认对业务有没有影响就行了，执行一下业务sql，看看刚刚杀的进程对业务是否有影响。
数据库没有报错，但是cpu又上来了。
9.在tmp下面mkdir bak，创建一个备份文件夹，然后把那个进程文件剪切进去
命令：mv x2fca82f6 bak
10.继续 ps -ef | grep x2fca82f6 返回进程号85236。
继续使用root账户kill -9 85236
11.继续操作业务sql，看看还能起来不，或者数据库是否报错，后来看都正常。
过了一会发现cpu又上来了。
12.猜测有程序能预编译这个东西…
13.查询下后台在运行的sql语句吧，能自动预编译应该是PGSQL自己编译的程序
发现没有业务sql，都是一些系统sql
SELECT
procpid,
START,
now() – START AS lap,
current_query
FROM (SELECT
backendid,
pg_stat_get_backend_pid(S.backendid) AS procpid,
pg_stat_get_backend_activity_start(S.backendid) AS START,
pg_stat_get_backend_activity(S.backendid) AS current_query
FROM (SELECT pg_stat_get_backend_idset() AS backendid) AS S) AS S
WHERE current_query <> ‘<IDLE>’
ORDER BY lap DESC;
14.建一个查询死锁和慢sql的视图，sql语句太大了，就不列出来了。
建好之后发现没有查出数据。
15.执行如下sql语句
select nspname from pg_namespace where nspname like ‘pg_temp%’
发现也没有数据，就算了。
16.执行如下sql，有就删除，没有就算了
drop schema if exists pg_temp_1 cascade;
17.查看一下数据库连接数
select count( * ) from pg_stat_activity where state not like ‘%idle’;
返回1，说明正常。
18.猜测postgresql数据库没有安装好，或者是配置有问题。
19.执行如下sql
select * from pg_stat_user_tables where n_live_tup > 100000 and seq_scan > 0 order by seq_tup_read desc limit 10;
发现返回数据为空。
20.最后升级了服务器的cpu和内存到8核和32G，然后重启了该数据库服务器，后面cpu一直都是0.2%左右，一直到第二天早上都很稳定。
21.进入/tmp/目录，把文件改名
mv x2fca82f6 xx2fca82f6_bak
22.ps auxw | grep postgres | grep — -D 返回结果如下：
postgres 45123 0.0 0.0 340208 15396 ? S 2017 0:06 /usr/pgsql-9.5/bin/postgres -D /var/lib/pgsql/9.5/data
24.cd pg_log
里面都是
postgresql日志文件
25.分析日志里面文件里面的内容来查找端倪，完事。
26.本文为虾米哥原创，转载请注明来源地址www.itxm.net
27.本文原文链接：http://www.itxm.net/a/shujuku/2018/0102/1481.html，转载请注明来源地址，谢谢！
转载请注明来源网站:blog.ytso.com谢谢！
原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/4507.html