【记一次运维】系统访问不到的问题

新签了个客户，客户的上个乙方到期不干了，然后系统出问题了，求救我们了。废话不多说了。

刚到，客户的技术负责人就说，系统能登录，然后只能访问一级菜单，再点就是空白页。

当接到这个问题的时候，我第一反应就是F12，看下network，果然有收获，访问了好多静态文件，但是有三个js文件访问不到的了。。。（这里有个坑，技术说的能访问的一级菜单，发布在A服务器，然后这三个访问不到的js文件竟然在B服务器。。。）。然后直接问负责人，打开B服务器我看下，结果他一愣，只知道A服务器，不知道B服务器的存在。抱着试一试的态度，用相同的用户名密码，竟然OK了，但是这个时候链接B服务器特别慢，也没在意。登入成功后看到有两个黑窗口，tomcat发布的，控制台有报错，报错是oracle Error Code: 17002 错误，并且负责人还说删过监听日志，并且有报错
java.sql.SQLException: Io exception: Message file ‘oracle.net.mesg.Message’ is missing.
所以下意识的认为，昂，oracle的问题，然后用C服务器能连上D服务器的Oracle，用的SQLPlus（其实到这儿，应该排除Oracle的问题了，然鹅并没有），到这儿为止，我竟然还认为是Oracle的问题。。。然后一顿海查，怎么停了监听，再启动Oracle服务，一顿改权限，中间还碰到了lsnrctl 无权限执行的问题。当我执行停监听的时候

lnsrctl stop

报错

TNS-01190: The user is not authorized to execute the requested listener command

然后查到一篇文章说，需要看看是哪个账号启动的这个进程

ps -ef | grep lsnrctl

然后发现是Oracle用户，但是我已经切换到oracle了，还是失败。结果是因为oracle 11g用的是grid用户，然后果断切换到grid用户
参考的

第二种情况：
因为数据库是11.2.0.3而且使用了oracle restart特性且用户为grid.注册了listener服务且只对默认端口1521有效.之前是1522所以oracle restart不会自动重启监听.由于将端口修改成了1521所以oracle restart自动重启了listener
 [[email protected]~]$ srvctl status listener
Listener LISTENER is enabled
Listener LISTENER is running on node(s): DEVEDW 
由于Oracle restart 以grid用户自动启动了监听所以oracle用户不能重动由grid用户所启动的监听。
故可以切换到grid 用户去执行lsnrctl 操作
[[email protected] home]$ su - grid
Password:
[[email protected] ~]$ lsnrctl stop

LSNRCTL for Linux: Version 11.2.0.3.0 - Production on 25-SEP-2014 11:24:49

Copyright (c) 1991, 2011, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1521)))
The command completed successfully

这次可以停了，然后oracle被shutdown成功了，但是启动又报错了，说权限不允许。。。
然后又是一顿查，改oracle的权限，
https://blog.csdn.net/scjthree/article/details/38345971
各种chmod，结果还是不行，算了吧，反正也不是自己做的，很难查出来了，直接重启这个linux服务器了，oracle能用了，和之前一样，然后想了下，既然这个sql plus能连上，那说明数据库是不是没有问题？
继续查报错，换个思路
找到个报错
java.net.SocketException: No buffer space available (maximum connections reached?)
这么看，先看到最大连接数，还是怀疑人家oracle，从上面报错可以看出缓冲空间已经不足了，无法启动应用程序，但是为什么会出现这个问题，赶紧问问度娘，毕竟玩window服务器的时间还是比较少的，网上说是有连接没有关闭，占用了端口资源，查一查，果然，进程都结束了，依然后很多TIME_WAIT状态的连接未释放，再查看所有的time_wait连接，直接过去好几屏，汗，计数也不用了，肯定有问题。

netstat -ano   windows下查看当前所有的tcp连接
 
netstat -ano |findstr "8080"  windows下查看所有8080端口的tcp连接
 
netstat -ano |findstr "TIME_WAIT"  windows下查看所有的“TIME_WAIT”状态的tcp连接
 
netstat -ano |find /i /c "TIME_WAIT"   windows下统计time_wait出现的次数（按行统计） /i 忽略大小写

这个就没有截图了，但是我是头一次见过这么多TIME_WAIT状态的链接。。。。汗
随即，查看一下有没有设TIME_WAIT的自动关闭时间（默认4分钟）、还有windows下的大端口服务（虽然系统总共可使用的Ports有65536个，但从本机连到外部网路(Outbound Connections)的连线埠最多只会使用到5000个而已【此为系统默认值】）。

cmd--->regedit    进入注册表
 
进入 HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Tcpip/Parameters 
 
新建 DWORD 类型的注册表项，命名为：MaxUserPort  
 
值数据： 60000（用十进制的格式录入进去，此值的有效范围为5000-65534）
 
新建 DWORD 类型的注册表项，命名为：TCPTimedWaitDelay
 
值数据： 30（TIME_WAIT的自动断开时间，默认为4分钟）

但是这次看到这么多TIME_WAIT的，也不想改了，要下班了，最直接的，重启服务器搞定。
设置完大端口及time_wait时间后，重新启动tomcat，能正常启动了，访问应用也正常了。但是有个现象就是time_wait的连接数似乎没有降低，同事说是微软操作系统的bug，然后重新启动服务器，再观察time_wait的链接，发现变少了，而且也能自动释放了。

【结论】：由于大量的TIME_WAIT连接未被释放，导致占用的端口资源一直未被回收，出现了缓冲区空间不足的问题，应用也总是自动断线。