服务器中很多的CLOSE_WAIT,请教各位大虾!!!!!!!!!

yierhan111 2013-10-29 10:09:31
最近遇到一个问题,工程在LINUX服务器上面跑起来了以后,运行一段时间就有很多的CLOSE_WAIT链接,多了之后,网站就访问不了了,多半是程序的原因,我想从这方面入手,查看服务器JBOSS宕机之前在访问网站的那些页面,看是那些页面引起的,再去查看代码,在下是LINUX新手,在服务器中怎么查看访问的页面信息,那些页面正在访问,这样好排查问题一些,请教各位大侠!!!!!!
...全文
536 6 打赏 收藏 转发到动态 举报
写回复
用AI写文章
6 条回复
切换为时间正序
请发表友善的回复…
发表回复
yierhan111 2013-10-31
  • 打赏
  • 举报
回复
引用 5 楼 yetaodiao 的回复:
结贴 yierhan111 祝福
好的
  • 打赏
  • 举报
回复
结贴 yierhan111 祝福
MiceRice 2013-10-30
  • 打赏
  • 举报
回复
对JBOSS不熟悉,不过如果其自身管理界面没有提供监控功能的话,你还有两个便捷手段: 1、开启AccessLog,根据时间,就可以知道某时间段内,哪些页面被访问; 2、执行ThreadDump,在生成的线程堆栈,可以看到所有线程在干啥以及哪个JSP(生成Servlet后的class),尤其是那些处于等待状态的。
yierhan111 2013-10-30
  • 打赏
  • 举报
回复
引用 1 楼 yetaodiao 的回复:
一、“多半是程序的原因”?这个还是交给程序猿吧 二、linux 下 CLOSE_WAIT过多的解决方法 情景描述:系统产生大量“Too many open files” 原因分析:在服务器与客户端通信过程中,因服务器发生了socket未关导致的closed_wait发生,致使监听port打开的句柄数到了1024个,且均处于close_wait的状态,最终造成配置的port被占满出现“Too many open files”,无法再进行通信。 close_wait状态出现的原因是被动关闭方未关闭socket造成,如附件图所示: 解决办法:有两种措施可行 一、解决: 原因是因为调用ServerSocket类的accept()方法和Socket输入流的read()方法时会引起线程阻塞,所以应该用setSoTimeout()方法设置超时(缺省的设置是0,即超时永远不会发生);超时的判断是累计式的,一次设置后,每次调用引起的阻塞时间都从该值中扣除,直至另一次超时设置或有超时异常抛出。 比如,某种服务需要三次调用read(),超时设置为1分钟,那么如果某次服务三次read()调用的总时间超过1分钟就会有异常抛出,如果要在同一个Socket上反复进行这种服务,就要在每次服务之前设置一次超时。 二、规避: 调整系统参数,包括句柄相关参数和TCP/IP的参数; 注意: /proc/sys/fs/file-max 是整个系统可以打开的文件数的限制,由sysctl.conf控制; ulimit修改的是当前shell和它的子进程可以打开的文件数的限制,由limits.conf控制; lsof是列出系统所占用的资源,但是这些资源不一定会占用打开文件号的;比如:共享内存,信号量,消息队列,内存映射等,虽然占用了这些资源,但不占用打开文件号; 因此,需要调整的是当前用户的子进程打开的文件数的限制,即limits.conf文件的配置; 如果cat /proc/sys/fs/file-max值为65536或甚至更大,不需要修改该值; 若ulimit -a ;其open files参数的值小于4096(默认是1024), 则采用如下方法修改open files参数值为8192;方法如下: 1.使用root登陆,修改文件/etc/security/limits.conf vi /etc/security/limits.conf 添加 xxx - nofile 8192 xxx 是一个用户,如果是想所有用户生效的话换成 * ,设置的数值与硬件配置有关,别设置太大了。 #<domain> <type> <item> <value> * soft nofile 8192 * hard nofile 8192 #所有的用户每个进程可以使用8192个文件描述符。 2.使这些限制生效 确定文件/etc/pam.d/login 和/etc/pam.d/sshd包含如下行: session required pam_limits.so 然后用户重新登陆一下即可生效。 3. 在bash下可以使用ulimit -a 参看是否已经修改: 一、 修改方法:(暂时生效,重新启动服务器后,会还原成默认值) sysctl -w net.ipv4.tcp_keepalive_time=600 sysctl -w net.ipv4.tcp_keepalive_probes=2 sysctl -w net.ipv4.tcp_keepalive_intvl=2 注意:Linux的内核参数调整的是否合理要注意观察,看业务高峰时候效果如何。 二、 若做如上修改后,可起作用;则做如下修改以便永久生效。 vi /etc/sysctl.conf 若配置文件中不存在如下信息,则添加: net.ipv4.tcp_keepalive_time = 1800 net.ipv4.tcp_keepalive_probes = 3 net.ipv4.tcp_keepalive_intvl = 15 编辑完 /etc/sysctl.conf,要重启network 才会生效 /etc/rc.d/init.d/network restart 然后,执行sysctl命令使修改生效,基本上就算完成了。 ------------------------------------------------------------ 修改原因: 当客户端因为某种原因先于服务端发出了FIN信号,就会导致服务端被动关闭,若服务端不主动关闭socket发FIN给Client,此时服务端Socket会处于CLOSE_WAIT状态(而不是LAST_ACK状态)。通常来说,一个CLOSE_WAIT会维持至少2个小时的时间(系统默认超时时间的是7200秒,也就是2小时)。如果服务端程序因某个原因导致系统造成一堆CLOSE_WAIT消耗资源,那么通常是等不到释放那一刻,系统就已崩溃。因此,解决这个问题的方法还可以通过修改TCP/IP的参数来缩短这个时间,于是修改tcp_keepalive_*系列参数: tcp_keepalive_time: /proc/sys/net/ipv4/tcp_keepalive_time INTEGER,默认值是7200(2小时) 当keepalive打开的情况下,TCP发送keepalive消息的频率。建议修改值为1800秒。 tcp_keepalive_probes:INTEGER /proc/sys/net/ipv4/tcp_keepalive_probes INTEGER,默认值是9 TCP发送keepalive探测以确定该连接已经断开的次数。(注意:保持连接仅在SO_KEEPALIVE套接字选项被打开是才发送.次数默认不需要修改,当然根据情形也可以适当地缩短此值.设置为5比较合适) tcp_keepalive_intvl:INTEGER /proc/sys/net/ipv4/tcp_keepalive_intvl INTEGER,默认值为75 当探测没有确认时,重新发送探测的频度。探测消息发送的频率(在认定连接失效之前,发送多少个TCP的keepalive探测包)。乘以tcp_keepalive_probes就得到对于从开始探测以来没有响应的连接杀除的时间。默认值为75秒,也就是没有活动的连接将在大约11分钟以后将被丢弃。(对于普通应用来说,这个值有一些偏大,可以根据需要改小.特别是web类服务器需要改小该值,15是个比较合适的值) 【检测办法】 1. 系统不再出现“Too many open files”报错现象。 2. 处于TIME_WAIT状态的sockets不会激长。 在 Linux 上可用以下语句看了一下服务器的TCP状态(连接状态数量统计): netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' 返回结果范例如下: ESTABLISHED 1423 FIN_WAIT1 1 FIN_WAIT2 262 SYN_SENT 1 TIME_WAIT 962
谢谢版主的回答,修改参数的办法有试过的,还是不行,主要是程序比较大,不知道是哪一部分引起的,不太好准确的定位到closed_wait出现的时候,用户有哪些操作,或者访问了哪些页面导致的,如果出现closed_wait的时候,可以查看到访问了哪些JSP页面,就比较好分析了
  • 打赏
  • 举报
回复
一、“多半是程序的原因”?这个还是交给程序猿吧 二、linux 下 CLOSE_WAIT过多的解决方法 情景描述:系统产生大量“Too many open files” 原因分析:在服务器与客户端通信过程中,因服务器发生了socket未关导致的closed_wait发生,致使监听port打开的句柄数到了1024个,且均处于close_wait的状态,最终造成配置的port被占满出现“Too many open files”,无法再进行通信。 close_wait状态出现的原因是被动关闭方未关闭socket造成,如附件图所示: 解决办法:有两种措施可行 一、解决: 原因是因为调用ServerSocket类的accept()方法和Socket输入流的read()方法时会引起线程阻塞,所以应该用setSoTimeout()方法设置超时(缺省的设置是0,即超时永远不会发生);超时的判断是累计式的,一次设置后,每次调用引起的阻塞时间都从该值中扣除,直至另一次超时设置或有超时异常抛出。 比如,某种服务需要三次调用read(),超时设置为1分钟,那么如果某次服务三次read()调用的总时间超过1分钟就会有异常抛出,如果要在同一个Socket上反复进行这种服务,就要在每次服务之前设置一次超时。 二、规避: 调整系统参数,包括句柄相关参数和TCP/IP的参数; 注意: /proc/sys/fs/file-max 是整个系统可以打开的文件数的限制,由sysctl.conf控制; ulimit修改的是当前shell和它的子进程可以打开的文件数的限制,由limits.conf控制; lsof是列出系统所占用的资源,但是这些资源不一定会占用打开文件号的;比如:共享内存,信号量,消息队列,内存映射等,虽然占用了这些资源,但不占用打开文件号; 因此,需要调整的是当前用户的子进程打开的文件数的限制,即limits.conf文件的配置; 如果cat /proc/sys/fs/file-max值为65536或甚至更大,不需要修改该值; 若ulimit -a ;其open files参数的值小于4096(默认是1024), 则采用如下方法修改open files参数值为8192;方法如下: 1.使用root登陆,修改文件/etc/security/limits.conf vi /etc/security/limits.conf 添加 xxx - nofile 8192 xxx 是一个用户,如果是想所有用户生效的话换成 * ,设置的数值与硬件配置有关,别设置太大了。 #<domain> <type> <item> <value> * soft nofile 8192 * hard nofile 8192 #所有的用户每个进程可以使用8192个文件描述符。 2.使这些限制生效 确定文件/etc/pam.d/login 和/etc/pam.d/sshd包含如下行: session required pam_limits.so 然后用户重新登陆一下即可生效。 3. 在bash下可以使用ulimit -a 参看是否已经修改: 一、 修改方法:(暂时生效,重新启动服务器后,会还原成默认值) sysctl -w net.ipv4.tcp_keepalive_time=600 sysctl -w net.ipv4.tcp_keepalive_probes=2 sysctl -w net.ipv4.tcp_keepalive_intvl=2 注意:Linux的内核参数调整的是否合理要注意观察,看业务高峰时候效果如何。 二、 若做如上修改后,可起作用;则做如下修改以便永久生效。 vi /etc/sysctl.conf 若配置文件中不存在如下信息,则添加: net.ipv4.tcp_keepalive_time = 1800 net.ipv4.tcp_keepalive_probes = 3 net.ipv4.tcp_keepalive_intvl = 15 编辑完 /etc/sysctl.conf,要重启network 才会生效 /etc/rc.d/init.d/network restart 然后,执行sysctl命令使修改生效,基本上就算完成了。 ------------------------------------------------------------ 修改原因: 当客户端因为某种原因先于服务端发出了FIN信号,就会导致服务端被动关闭,若服务端不主动关闭socket发FIN给Client,此时服务端Socket会处于CLOSE_WAIT状态(而不是LAST_ACK状态)。通常来说,一个CLOSE_WAIT会维持至少2个小时的时间(系统默认超时时间的是7200秒,也就是2小时)。如果服务端程序因某个原因导致系统造成一堆CLOSE_WAIT消耗资源,那么通常是等不到释放那一刻,系统就已崩溃。因此,解决这个问题的方法还可以通过修改TCP/IP的参数来缩短这个时间,于是修改tcp_keepalive_*系列参数: tcp_keepalive_time: /proc/sys/net/ipv4/tcp_keepalive_time INTEGER,默认值是7200(2小时) 当keepalive打开的情况下,TCP发送keepalive消息的频率。建议修改值为1800秒。 tcp_keepalive_probes:INTEGER /proc/sys/net/ipv4/tcp_keepalive_probes INTEGER,默认值是9 TCP发送keepalive探测以确定该连接已经断开的次数。(注意:保持连接仅在SO_KEEPALIVE套接字选项被打开是才发送.次数默认不需要修改,当然根据情形也可以适当地缩短此值.设置为5比较合适) tcp_keepalive_intvl:INTEGER /proc/sys/net/ipv4/tcp_keepalive_intvl INTEGER,默认值为75 当探测没有确认时,重新发送探测的频度。探测消息发送的频率(在认定连接失效之前,发送多少个TCP的keepalive探测包)。乘以tcp_keepalive_probes就得到对于从开始探测以来没有响应的连接杀除的时间。默认值为75秒,也就是没有活动的连接将在大约11分钟以后将被丢弃。(对于普通应用来说,这个值有一些偏大,可以根据需要改小.特别是web类服务器需要改小该值,15是个比较合适的值) 【检测办法】 1. 系统不再出现“Too many open files”报错现象。 2. 处于TIME_WAIT状态的sockets不会激长。 在 Linux 上可用以下语句看了一下服务器的TCP状态(连接状态数量统计): netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' 返回结果范例如下: ESTABLISHED 1423 FIN_WAIT1 1 FIN_WAIT2 262 SYN_SENT 1 TIME_WAIT 962
yierhan111 2013-10-30
  • 打赏
  • 举报
回复
引用 3 楼 ldh911 的回复:
对JBOSS不熟悉,不过如果其自身管理界面没有提供监控功能的话,你还有两个便捷手段: 1、开启AccessLog,根据时间,就可以知道某时间段内,哪些页面被访问; 2、执行ThreadDump,在生成的线程堆栈,可以看到所有线程在干啥以及哪个JSP(生成Servlet后的class),尤其是那些处于等待状态的。
谢谢大虾的回答,下次再出现这样的问题,我会试试看的

25,985

社区成员

发帖
与我相关
我的任务
社区描述
高性能WEB开发
社区管理员
  • 高性能WEB开发社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧