最近有个客户XC数据库环境的sys% CPU较高，是一台highgoDB 数据库的ARM linux操作系统，loadavg达到200多，sys%占到80%左右，从ps和top进程能看到有几个postgresql进程和几十个“w”进程，简单的记录这一现象。
把top拍照给AI，豆包说是postgresql进程导致的I/O中断，说是IO负载太大，使用iostat查看对于nvme盘来着200M的吞吐，偶尔上w的iops，不太可能，看来AI总是那么的自洽，不过当时确实是在数据库重建索引，不过是2个窗口并行的创建2000多个索引。
手动从`ps -elf` 分析 看到root用户大量的“w“进程， 但进程持续时间并不长，如果快速跟踪，可以从/proc/xxxx/exe 找到指向/usr/bin/w。 w是操作系统自己的用于查看负载和stty的ssh连接。
进一步分析从ps 从进程PPID 向上可以定位到ssh服务。安装gdb可以使用pstack查看调用进程。
再次查看finalshell创建索引的人打开了40多个窗口，而关掉多余窗口后，sys% CPU占用几乎消失。
从message log能看到有频繁的ssh创建与关闭的输出。
怀疑是finalshell有自在load监控会频繁的调用，server端ssh 配置如果发现ssh timeout断开，但client端又自动创建。