在用apache+tomcat做負載均衡的時候，遇到服務器問題，apache的日誌如下：
寫道
==ajp_process_callback::jk_ajp_common.c (1945): Writing to client aborted or client network problems
==ajp_service::jk_ajp_common.c (2607): (tomcat2) sending request to tomcat failed (unrecoverable), because of client write error (attempt=1)
==service::jk_lb_worker.c (1400): service failed, worker tomcat2 is in local error state
==service::jk_lb_worker.c (1419): unrecoverable error 200, request failed. Client failed in the middle of request, we can't recover to another instance.
==jk_handler::mod_jk.c (2671): Aborting connection for worker=controller
==ajp_service::jk_ajp_common.c (2607): (tomcat2) sending request to tomcat failed (unrecoverable), because of client write error (attempt=1)
==service::jk_lb_worker.c (1400): service failed, worker tomcat2 is in local error state
==service::jk_lb_worker.c (1419): unrecoverable error 200, request failed. Client failed in the middle of request, we can't recover to another instance.
==jk_handler::mod_jk.c (2671): Aborting connection for worker=controller
網上找了一些解決辦法，這裏貼出只是爲了備註一下，方便以後查找。
寫道
1現象
當然能報這個錯的原因很多，配置不對連不上的，二者版本不對，不兼容的,這裏不討論這些入門的事。只說配置成功，在有較高負載的情況下出現這種情況。這種情況還伴隨着apache的文件正常訪問，單獨訪問tomcat的端口也正常。只是訪問apache+tomcat的端口出事。
2解決方案
在workers.properties裏設置相應的負載機器的recovery_options=3
3解釋
recovery_options屬性說明了web server在檢測到Tomcat失敗後如何進行恢復工作。默認情況下，web server將轉發請求給處於負載平衡模式中的另一個Tomcat。屬性值爲0，說明全部恢復；屬性值爲1，說明如果在Tomcat接到請求後出現失敗狀況，則不進行恢復；屬性值爲2，說明如果在Tomcat發送http頭給客戶端後出現失敗狀況，則不進行恢復；屬性值爲3，說明如果在Tomcat接到請求後出現失敗狀況或者在Tomcat發送http頭給客戶端後出現失敗狀況，則不進行恢復。此屬性在jk 1.2.6版本被增加進來，以求避免Tomcat的死機和在支持ajp13的servlet引擎上發生的問題。此屬性默認爲全部恢復。
因在默認的情況下，JK檢測tomcat的工作情況，所以浪費了很多資源，這個資源多到比tomcat正常工作所需的資源的1.6倍還多--通過後來的滿足更多請求使用更少機器的情況估計出來的保守值。如果不檢測恢復，則效率高了，處理的請求數可以是原來的2.6倍多，而且tomcat還不死--沒響應,反而使出錯的數量比檢測恢復之後出錯的數量還少，性能還加強了，如果原來用這種的集羣100臺機器，有一陣就掛掉，改成這個配置只要40臺機器，一般在同樣的時間段內運行無反應或出錯的情況比recovery_options使用默認值的少得多。
recovery_options的最新參考
http://tomcat.apache.org/connectors-doc/reference/workers.html
4思考過程和方法
具體說是具體問題具體分析，這裏主要是觀察和思考矛盾現象。
矛盾現象:負載高時，機器僵死，CPU和IO都不怎麼用，只處理少量請求，tomcat單獨訪問沒問題，apache單獨訪問沒問題。現象很矛盾，負載高反而不做什麼事。
觀察這種矛盾現象用到了查看機器網絡流量，CPU佔用，全局共享文件，使用內存，IO使用情況，apache和tomcat使用的文件、socket、線程。綜合上面的現象和一些觀察的結果看，問題出現在apache連接tomcat上，當然就去找那個上面提到過的配置文件參考。幾乎試用了所有參數，最終找到這個參數，起初沒覺得這個錯誤恢復功能會使性能下降這麼大，不過仔細想想這個功能確實會佔用大量的資源，一個程序監控另一個程序裏的連接數據還要根據這些數據判斷一堆東西顯然要比一個只往自己的網絡連接裏收發數據的程序佔用的資源大，以至性能下降很大。改了它之後解決了一半高負載的問題。還有可能會出現的另一個問題。
5可能出現的問題
在服務器管理的實踐中遇到過經改完配製後，有的機器還有上面的報錯，但已經不是不用CPU和IO了，看樣子是正常工作了。有的機器現象較好，一個apache+4個tomcat,一晚上可以處理1000萬的請求。用jmeter開50個線程狂壓都死不了。起初認爲是新舊機器的事，因舊機器性能本身是差，並且舊機器中出現以上報錯的也多。但是也有一兩臺舊機器運行良好，一兩臺新機器一兩天就會出現上面的報錯。爲此，又分析了一下這個矛盾現象。
從監控新機器處理的流量開始,這些新機器每天處理的流量都是差不多的，配製基本上一樣。上面說過一臺運行好的機器12小時處理1000萬請求還輕鬆，而正常運營的每臺機器24小時處理不超過150萬請求，還有報錯的現象。顯然性能差別巨大不是新舊機器性能上的而是本質上的。
於是在新機器中選出性能好和不好的，全面對比，還算是比較順利，因用CPU多的只有tomcat，而用ps看程序時，發現二者的java路徑不一樣，很容易讓人想到是jre的事。把性能不好的機器換上的jrocket的jre，問題解決了。
原因爲普通的jre總是回收內存，做了回收內存的日誌，一秒鐘最少回收一次，一臺機器4個tomcat則每秒至少回收4次，回收期間使用CPU高--1個tomcat佔500多兆內存，而且垃圾回收期間是暫停請求的，所以CPU狂用，而處理的量也不比其它機器多。而jrocket的jre測試用了一兩個小時竟然沒垃圾回收，網上查了一下有人說那個大約一天才回收一次，不過回收一次可能要幾分鐘到十幾分鍾，這就是爲什麼用apache加一個jrocket的NIO的tomcat不如用apache加4個tomcat好的原因，只要一垃圾回收一個tomcat十幾分鐘沒響應肯定是不行的，雖然單個的NIO的tomcat的性能比4個tomcat的好。
出自：http://blog.sina.com.cn/s/blog_54394f910100p52t.html
當然能報這個錯的原因很多，配置不對連不上的，二者版本不對，不兼容的,這裏不討論這些入門的事。只說配置成功，在有較高負載的情況下出現這種情況。這種情況還伴隨着apache的文件正常訪問，單獨訪問tomcat的端口也正常。只是訪問apache+tomcat的端口出事。
2解決方案
在workers.properties裏設置相應的負載機器的recovery_options=3
3解釋
recovery_options屬性說明了web server在檢測到Tomcat失敗後如何進行恢復工作。默認情況下，web server將轉發請求給處於負載平衡模式中的另一個Tomcat。屬性值爲0，說明全部恢復；屬性值爲1，說明如果在Tomcat接到請求後出現失敗狀況，則不進行恢復；屬性值爲2，說明如果在Tomcat發送http頭給客戶端後出現失敗狀況，則不進行恢復；屬性值爲3，說明如果在Tomcat接到請求後出現失敗狀況或者在Tomcat發送http頭給客戶端後出現失敗狀況，則不進行恢復。此屬性在jk 1.2.6版本被增加進來，以求避免Tomcat的死機和在支持ajp13的servlet引擎上發生的問題。此屬性默認爲全部恢復。
因在默認的情況下，JK檢測tomcat的工作情況，所以浪費了很多資源，這個資源多到比tomcat正常工作所需的資源的1.6倍還多--通過後來的滿足更多請求使用更少機器的情況估計出來的保守值。如果不檢測恢復，則效率高了，處理的請求數可以是原來的2.6倍多，而且tomcat還不死--沒響應,反而使出錯的數量比檢測恢復之後出錯的數量還少，性能還加強了，如果原來用這種的集羣100臺機器，有一陣就掛掉，改成這個配置只要40臺機器，一般在同樣的時間段內運行無反應或出錯的情況比recovery_options使用默認值的少得多。
recovery_options的最新參考
http://tomcat.apache.org/connectors-doc/reference/workers.html
4思考過程和方法
具體說是具體問題具體分析，這裏主要是觀察和思考矛盾現象。
矛盾現象:負載高時，機器僵死，CPU和IO都不怎麼用，只處理少量請求，tomcat單獨訪問沒問題，apache單獨訪問沒問題。現象很矛盾，負載高反而不做什麼事。
觀察這種矛盾現象用到了查看機器網絡流量，CPU佔用，全局共享文件，使用內存，IO使用情況，apache和tomcat使用的文件、socket、線程。綜合上面的現象和一些觀察的結果看，問題出現在apache連接tomcat上，當然就去找那個上面提到過的配置文件參考。幾乎試用了所有參數，最終找到這個參數，起初沒覺得這個錯誤恢復功能會使性能下降這麼大，不過仔細想想這個功能確實會佔用大量的資源，一個程序監控另一個程序裏的連接數據還要根據這些數據判斷一堆東西顯然要比一個只往自己的網絡連接裏收發數據的程序佔用的資源大，以至性能下降很大。改了它之後解決了一半高負載的問題。還有可能會出現的另一個問題。
5可能出現的問題
在服務器管理的實踐中遇到過經改完配製後，有的機器還有上面的報錯，但已經不是不用CPU和IO了，看樣子是正常工作了。有的機器現象較好，一個apache+4個tomcat,一晚上可以處理1000萬的請求。用jmeter開50個線程狂壓都死不了。起初認爲是新舊機器的事，因舊機器性能本身是差，並且舊機器中出現以上報錯的也多。但是也有一兩臺舊機器運行良好，一兩臺新機器一兩天就會出現上面的報錯。爲此，又分析了一下這個矛盾現象。
從監控新機器處理的流量開始,這些新機器每天處理的流量都是差不多的，配製基本上一樣。上面說過一臺運行好的機器12小時處理1000萬請求還輕鬆，而正常運營的每臺機器24小時處理不超過150萬請求，還有報錯的現象。顯然性能差別巨大不是新舊機器性能上的而是本質上的。
於是在新機器中選出性能好和不好的，全面對比，還算是比較順利，因用CPU多的只有tomcat，而用ps看程序時，發現二者的java路徑不一樣，很容易讓人想到是jre的事。把性能不好的機器換上的jrocket的jre，問題解決了。
原因爲普通的jre總是回收內存，做了回收內存的日誌，一秒鐘最少回收一次，一臺機器4個tomcat則每秒至少回收4次，回收期間使用CPU高--1個tomcat佔500多兆內存，而且垃圾回收期間是暫停請求的，所以CPU狂用，而處理的量也不比其它機器多。而jrocket的jre測試用了一兩個小時竟然沒垃圾回收，網上查了一下有人說那個大約一天才回收一次，不過回收一次可能要幾分鐘到十幾分鍾，這就是爲什麼用apache加一個jrocket的NIO的tomcat不如用apache加4個tomcat好的原因，只要一垃圾回收一個tomcat十幾分鐘沒響應肯定是不行的，雖然單個的NIO的tomcat的性能比4個tomcat的好。
出自：http://blog.sina.com.cn/s/blog_54394f910100p52t.html