国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

Was故障分析及優化整改方案

IT那活兒 / 2701人閱讀
Was故障分析及優化整改方案

點擊上方“IT那活兒”公眾號，關注后了解更多內容，不管IT什么活兒，干就完了！！！


  
7月28日15點50分左右，某管理平臺一臺應用服務器主機出現前端應用請求反應嚴重超慢的現象，17點48分重啟應用服務后，應用訪問暫時恢復正常。


問題故障原因定位

從錯誤日志分析，錯誤原因的數據庫連接池的連接達到最大設定值，導致系統無法獲取新的數據庫連接導致。

數據庫連接池連接最大值設置為200，如沒有特殊情況發生，系統不會出現連接數不足的現象。按以往的經驗造成連接數不足現象的原因有以下幾個：

  • 系統發生數據庫死鎖導致大量連接被鎖定；
  • 數據庫系統超負荷運轉導致反應變慢；
  • 網絡連接問題導致無法連接數據庫；
  • 系統有大數據量操作導致；
  • 系統程序有未釋放連接的程序bug，導致連接被使用光；
  • 數據庫其他問題導致無法獲取連接。

通過排查該應用系統各個層面的影響因素，最終將故障原因定位在連接池上。

問題分析過程

1. 首先檢查數據庫是否有死鎖

從前端發送到2節點的請求可以立馬得到響應，請求的頁面立馬顯示出來。從以上現象可以判斷，數據庫的訪問是肯定沒有問題的，不會存在死鎖或者數據庫宕機的可能；另外通過后臺查看數據庫沒有死鎖對象。
2. 檢查數據庫系統的負載情況
檢查數據庫主機的日志，發現CPU、內存占用率都很低，數據庫主機允許的最大連接數為1500，遠超2臺應用服務器連接池配置的共400的數據庫連接數，足以滿足應用的數據庫連接需求。
3. 檢查網絡連接情況
這臺服務器的WAS服務重啟后，請求立即得到快速響應，頁面很快就展現出來，說明網絡沒有任何問題。
4. 應用服務器的資源使用情況
通過重新啟動1節點中的WAS應用服務器之后，前端的請求發送到1節點之后，前端的請求可以立馬得到反應，而且請求的頁面也很快展現顯示出來，可以認為是WAS應用服務器釋放了相應的資源，可以滿足前端的請求響應了。同時，從websphere的層面來看，沒有生成相應的JavaCore和HeapDump文件，可以判斷機器的CPU和MEMORY資源也很正常，沒有發生內存泄漏等嚴重問題存在。
平臺使用的連接池是DBCP(DataBase connection pool)數據庫連接池。是 apache 上的一個 java 連接池項目，也是 tomcat 使用的連接池組件，也就是根本沒用到WAS的連接池。
5. WAS日志信息分析
繼續檢查1節點上WAS的應用日志信息，發現WAS的應用服務器重啟之前有大量如下報錯：
APP-1:
[7/27/14 15:51:54:938 GMT+08:00] 000000db AcfCoreServle E com.ursa.acf.plugins.todomessage.impl.DealReadToDoMsgMgr list error.plugin.user.error_sqlerror
com.ursa.acf.plugins.user.UserPluginException: error.plugin.user.error_sqlerror
at com.ursa.acf.plugins.user.ursaimpl.UrsaUser.j(UrsaUser.java:646)
at com.ursa.acf.plugins.user.ursaimpl.UrsaUser.(UrsaUser.java:53)
at com.ursa.acf.plugins.user.ursaimpl.UrsaUserManager.getUser(UrsaUserManager.java:178)
at com.ursa.acf.plugins.user.UserHelper.getUser(UserHelper.java:52)
at com.ursa.acf.plugins.todomessage.impl.DealReadToDoMsgMgr.list(DealReadToDoMsgMgr.java:132)
at com.itss.xz.test.login.AcfPanel_DBSY.setPanel(AcfPanel_DBSY.java:265)
at com.ursa.acf.plugins.acfpage.acfpanel.AcfPanelShow.acfShow(AcfPanelShow.java:65)
at com.ursa.acf.plugins.acfshow.AcfShow.acfExecute(AcfShow.java:38)
at com.ursa.acf.core.servlet.AcfCoreAction.execute(AcfCoreAction.java:62)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1194)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:575)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1147)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:722)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:449)
at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget(WebAppFilterChain.java:125)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:92)
at com.ursa.acf.core.EncodingFilter.doFilter(EncodingFilter.java:46)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:192)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:89)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:919)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1016)
at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:87)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:883)
at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1659)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:195)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:452)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:511)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:305)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:276)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
at com.ibm.io.async.AsyncChannelFuture$1.run(AsyncChannelFuture.java:205)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1648)
Caused by: org.apache.commons.dbcp.SQLNestedException: Cannot get a connection, pool error Timeout waiting for idle object
at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:114)
at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1044)
at com.ursa.acf.component.datasource.impl.StrutsDSManager.getConnection(StrutsDSManager.java:107)
at com.ursa.acf.component.datasource.DatabaseHelper.getConnection(DatabaseHelper.java:42)
at com.ursa.acf.plugins.user.ursaimpl.UrsaUser.j(UrsaUser.java:629)
... 39 more
Caused by: java.util.NoSuchElementException: Timeout waiting for idle object
at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1144)
at org.apache.commons.dbcp.AbandonedObjectPool.borrowObject(AbandonedObjectPool.java:79)
at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106)
... 43 more
其中紅色字體部分：
Caused by: org.apache.commons.dbcp.SQLNestedException: Cannot get a connection, pool error Timeout waiting for idle object
Caused by: java.util.NoSuchElementException: Timeout waiting for idle object
指出了產生問題的原因：
拋出此異常的原因為連接池泄漏，也就是再也無法從連接池中獲取有效的數據庫連接。
可能由于頻繁的刷新頁面導致上一次獲取的connection還沒有得到有效釋放，下一次的connection請求已經到達，如是刷新多次后導致池資源耗盡，即所謂的連接池泄漏。
而且，在此種情況下，最糟糕的是異常發生后導致整個服務向連接池發起connection請求都將一直拋出如上異常，無法恢復到正常狀態。向服務器發送請求，服務器沒有響應，最簡單的辦法是重新啟動釋放連接池的資源，才能使連接池的連接數恢復到一個正常狀態。前端的應用程序訪問才能正常。
查看WAS重啟后的日志信息，發現大量的如下錯誤信息：
  • 2節點:
[7/28/14 10:41:32:109 GMT+08:00] 00004676 filter        E com.ibm.ws.webcontainer.filter.FilterInstanceWrapper service SRVE8109W: Uncaught exception thrown by filter EncodingFilter: java.io.FileNotFoundException: SRVE0190E: File not found: /xzpage/bjyc/fs/resources/styles/ursadefault.css
at com.ibm.ws.webcontainer.extension.DefaultExtensionProcessor.handleRequest(DefaultExtensionProcessor.java:443)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget(WebAppFilterChain.java:125)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:92)
at com.ursa.acf.core.EncodingFilter.doFilter(EncodingFilter.java:46)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:192)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:89)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:919)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1016)
at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3639)
at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:304)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:950)
at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1659)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:195)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:452)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:511)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:305)
at com.ibm.ws.http.channel.inbound.impl.HttpICLReadCallback.complete(HttpICLReadCallback.java:83)
at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138)
at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204)
at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775)
at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1648)
  • 1節點:
[7/28/14 8:47:21:557 GMT+08:00] 00000036 filter        E com.ibm.ws.webcontainer.filter.FilterInstanceWrapper service SRVE8109W: Uncaught exception thrown by filter EncodingFilter: java.io.FileNotFoundException: SRVE0190E: File not found: /xzdefault.css
at com.ibm.ws.webcontainer.extension.DefaultExtensionProcessor.handleRequest(DefaultExtensionProcessor.java:443)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget(WebAppFilterChain.java:125)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:92)
at com.ursa.acf.core.EncodingFilter.doFilter(EncodingFilter.java:46)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:192)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:89)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:919)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1016)
at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3639)
at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:304)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:950)
at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1659)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:195)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:452)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:511)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:305)
at com.ibm.ws.http.channel.inbound.impl.HttpICLReadCallback.complete(HttpICLReadCallback.java:83)
at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138)
at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204)
at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775)
at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1648)
6. 對大數據量操作的分析
因為沒有針對用戶的歸檔和查詢操作進行記錄，因此無法獲悉問題發生前的客戶操作情況，而大量的歸檔、查詢操作會導致應用的負載急劇增加，數據庫連接數量瞬間爆發，導致連接池滿，后續需要對客戶的這類操作進行詳細記錄，同時通過應用層面做些適當的限制措施避免大量重復點擊操作等。
7. 應用代碼的分析
由于時間關系，沒來得及檢查系統的所有源代碼，以及是否有未關閉數據庫連接的程序，所以針對如何導致連接池泄露的根本原因還無法查明，需要后續排查應用代碼。
9. 應用調用數據庫的模式

應用調用數據庫使用的常連接，意味著即使用戶沒有在做業務的情況下，也一直不釋放而占用著數據庫連接的資源，也會影響別的用戶訪問數據庫。

系統優化整改要求

根據連接池問題，系統優化整改要求如下：

1. 增加Apache上的最大連接數

由于應用調用數據庫采用的常連接，確實很消耗連接數資源，因此本操作需要優先執行。
加大最大連接數到300，同時對連接池進行監控，設置報警閥值，當連接總數達到閥值后進行緊急處理，進行日志數據抓取，詳見“5. 應急預案”。
閥值：Aqsiq 180  Xzblob 140

2. 大數據量操作的優化建議

由于無法獲悉客戶操作情況，因此不好判斷一定就是客戶對大數據量誤操作導致的連接數急劇增加撐滿了連接池，因此后續也需要針對這塊進行優化整改，本操作需要優先執行。

對大數據量操作增加操作日志，以及對可能發生大數據量操作的程序進行以下優化。

  • 收文查詢打印功能限制最大打印數量（小于1000條），超過數量會在打印的文檔最后輸出“打印數量超過1000條請優化查詢后再進行打印”；
  • 收文查詢記錄查詢日志，記錄查詢人、查詢時間、查詢sql等信息；
  • 歸檔操作記錄日志，記錄歸檔人、歸檔時間、歸檔條數等日志；
  • 對收文查詢、歸檔操作實現屏蔽重復操作的功能（屏蔽雙擊或多次快速點擊操作）。

3. 建議查看如下方法中的代碼問題

檢查系統的所有源代碼，檢查是否有未關閉數據庫連接的程序。
可重點檢查以下代碼：
A) at com.ursa.acf.core.EncodingFilter.doFilter(EncodingFilter.java:46)
中doFilter(EncodingFilter.java:46)方法中的46行代碼

B) com.ursa.acf.component.datasource.impl.StrutsDSManager.getConnection
(StrutsDSManager.java:107)
中getConnection（）方法中的107行代碼

C) com.ursa.acf.component.datasource.DatabaseHelper.getConnection
(DatabaseHelper.java:42)
中getConnection(DatabaseHelper.java:42) 方法中的42行代碼

4. 依據用戶的應用使用習慣進行適當調整

鑒于應用調用數據庫使用的“常連接”，意味著即使用戶沒有在做OA業務的情況下，也一直不釋放而占用著數據庫連接的資源，也會影響別的用戶訪問數據庫。
因此建議應用開發方強制取消用戶常連接，比如：每24小時，常連接中斷。

5. Websphere應用服務器的優化

由于是32位的WAS平臺，對于32位的操作系統，最多只能使用4G的內存，而且又由于JVM的特殊性，對于32的JAVA 虛擬機，它只用到2G內存，考慮到JVM本身的原因，最多又只能使用2G內存的75%，所以，對于32位的JVM的堆最大大小的設置，不要超過1.5G(1536M)，對于，上面的最大堆大小，建議改為1536 MB。
對于垃圾回收機制問題，一般在生產環境建議不要開啟，因為開啟這個功能，會進行垃圾的回收功能，會損耗JVM的資源，也會影響性能。所以建議最好【詳細垃圾回收】不要開啟，除非是需要進行GC問題的故障診斷功能，才需要開啟該功能。

6. 升級WAS主機的操作系統及中間件

現網WAS主機部署的操作系統是32位，WAS中間件的位數也是32位。
建議如有可能，最好是安裝64位的操作系統，同時也安裝64位的websphere應用服務器中間件。尤其在應用訪問數據庫是基于常連接的調用模式的情況下，更耗系統資源。

7. 升級前端Apache分發機制的負載均衡功能

另外我們也認為前端Apache分發機制的負載均衡功能確實不盡如人意，2節點主機的連接數都達到200的極限值了，可故障發生當時另外一臺主機1節點的連接數還不到120；很顯然。基于Apache軟件分發負載均衡的功能還是大大弱于類似F5等硬件負載均衡機制的。

主要有兩個原因：

  • 硬件負載均衡設備可根據連接數、后臺服務器的負載壓力判斷實現真正的負載均衡；而Apache基本上是采用輪詢的方式。
  • 另外用apache、tomcat這種部署方式導致主分發節點成為了單點，一旦這個節點出現故障，整個系統就會癱瘓；而硬件負載均衡設備可以實現每個節點均可充當主節點，大大提升系統可靠性和高可用性。
如果系統采用了硬件負載均衡設備，兩臺應用服務器的連接數會保持均衡，比如都是160~170左右，應該可以規避10月27日下午發生的故障。

強烈建議：如系統后續有升級改造，在資金寬裕的情況下，采用硬件負載均衡設備。

應急預案

以后針對應用的類似問題，我方建議采用以下應急預案。
當主機的應用出現癱瘓的情況下，首先重啟服務優先保證應用的持續運行，再進行故障診斷、排錯及后續的優化。
因此需要建立相應的應急數據抓取機制，以便問題發生后可以對當時的運行情況進行分析找出問題根本原因，抓取的內容由各家聯合統一進行分析。

數據抓取內容如下：

  • 連接數抓取，用于分析數據庫連接使用情況。
    執行sql如下：
    select username,machine,count(username) from v$session where username is not null and username <> SYS group by machine,username order by machine
    分別在數據庫服務器1和2上執行。
  • 應用服務器日志抓取，分析程序錯誤。當前日志保存5個歷史文件，如有問題發生很有可能會大量產生日志，導致前面的日志被沖掉，所以需要加大日志保存的數量和時間。
  • 數據庫鎖情況抓取。
  • 應用服務器內存快照抓取，用于分析問題發生時系統正在運行的程序。
  • 應用服務器內存、cpu使用情況抓取。

本文作者：李松樺（上海新炬王翦團隊）

本文來源：“IT那活兒”公眾號

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/129315.html

相關文章

  • 2月第3周業務風控關注|上海網信辦復測23個被約談APP 涉及1號店、小紅書等

    摘要：上海網信辦復測個被約談涉及號店小紅書等近日，上海市網信辦對此前被約談的個開展回頭看復測工作，要求各企業按照整改報告切實做好整改工作。 易盾業務風控周報每周呈報值得關注的安全技術和事件，包括但不限于內容安全、移動安全、業務安全和網絡安全，幫助企業提高警惕，規避這些似小實大、影響業務健康發展的安全風險。 1、上海網信辦復測23個被約談APP 涉及1號店、小紅書等 近日，上海市網信辦對此前被...

    forsigner 評論0 收藏0

  • 1月第1周業務風控關注| 國家網信辦啟動專項行動 劍指12類違法違規互聯網信息

    摘要：國家網信辦啟動專項行動劍指類違法違規互聯網信息近日，針對網絡生態問題頻發各類有害信息屢禁不止等突出問題，為積極回應民眾關切，國家網信辦啟動網絡生態治理專項行動。中國鐵路總公司官方微博回應網傳信息不實，網站未發生用戶信息泄露。 易盾業務風控周報每周呈報值得關注的安全技術和事件，包括但不限于內容安全、移動安全、業務安全和網絡安全，幫助企業提高警惕，規避這些似小實大、影響業務健康發展的安全風...

    張巨偉 評論0 收藏0

  • 深度分析 | MGR相同GTID產生不同transaction故障分析

    摘要：對于該故障的分析，我們要從主從實例相同，但是事務不同的原因入手，該問題猜測與相關，我們針對同步事務的時序做如下分析。接受者被動接收提議者的提議，并記錄和反饋，或學習達成共識的提議。節點將的提案信息發送至組內，仍收到了大多數成員返回。 本文是由愛可生運維團隊出品的「MySQL專欄」系列文章，內容來自于運維團隊一線實戰經驗，涵蓋MySQL各種特性的實踐，優化案例，數據庫架構，HA，監控等...

    wuaiqiu 評論0 收藏0

發表評論

0條評論

IT那活兒

男|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<