postgresql某一個(gè)進(jìn)程占用大量

CPU，問題排查，目前服務(wù)器cpu為4核，內(nèi)存8G

1.查下是不是我們的業(yè)務(wù)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 <> '' AND procpid = 35500

ORDER BY lap DESC;

2.linux root shell下面執(zhí)行updatedb

updatedb 是重建本地文件索引，沒有影響

3.locate x2fca82f6

x2fca82f6是占用大量CPU的進(jìn)程名稱，大概是99%左右。

4.查詢進(jìn)程文件所在的目錄。

find / -name x2fca82f6

/tmp/x2fca82f6 文件所在的目錄和文件名。

5.cat /tmp/x2fca82f6

打開后里面是亂七八糟的內(nèi)容，該文件很可疑！！！

6.嘗試先修改這個(gè)文件的執(zhí)行權(quán)限，讓他不可運(yùn)行，然后殺進(jìn)程，看看對業(yè)務(wù)有沒有影響。

在tmp下面打chmod 600 x2fca82f6 修改成不可修改，該執(zhí)行文件變成白色。

7.執(zhí)行ps -ef | grep x2fca82f6???? 返回進(jìn)程號(hào)35500。

用root用戶執(zhí)行kill語句 kill -9 35500，cpu立馬降下來了，變?yōu)?.2%左右。

8.CPU肯定是恢復(fù)了，現(xiàn)在只需要確認(rèn)對業(yè)務(wù)有沒有影響就行了，執(zhí)行一下業(yè)務(wù)sql，看看剛剛殺的進(jìn)程對業(yè)務(wù)是否有影響。

數(shù)據(jù)庫沒有報(bào)錯(cuò)，但是cpu又上來了。

9.在tmp下面mkdir bak，創(chuàng)建一個(gè)備份文件夾，然后把那個(gè)進(jìn)程文件剪切進(jìn)去

命令：mv x2fca82f6 bak

11.繼續(xù)操作業(yè)務(wù)sql，看看還能起來不，或者數(shù)據(jù)庫是否報(bào)錯(cuò)，后來看都正常。

過了一會(huì)發(fā)現(xiàn)cpu又上來了。

12.猜測有程序能預(yù)編譯這個(gè)東西...

13.查詢下后臺(tái)在運(yùn)行的sql語句吧，能自動(dòng)預(yù)編譯應(yīng)該是PGSQL自己編譯的程序

發(fā)現(xiàn)沒有業(yè)務(wù)sql，都是一些系統(tǒng)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 <> ''

ORDER BY lap DESC;

14.建一個(gè)查詢死鎖和慢sql的視圖，sql語句太大了，就不列出來了。

建好之后發(fā)現(xiàn)沒有查出數(shù)據(jù)。

15.執(zhí)行如下sql語句

select?nspname?from?pg_namespace?where?nspname?like?'pg_temp%'

發(fā)現(xiàn)也沒有數(shù)據(jù)，就算了。

16.執(zhí)行如下sql，有就刪除，沒有就算了

drop?schema?if?exists?pg_temp_1?cascade;

17.查看一下數(shù)據(jù)庫連接數(shù)

select count( * ) from pg_stat_activity where state not like '%idle';

返回1，說明正常。

18.猜測postgresql數(shù)據(jù)庫沒有安裝好，或者是配置有問題。

19.執(zhí)行如下sql

select * from pg_stat_user_tables where n_live_tup > 100000 and seq_scan > 0 order by seq_tup_read desc limit 10;

發(fā)現(xiàn)返回?cái)?shù)據(jù)為空。

20.最后升級(jí)了服務(wù)器的cpu和內(nèi)存到8核和32G，然后重啟了該數(shù)據(jù)庫服務(wù)器，后面cpu一直都是0.2%左右，一直到第二天早上都很穩(wěn)定。

21.進(jìn)入/tmp/目錄，把文件改名

mv x2fca82f6 xx2fca82f6_bak

22.ps auxw |? grep postgres | grep -- -D????? 返回結(jié)果如下：

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.分析日志里面文件里面的內(nèi)容來查找端倪，完事。

26.本文為蝦米哥原創(chuàng)，轉(zhuǎn)載請注明來源地址www.itxm.net

27.本文原文鏈接：http://www.itxm.net/a/shujuku/2018/0102/1481.html，轉(zhuǎn)載請注明來源地址，謝謝！

轉(zhuǎn)載請注明來源網(wǎng)站:www.itxm.cn謝謝！

總結(jié)

以上是生活随笔為你收集整理的linux查找postgre进程,postgresql数据库某一个进程占用大量CPU，问题排查详解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。