sd-pam进程像疯狂的野兽吞噬着CPU。去研发大群里询问，没有人能说清楚sd-pam进程是什么来头。疑云骤起，关注点向sd-pam进程聚焦。
2.3 举手解内困提交PR还得仰仗JIRA服务，JIRA服务是运行在Docker容器内的。登录到JIRA容器，查看Java虚拟机参数，堆空间最大可用缺省值是768MB，对于JIRA服务来说显然偏低。而云服务器16GB内存还有10GB以上的空闲，闲着也是闲着，堆空间最大可用值拟修改为2GB。因为运行环境和文件权限问题，在容器内不好修改文件，所以用docker cp命令把环境设置文件setenv.sh拷贝到宿主机，修改后拷贝回JIRA容器。
在大群里喊一嗓子，要重启JIRA服务了，没人理，过几分钟就reboot云服务器了。
重启后，JIRA服务的配置会生效，JVM堆空间会扩大，对改善JIRA服务会有帮助。我也想看看云服务器重启后，sd-pam进程会不会还在。
修改JIRA配置与黑客对战没啥关系，不过是举手解JIRA之困境。
3、循迹清木马 3.1 初识两点疑
重启云服务器后，sd-pam进程依然顽固地存在，撒着欢一样把CPU利用率拱到满格400%。
“你来或不来我都在这里，不多不少，4个CPU全是我的菜。” 清哥哥感觉被挑衅了，看来得好好伺候这位爷了。
思绪开始往木马、蠕虫方向去想了。但凡木马都不是孤立的，要与外界联系，云服务器联系外界唯一的通道是网络通信。我想看看sd-pam都联系了哪些网络地址。实用工具lsof能查看进程打开的所有文件描述符。文件描述符有点抽象，但是说建立的TCP连接、打开的文件/目录、建立的管道都是文件描述符，就不难理解了。而进程打开的文件和建立的TCP连接正是我想知道的，以后有妙用。
在CentOS上，缺省地没有安装实用命令lsof，通过yum自动下载安装。
1 yum install -y lsof