记一次公网postgresql数据库服务器被入侵为矿机的定位过程

今天中午群里有一个群友反馈pg服务器cpu使用率高达1700%，处于好奇自己就帮着他一起定位了一下问题，以下记录一下定位问题的过程方便以后做复盘管理！

现象截图如下：

一、查看cpu情况和服务器平均负载情况得知各个cpu的使用率并不是很高呀，为什么执行top命令看到postgresql进程的cpu使用是1700%呢？没有头绪我们继续往下看

二、查看一下服务器的负载情况呢

有问题了，你服务器是32个cpu，负载到了38了，而且一直在增长，猜测是是因为多个线程或者进程抢占cpu，导致的cpu上线问切换频繁，并且进程和线程在不停的增长

三、vmstat 5看一下操作系统cpu的上下文切换情况嗯

r代表的是等待或者正在cpu中执行的进程数，进程数一直在递增，in代表的是操作系统中断的次数，cs是cpu上下文切换的次数，从数据来看就是验证了我的猜测结果

四、接着想看一下postgresql进程的cpu上下文切换情况呢，不知道为啥看不到，可能是因为我命令用错了吧！！！
pidstat -u -p 64804

到了这一步没有了思路了，从现象看postgresql的cpu使用率很高，但是定位不到具体的原因，群里有大佬提醒这台服务器可能是被入侵当做了矿机了，好，按照大佬的思路我们继续用strace跟踪下postgresql这个进程的内核调用情况

想办法把进程杀了吧，中毒了，坑了，一直在做io操作，真是被挖矿了，
从内核调用情况看postgresql进程在不停的创建进程调动IO操作，同时还给cpu进行了加锁操作！！

以上也是我这边粗略的理解，很多问题没想明白！

比如：频繁的IO操作和锁操作为什么会导致CPU的占用那么高，但是用top看的话id是100%呢？

需要优化的部分为：

定位问题的思路不清晰，本身已经通过top命令定位到了有问题的进程是postgresql了，不知道如何深入找到postgresql进程导致高cpu使用率的底层原因，本来是打算用pidstat看一下进程的资源情况，但是查询不到结果无奈只能用strace查看进程的内核调用情况

隐隐感觉到自己定位问题的逻辑一堆漏洞，却又找不到漏洞在哪里，对操作系统底层的相关知识太薄弱