ビューデータ収集Tomcatのログ、参照するには、最後のログの習慣的な最初のターン：何も珍しいプリントはありませんが、それはいくつかの異常が、ほとんどはまだ、このことが判明しました
「あまりにもmanay開いているファイルは、」問題は、開いているファイル記述子の制限は、ファイルが得られ超過またはulimitのは確かに最適化されていないネットワーク接続、この問題は、いくつかの他の問題につながるを作成し、その設定をulimitをチェックしていることができない、ああ、非常に明確です。
開いているファイルは、65535であることが判明した最適化は、その後、Tomcatと他のサービス、および行うに最適化されたulimitの魚を始めよないです行われていますか？可能なので、[OK]サービスを再起動しますので、すべてのサービスが再び正常に動作して再起動され、レポートはすぐにデータを表示して、技術的なサポートを教えてくれます、問題が解決された後、他のケースに対処するために行ってきましたA;
結果は、レポートにデータがないので、彼は、Tomcatのログデータ収集アプリケーションが見ヒットし、すべての間違いを例外の束を発見したと、20分未満、技術的なサポートされています：
Tomcatのコネクタがネットワーク要求を処理しているこの例外エラーメッセージを見ることは非常に多くあり、Tomcatのコネクタが書き込み動作例外の時に壊れたパイプが起こっているが、それはネットワークの問題であるが、なぜ異常発生は、読み取り、書き込みされています問題はありませんか？裁判官にローカルインタフェースサーバにビットにアクセスするためのwgetコマンドを使用し、その後、ネットワークの問題ではありません、そして、そのような長い時間を見つけて応答していない、通常の状況下では、原因がネットワークではないことを示し、即時応答があるはず、サーバー問題は、その後、現在のTCPIP接続の状態を表示するコマンドを使用します。
接続CLOSE_WAITクライアントが接続を閉じることを示し、実際には正常ではないとする、3853を持っている状態、サーバは、サーバがの状態CLOSE_WAIT、そうでない場合、オペレーティング・システム・アライブに維持されている原因、閉じる操作が接続されませんでした最適化を行うには、デフォルトではシステムのセットアップを確認するために2時間、この状態のままになります。
果然是7200秒，这就解释通了，为什么第一次查看tomcat日志最后报错都是“Too manay open files”异常，一定是在两个小时内，close_wait状态暴增，导致文件描述符超过了65535的最大限制；
而这个状态应该就是broken pipe 异常导致的，是什么导致的broken pipe异常呢？为什么探针关闭了连接，但是数据采集服务器却没有关闭连接？报异常的是tomcat的connector，tomcat不可能会忘记调用close方法去关闭连接，排除了程序的问题，也想不出来是什么导致的了；
于是去拿了往采集服务器上传数据的探针的日志查看，竟然有大量的一个异常：
都是read time out异常,那么问题就明确了， 是探针端读取超时了，断开了连接，而这时候数据采集服务器还在处理请求，它并不知道探针端已经断开了连接，处理完请求后再将处理结果发给探针，就broken pipe了；
原来这个异常是客户端读取超时关闭了连接,这时候服务器端再向客户端已经断开的连接写数据时就发生了broken pipe异常！
探针读超时的时间是2分钟，服务器为什么这么长的时间都没有响应呢？于是使用jstack命令导出了tomcat的线程栈信息进行分析，最后发现代码中有耗时的操作加了锁，导致线程阻塞（保密原因，在这里就不贴代码了）；
这里总结一下，给我发私信的有些朋友没有get到Broken piple问题的重点，并不是只有超时才会导致这个问题，只要是连接断开，再往这个断开的连接上去执行写操作，都会出现这个异常，客户端超时断开只是其中的一种情况：
另外，当看到“Too manay open files”异常的时候，通常做法除了检查ulimit系统限制外，还应该看一下进程打开的文件句柄数,cat /proc/sys/fs/file-nr命令查看系统总句柄数,当前应用打开的文件句柄数使用ls -l /proc/<pid>/fd | wc -l命令，这里还好忽略了这一步，否则可能又要花费一些时间来查找系统真正的问题；
通过这个案例可知，排查问题时，在有些情况下，你第一眼看到的异常信息未必就是问题的根源所在，而是后续一些连锁反应，尤其是当大量出现同一个异常的情况下，不要看最后一条异常日志，应该先去日志里面查找第一出现该异常的位置，看看这个异常发生之前系统的状况；