撰写今早ssh连接内网堡垒机发现连接失败，网页端端登录502，怀疑是frp的程序错误，就想直接ssh登录堡垒机宿主重启frpc，发现ssh直接登录也是连接失败，感觉事情不对劲，于是赶紧登录VCenter发现服务器CPU利用率已经100%，这明显不对劲我只能手动强制重启服务器，重启后登录时感觉有点慢以为是docker在启动堡垒机容器就没在意，结果过了一阵cpu利用率又上去了，通过ps命令发现大量frpc进程，于是通过命令：
ps -ef | grep frpc | grep -v grep | wc -l统计出大概580多个frpc进程，怀疑我之前编写的frpc的启动文件有问题，趁服务器还没死透先让frpc禁止开机启动（之前已经写入service，可通过systemctl控制），再次手动重启服务器，重新启动后发现依然有大量frpc进程，我赶快去把frpc的启动文件改了名字，发现进程没有再增长，通过命令：
ps aux|grep frpc|grep -v grep|cut -c 9-15|xargs kill -15
#“ps aux”是linux 里查看所有进程的命令。这时检索出的进程将作为下一条命令“grep python”的输入。
#“grep frpc”的输出结果是，所有含有关键字“frpc”的进程，这是frpc程序
#“grep -v grep”是在列出的进程中去除含有关键字“grep”的进程
#“cut -c 9-15”是截取输入行的第9个字符到第15个字符，而这正好是进程号PID
#“xargs kill -15”中的xargs命令是用来把前面命令的输出结果（PID）作为“kill -15”命令的参数，并执行该令
#“kill -15”会正常退出指定进程，-9强行杀掉批量杀死所有frpc进程后，ps命令看到有个进程提示找不到frpc启动文件，终于找到罪魁祸首了，经过排查发现是通过supervise做了守护进程，这个进程发现frpc没有启动就会进行一次重启，可能是脚本出现问题或者是我更改了systemctl启动，导致脚本程序检测不到frpc已经启动了，所以不停的启动frpc进程，于是我停止了supervise的母程序Daemontools，删除脚本文件，再次启动frpc，发现已经没有异常进程了
到此为止，异常解除，cpu负载也已经回归正常