99%的人都不知道的ssh访问缓慢原因

最新推荐文章于 2024-06-11 13:27:06 发布

qiubinwei

最新推荐文章于 2024-06-11 13:27:06 发布

阅读量1.5k

点赞数 21

文章标签：前端

本文链接：https://blog.csdn.net/qiubinwei/article/details/135309430

版权

接到小伙伴信息，说生产有一台sftp的服务器，近期用户在使用sftp的时候发现登录时间特别慢，从输入用户名密码后到login成功，期间会有4-8秒左右的等待时间。此外使用su命令和ssh命令的时候都存在类似问题。需要协助一起排查一下。

耳听为虚，眼见为实。登录服务器，瞬间就感觉到了的确很慢，光登录等待就花了6秒左右。结合问题描述的现象，首先开始三板斧。vmstat，pidstat，iostat。

#vmstat 1 观察30秒

从vmstat的结果来看，第一列r(run)和第二列(Block)的进程数量不超过2个，说明进程队列基本没有阻塞情况，cpu调度没有瓶颈。

#iostat -x -t -m 1 观察30秒

查看磁盘读写，iowait，发现指标都非常小，没有压力。

#pidstat 1 观察30秒

从每秒信息看，发现每秒都有ssh的进程，cpu使用率达到100%左右，持续1-2秒，随后就降下去了，ssh的pid都不太一样。

综上所述，收集完一圈信息以后，初步判断登录卡顿的问题主要出现在ssh进程占用了较大CPU开销，所以导致了登录卡顿。为了验证判断，通过top观察了1分钟左右，进一步佐证了观点，不时会有不同pid进程号的ssh进程CPU使用率达到100%，随后再消失。

完成出诊后，关注点主要放在ssh进程上，由于ssh进程都是“短命鬼”，sftp上来拿个小文件就退出了。琢磨了一下，最有效的方法就是用strace工具抓取一下那4-8秒的ssh进程到底在做什么。

于是果断开了两个终端，一个使用top观察ssh的进程号（暂时没有想到比较好的自动抓取CPU冲高的pid号，就只能靠人肉了），另一个终端就输入“strace -T -f -tt -e trace=all -o try.txt -p [pid]”,随时准备把pid输入进去按回车。

在经过类似以上几次报错后，终于成功的抓住了一个pid的尾巴。

cat try.out | wc -l 可以看到，这个文件有80w行左右，其中从第79.8w行开始有正常的ssh登录的输出，而其中的前79.8w行都是相同的read系统函数调用

每个read函数调用开销为0.000013秒左右，80w次调用累计耗时10秒左右，比之前的更长，这个耗时变长的原因主要是因为使用了strace追踪，导致开销时间变长。

那么下一步的问题来了，这个read主要是读取了什么函数呢？

当你输入strace -h时，可以看到有一个参数叫做-yy, 会打印出read、write文件的具体信息

-yy, --decode-fds=all print all available information associated with file descriptors in addition to paths

一不做，二不休，安排！

strace -T -f -tt -yy -e trace=all -o try.txt -p [pid]

重新抓住一个ssh pid的进程号后，strace了20秒，ssh进程居然还没有结束。。。。。吓得我赶紧中断了strace命令（毕竟是生产环境），看了加了-yy的参数以后，对于原ssh进程的性能还是有比较大的影响的，也就是20多秒都么有完成登录。。。

继续查看strace结果文件。

发现ssh进程不停地在read调用读取/var/log/btmp文件。

du -sm /var/log/btmp，发现这个文件有1.8GB的大小。

btmp文件是记录用户登录错误信息的二进制文件，可以通过lastb命令进行信息查看。文件越大，代表经常有用户登录错误，可能是脚本错误或者被暴力破解攻击了。

接着通过"echo > /var/log/btmp" 进行清理

随后再ssh发现，就直接秒登录了。再用top看，也没有相关的ssh进程cpu冲高的现象了。问题解决。

由此可以推断当ssh、su、sftp等命令在对服务器连接时，会去读取/var/log/btmp文件（应该与pam的配置有关），由于该文件非常大，所以读完这个文件的耗时比较长。最终导致登录缓慢。

当场通过"echo > /var/log/btmp" 进行清理，立竿见影。

接着追溯发现由于脚本配置有问题，每分钟都会有大量配置错误的sftp用户进行登录访问，最终登录失败信息都会记录在btmp文件内，因此echo 是治标不治本。

据团队小伙伴landscape说，centos的确有一个N年前的bug，只要是配置了pam某个参数，就会遍历读取/var/log/btmp文件。

需要在logrotate里面加入循环清理/var/log/btmp文件的配置信息。

以下是团队小伙伴landscape给的方法。

关注