我正在使用 Postgres 容器来运行一些小型非关键应用程序和站点。它已经稳定了一段时间，但是现在容器在运行了很短的一段时间后就开始消耗一些严重的 CPU。我已经删除了所有其他使用 Postgres 容器的容器，即使在启动一个新实例后，CPU 使用率也会过高。在我的主机 ( docker stats) 中，我看到：
CONTAINER ID NAME
CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS cd553249727d data_postgresql.1.ft2gof5jci25xs5w5uqw6eezi
814.52% 22.11MiB / 46.95GiB 0.05% 129kB / 116kB 0B / 692kB 23
而这个（top）：
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
28923 70 20 0 633580 19664 488 S 696.7 0.0 2408:51 Dp2N
在容器 ( top) 中，我看到：
Mem: 42042244K used, 7183656K free, 3622600K shrd, 1952K buff, 30585480K cached
CPU: 63% usr 9% sys 0% nic 26% idle 0% io 0% irq 0% sirq
Load average: 9.77 9.70 9.66 13/508 11090
PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND
94 1 postgres S 618m 1% 3 58% ./Dp2N <----- WTF?!?!?
53 52 postgres S 1588 0% 1 1% {systemd} /bin/sh ./systemd
47 1 postgres S 163m 0% 8 0% postgres: postgrea67 postgres 10.2
22 1 postgres S 161m 0% 0 0% postgres: autovacuum launcher proc
20 1 postgres S 161m 0% 8 0% postgres: writer process
21 1 postgres S 161m 0% 5 0% postgres: wal writer process
1 0 postgres S 161m 0% 0 0% postgres
19 1 postgres S 161m 0% 8 0% postgres: checkpointer process
23 1 postgres S 19988 0% 1 0% postgres: stats collector process
11081 53 postgres R 1588 0% 4 0% [systemd]
33 0 root S 1576 0% 9 0% sh
52 47 postgres S 1568 0% 10 0% sh -c setsid ./systemd
39 33 root R 1508 0% 11 0% top
11083 11081 postgres Z 0 0% 5 0% [grep]
11084 11081 postgres Z 0 0% 4 0% [awk]
查询活动（不知道做什么select fun308928987('setsid ./systemd')）：
postgres=# select backend_start, usename, application_name, client_addr, client_hostname, query from pg_stat_activity;
backend_start | usename | application_name | client_addr | client_hostname | query
-------------------------------+------------+------------------+-------------+-----------------+-------------------------------------------------------------------------------------------------------------
2018-05-23 07:34:14.694057+00 | postgres | psql | | | select backend_start, usename, application_name, client_addr, client_hostname, query from pg_stat_activity;
2018-05-23 01:26:55.235556+00 | postgrea67 | | 10.255.0.2 | | select fun308928987('setsid ./systemd');
2018-05-23 07:26:03.519231+00 | postgrea67 | | 10.255.0.2 | | select fun308928987('setsid ./systemd');
在服务日志中也有大量出现此错误的实例：
data_postgresql.1.ft2gof5jci25@IS-57436 | ps: bad -o argument 'command', supported arguments: user,group,comm,args,pid,ppid,pgid,etime,nice,rgroup,ruser,time,tty,vsz,stat,rss
如果我终止Dp2N容器内的进程，CPU 使用率会恢复正常，但随后会立即启动该进程。我用谷歌搜索，看看我是否可以找到任何关于 的信息Dp2N，但无济于事。它位于外部安装的卷中：
/ # ls -al /var/lib/postgresql/data/pgdata/Dp2N
-rwxrwxrwx 1 postgres postgres 1886536 May 22 23:25 /var/lib/postgresql/data/pgdata/Dp2N
但据我所知，它似乎是创建的，因为它不是基本图像的一部分。
我正在使用 postgres:9.6.9-alpine。问题从 postgres:9.6.8-alpine 开始，但升级并没有解决它。任何帮助将不胜感激，因为这让我发疯！
额外细节
运行结果file：
sudo file /var/data/pgdata/pgdata/Dp2N
/var/data/pgdata/pgdata/Dp2N: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.24, BuildID[sha1]=bcb5ccf2bc22d1fcb0676506d7c7f31a9b7148bc, stripped
事实证明，Alpine 附带了一个有限版本的ps命令。运行这个：
apk --no-cache add procps
获取增强版本并防止ps日志中的相关错误。我已经更新了 Postgres 图像以包含这个，到目前为止问题还没有重新出现。推测是 CPU 在失败后试图重复执行命令时受到了打击。
诊断
根据下面的答案，事实证明我被黑了。不过，我目前不知道他们是如何进来的。服务器锁定到具有 SSH 证书/无密码访问和禁用 root 的特定用户。（'last' 只显示我的访问权限 - 除非它被黑客入侵。）没有对 postgresql 的公共访问权限。非常强大的数据库管理员密码。目前只能从其他 1 个容器访问。似乎他们是通过服务器上的网站进入的，但在这种情况下只进入容器操作系统，而不是主机操作系统。FWIW 我正在运行一个 Wordpress 站点、Grafana、Kibana、Traefik、Portainer 和我自己的基于 .NET 的 API。我首先从 Wordpress 的调整开始，因为我之前曾经历过与插件相关的感染。
出于教育目的：