1. 程式人生 > >linux 下 tomcat 運行報錯 Broken pipe

linux 下 tomcat 運行報錯 Broken pipe

復制 復制代碼 cooper href 物理內存 csdn ner details 參數

linux 下 tomcat 運行報錯 Broken pipe 感謝:http://hi.baidu.com/liupenglover/blog/item/4048c23ff19f1cd67d1e7184.html

有可能是linux的線程機制會產生JVM出錯的問題,特別是在連接高峰期間經常出現這樣的問題,tomcat在linux下也出現類似情況。
  解決辦法是在環境變量中設置: _JAVA_SR_SIGNUM = 12 基本就可以解決。

在WIN環境變量中設置: _JAVA_SR_SIGNUM=12, 若Linux下用 export _JAVA_SR_SIGNUM=12, 基本就可以解決.
  sun的解釋:
  --posted by: cooper
  Below is a clipping from Sun on working around JVM crashes under high
  thread counts in the JVM 1.3 for Linux
  On Linux, use a larger signal number for hotspot thread
  suspension/resumption handler. The signal number being used is
  specified by environment variable _JAVA_SR_SIGNUM. Setting it to a
  number larger than SIGSEGV (11) will solve the PRoblem. A good number
  to use is 12, which is SIGUSR2. Using signal 16 to work around the
  problem might have potential problems. So on tcsh, "setenv
  _JAVA_SR_SIGNUM 12" can solve the problem.

--------------------- 本文來自 ruan_learning 的CSDN 博客 ,全文地址請點擊:https://blog.csdn.net/ruan_learning/article/details/50502366?utm_source=copy

這個異常是由於以下幾個原因造成。

1、客戶端再發起請求後沒有等服務器端相應完,點擊了stop按鈕,導致服務器端接收到取消請求。 通常情況下是不會有這麽無聊的用戶,出現這種情況可能是由於用戶提交了請求,服務器端相應緩慢,比如業務邏輯有問題等原因,導致頁面過了很久也沒有刷新出來,用戶就有可能取消或重新發起請求。

2、Tomcat服務器在接受用戶請求的時候,有其自身的處理能力,線程、服務器等各個資源限制,超出Tomcat承載範圍的請求,就會被tomcat停掉,也可能產生該錯誤。

3、linux的線程機制會產生JVM出錯的問題,特別是在連接高峰期間經常出現這樣的問題,tomcat在linux下也出現類似情況。
Java代碼

  1. 1.sun的解釋:
  2. 2.--posted by: cooper
  3. 3.Below is a clipping from Sun on working around JVM crashes under high
  4. 4.thread counts in the JVM 1.3 for Linux
  5. 5.
  6. 6.On Linux, use a larger signal number for hotspot thread
  7. 7.suspension/resumption handler. The signal number being used is
  8. 8.specified by environment variable _JAVA_SR_SIGNUM. Setting it to a
  9. 9.number larger than SIGSEGV (11) will solve the problem. A good number
  10. 10.to use is 12, which is SIGUSR2. Using signal 16 to work around the
  11. 11.problem might have potential problems. So on tcsh, "setenv
  12. 12._JAVA_SR_SIGNUM 12" can solve the problem.
  13. sun的解釋:
  14. --posted by: cooper
  15. Below is a clipping from Sun on working around JVM crashes under high
  16. thread counts in the JVM 1.3 for Linux
  17. On Linux, use a larger signal number for hotspot thread
  18. suspension/resumption handler. The signal number being used is
  19. specified by environment variable _JAVA_SR_SIGNUM. Setting it to a
  20. number larger than SIGSEGV (11) will solve the problem. A good number
  21. to use is 12, which is SIGUSR2. Using signal 16 to work around the
  22. problem might have potential problems. So on tcsh, "setenv
  23. _JAVA_SR_SIGNUM 12" can solve the problem.
復制代碼

“_JAVA_SR_SIGNUM=12”等號兩邊必須沒有空格,等號是半角

資料:
Broken pipe產生的原因通常是當管道讀端沒有在讀,而管道的寫端繼續有線程在寫,就會造成管道中斷。(由於管道是單向通信的) SIGSEGV(Segment fault)意味著指針所對應的地址是無效地址,沒有物理內存對應該地址。 以下是UNIX的信號解釋: 11 / SIGSEGV: Unerlaubter Zugriff auf Hauptspeicher (Adressfehler). 12 / SIGUSER2: User-defined Signal 2 (POSIX). 把_JAVA_SR_SIGNUM改成12只是將信號至成user-defined,讓它不報出來而已,不能解決問題。 建議采取的方式:
1. 資源沒有完全釋放,用完後要至NULL 值(JAVA的GC沒那麽完善)
2. 數據庫連接順序關閉!(RS,PS,CONN)
3. 優化JAVA虛擬機 加入相應的內存參數!
4. 不要在數據庫中獲取大段文本(即一個欄位的值不要太大)
5. JAVA 不推薦 用String 獲取大量信息。(容易造成內存泄露,建議用StringBuffer)
6. 頁面重復提交
7. 盡量將METHOD移到JAVA中,在JSP中所有的方法都看做全局變量,編譯執行本身就有很多問題。
8. 如果是查詢功能,盡可能的使用非XA(事務)。
9. 盡量用較新較穩定版本的JDK,低版本的JVM本身也有很多BUG,比如1。5的垃圾回收比起1。2,1。3一定是非常明顯的進步。
10. LINUX系統本身沒有這麽穩定,有些問題無法避免的~~:)

分類: 軟件設計 標簽: Broken pipe, 管道, tomcat

linux 下 tomcat 運行報錯 Broken pipe