TIME_WAIT导致系统越来越慢

同事说系统越来越慢,出现一堆TIME_WAIT,是以前的几十倍,是否跟这个有关系。

上去看看什么情况。

[[email protected] ~]$ netstat -ntal    #一堆TIME_WAIT没释放,几乎由程序本身发起。
tcp        0      0 ::ffff:127.0.0.1:60110      ::ffff:127.0.0.1:28080      TIME_WAIT   
tcp        0      0 ::ffff:127.0.0.1:60303      ::ffff:127.0.0.1:28080      TIME_WAIT   
tcp        0      0 ::ffff:127.0.0.1:60329      ::ffff:127.0.0.1:28080      TIME_WAIT   
tcp        0      0 ::ffff:127.0.0.1:60088      ::ffff:127.0.0.1:28080      TIME_WAIT   
tcp        0      0 ::ffff:127.0.0.1:60044      ::ffff:127.0.0.1:28080      TIME_WAIT   
tcp        0      0 ::ffff:127.0.0.1:60359      ::ffff:127.0.0.1:28080      TIME_WAIT   
tcp        0      0 ::ffff:127.0.0.1:60132      ::ffff:127.0.0.1:28080      TIME_WAIT   
tcp        0      0 ::ffff:127.0.0.1:60306      ::ffff:127.0.0.1:28080      TIME_WAIT   
tcp        0      0 ::ffff:127.0.0.1:60061      ::ffff:127.0.0.1:28080      TIME_WAIT   
tcp        0      0 ::ffff:127.0.0.1:60101      ::ffff:127.0.0.1:28080      TIME_WAIT   
tcp        0      0 ::ffff:127.0.0.1:60083      ::ffff:127.0.0.1:28080      TIME_WAIT   
tcp        0      0 ::ffff:127.0.0.1:60243      ::ffff:127.0.0.1:28080      TIME_WAIT   
tcp        0      0 ::ffff:127.0.0.1:60035      ::ffff:127.0.0.1:28080      TIME_WAIT   
tcp        0      0 ::ffff:127.0.0.1:60080      ::ffff:127.0.0.1:28080      TIME_WAIT   
tcp        0      0 ::ffff:127.0.0.1:60198      ::ffff:127.0.0.1:28080      TIME_WAIT   
tcp        0      0 ::ffff:127.0.0.1:60151      ::ffff:127.0.0.1:28080      TIME_WAIT   
tcp        0      0 ::ffff:127.0.0.1:60003      ::ffff:127.0.0.1:28080      TIME_WAIT   
tcp        0      0 ::ffff:127.0.0.1:60070      ::ffff:127.0.0.1:28080      TIME_WAIT   
tcp        0      0 ::ffff:127.0.0.1:60189      ::ffff:127.0.0.1:28080      TIME_WAIT

[[email protected] ~]$ netstat -ntal |awk ‘{print $6}‘|sort |uniq -c |sort -nr
    10558 TIME_WAIT          #这个数量多的不太正常。
       23 ESTABLISHED        #这里连接数少是做了缓存,命中率达98%以上,很少穿透进来。
       
[[email protected] ~]$ cat /etc/issue  #操作系统版本不一样,内核参数也有些变化。
CentOS release 6.3 (Final)
Kernel \r on an \m

/etc/sysctl.conf 配置文件末尾添加如下3个参数,然后执行 /sbin/sysctl -p 让参数生效。

 

net.ipv4.tcp_tw_reuse = 1     #允许TIME-WAIT sockets重新用于新的TCP连接,默认为0。

net.ipv4.tcp_tw_recycle = 1   #开启TCP连接中TIME-WAIT sockets的快速回收,默认为0。

net.ipv4.tcp_fin_timeout = 20 #修改默认的 TIMEOUT 时间。

接着看下TIME_WAIT数量,恢复正常。

[[email protected] ~]$ netstat -ntal |awk ‘{print $6}‘|sort |uniq -c |sort -nr
     54 TIME_WAIT
     25 ESTABLISHED


现在访问系统变得非常快。

现将这3个参数加入系统初始化脚本,但以后程序出现这种情况不易被发现,如何监控值得考虑。

能不动内核参数,最好别动,很多情况下默认已够用,切忌为了优化而优化。目前这只是暂时解决问题,治标不治本。


最后还需联系开发一起排查问题原因~

TIME_WAIT导致系统越来越慢,布布扣,bubuko.com

时间: 2024-07-31 14:34:43

TIME_WAIT导致系统越来越慢的相关文章

Linux中进行用户UID测试导致系统报错

今天在Ubuntu14.04下进行了一个小测试,即修改系统文件/etc/passwd的用户UID值,却导致系统Bug,无法正常使用.因为修改/etc/passwd需要root权限,当再次准备使用sudo命令复原文件时,报错: sudo:unknown uid 1000:who are you? 重启之后却直接进入最低权限的guest账号,同时使用sudo命令是报错: sudo:unable to change to root gid:Operation not permitted仍然无法解决.

Redis 未授权访问缺陷可轻易导致系统被黑

Redis 未授权访问缺陷可轻易导致系统被黑 漏洞概要 Redis 默认情况下,会绑定在 0.0.0.0:6379,这样将会将Redis服务暴露到公网上,如果在没有开启认证的情况下,可以导致任意用户在可以访问目标服务器的情况下未授权访问Redis以及读取Redis的数据.攻击者在未授权访问Redis的情况下可以利用Redis的相关方法,可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中,进而可以直接登录目标服务器. 漏洞概述 Redis

Boot目录下内容丢失导致系统无法启动

Boot目录下内容丢失导致系统无法启动 笔者朋友近期在一次学习过程中不慎将虚拟机中boot目录下内容丢失,导致系统无法启动.当然此前他并不知道是这样,只是应为莫名的弹出框报错所有导致系统无法启动.此后朋友将此故障告知笔者,笔者本身其实也是小白刚刚学习linux不就,但是对这些稀奇古怪的故障感觉很有兴趣,所以笔者就掉进坑里搞了几个小时到了凌晨2点才搞出来点眉目来.为了让更多学习linux的小白踩坑,笔者将故障处理过程写出来希望和在下一样的小白们少踩坑.下的不好大家别见怪哈. 1.  事故出现原因

强力删除Avast后导致系统不断重启解决办法

我使用的是XP系统,Avast版本是7.0.由于avast7.0无法更新病毒库和软件,所以想卸载掉再重装. 问题来了!Avast无法直接卸载!用控制面板的卸载工具和360卸载功能都无法卸载,提示"setup.ovr-应用程序错误".下载新版安装包之后,也无法覆盖,同样提示应用程序错误.最后怒了,用360强力卸载将Avast文件夹直接强力删除了. 重启电脑后,电脑无法进入系统.启动过程中能够看到进度条,然后又重启,反复.尝试进入"安全模式",成功.网上搜索,下载了36

linux中/etc/fstab文件删除或修改了,导致系统无法启动

在linux中,/etc/fstab文件是磁盘挂载的问题,若该文件不小心给修改了,或者被删除了,那么就会导致系统无法重启.因为/etc/fstab文件是记录磁盘挂载的信息,若该文件出现了问题,那么对应的主目录(/)和(/boot)以及swap的磁盘将无法挂载,所以这个文件对于linux系统来说是相当重要的. 我犯的错误是:我在对hadoop集群进行文件配置的时候,在一台主机上对/etc/fstab文件进行修改,修改好了之后,准备分发给其他主机,我开始以为fstab文件的内容是一样的,于是我就该文

Linux 修改inittab导致系统无法启动修复

以红帽Linux为例,由于修改inittab内容不当,导致系统无法启动. 解决思路:启动时修改grub参数,进入单用户模式,将inittab文件恢复,重新启动系统即可.而且该方法不需要光盘启动,特别适合虚拟机下的inittab等文件的恢复. 解决步骤: 1.修改grub参数. 在启动Linux时,按上下键,进入启动参数选择模式. 2.按e键进入grub参数编辑模式. 3.选择启动项,将rhgb参数修改为single,敲回车返回,再按b键启动Linux. 将 grub append>ro root

CentOS误删除glibc导致系统系统一系列错误的解决办法

因为升级glibc不成功,将老版本的glibc删除,导致系统大部分命令都不能使用,系统不能正常启动.解决办法如下:系统:CentOS release 6.5 (Final)内核:2.6.32-431.el6.x86_64插入系统盘选择系统救援模式默认会将原操作系统挂在到/mnt/sysimage目录下#chroot /mnt/sysimage //切换到原操作系统#mkdir /mnt/cdrom //创建光驱挂载目录#mount /dev/sr0 /mnt/cdrom //挂在光驱#cd /m

【原创】访问Linux进程文件表导致系统异常复位的排查记录

前提知识: Linux内核.Linux 进程和文件数据结构.vmcore解析.汇编语言 问题背景: 这个问题出自项目的一个安全模块,主要功能是确定某进程是否有权限访问其正在访问的文件. 实现功能时,需要在内核里通过扫描该进程打开的文件表,获取文件的路径,和安全模块里配置的可访问文件的进程白名单进行匹配: 模块会一直到搜索到进程pid为1的进程,也就是init进程.在访问中间某个父进程的文件表时,出现struct task_struct的files指针为空的情况, 导致系统异常复位. 下面就是这次

TIME_WAIT状态的连接过多导致系统端口资源耗尽问题(2)

继上次解决完mysql连接过多,导致的TIME_WAIT进程过多问题之后,最近这个现象再一次出现,并且依然和之前一样严重.只不过这次出现问题的mysql 服务跟上次不一样,上一次主要是mysql master server,而这一次是mysql slave server.所以这意味着,我们上次解决了部分问题,但没有彻底解决,还存在一部分问题.所以这次彻底的把这个问题好好梳理一下. 再次确认一下TIME_WAIT进程的所属服务: sudo netstat -anp | grep TIME_WAIT