在這以後裡分享一篇關於web應用緩慢的分析過程，感覺挺有用的。

友在一家購物網站做運維不久，今日打電話說前臺頁面開啟比較慢訂單無法正常投遞，但是檢視CPU使用率較低沒什麼壓力，只是記憶體稍高86%左右，磁碟讀寫也很正常，諮詢我怎麼進行解決。我問了他一些基本的系統架構問題，知道是F5做的負載均衡分發到前端10臺應用伺服器上，中介軟體是JBOSS，後端資料庫是ORACLE.整理了下思路，決定讓朋友進行如下分析：

一、登陸前端應用伺服器，首先檢視統計ip連線數 [[email protected] ~]$ netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n       1        1 Address       1 servers)       2 172.16.100.35       2 172.16.100.38       2 172.16.100.45       4 127.0.0.1      10 172.16.100.18      20 172.16.100.8    2048 172.16.100.98 #在伺服器和負載均衡間有2048個連線 檢視JBOSS應用埠8080的情況 [

[email protected] ~]$ netstat -ntu |grep 8080 tcp        0      0 172.16.100.26:8080     172.16.100.98:19593           TIME_WAIT    tcp        0      0 172.16.100.26:8080     172.16.100.98:16777           TIME_WAIT    tcp        0      0 172.16.100.26:8080     172.16.100.98:11913           TIME_WAIT    tcp        0      0 172.16.100.26:8080     172.16.100.98:1929            TIME_WAIT    tcp        0      0 172.16.100.26:8080     172.16.100.98:53641           TIME_WAIT    tcp        0      0 172.16.100.26:8080     172.16.100.98:43401           TIME_WAIT    tcp        0      0 172.16.100.26:8080     172.16.100.98:36233           TIME_WAIT    tcp        0      0 172.16.100.26:8080     172.16.100.98:28040           TIME_WAIT    tcp        0      0 172.16.100.26:8080     172.16.100.98:5000            TIME_WAIT    ............................................................... ............................................................... ............................................................... [

[email protected] ~]$ netstat -ntu |grep 8080|grep TIME_WAIT |wc  -l 2003 通過以上內容顯示，在前端應用伺服器和負載均衡間產生了大量TCP等待，這正是消耗記憶體並把前臺應用拖慢的主要原因。由負載均衡分發到應用伺服器的大量請求可能由於JBOSS的處理瓶頸產生了等待，實際處理的請求遠小於分發過來的請求。 二、檢視JBOSS連線數設定 一般中介軟體jboss連線後端的oracle，在deploy下會有個檔案oracle-ds.xml，我們看一下它連線資料庫的程式碼： <local-tx-datasource>     <jndi-name>jdbc/TETD</jndi-name>     <connection-url>jdbc:oracle:thin:@172.16.100.18:1521:orcl</connection-url>     <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>     <user-name>TETD_QT</user-name>     <password>Hpoui&bmn$m#

[email protected]</password>         <min-pool-size>20</min-pool-size>         <max-pool-size>50</max-pool-size>     <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>   注意：<min-pool-size>的值設的是20，<max-pool-size>設的值是50 三、檢視ORACLE連線數設定 SQL>select count(*) from v$process --當前的連線數 顯示為45 SQL>select value from v$parameter where name = 'processes' --資料庫允許的最大連線數 顯示為600 (注:當資料庫最大連線數不夠時會出現客戶端連線間歇性失敗，報錯ORA-12519) 通過以上資料分析，在ORACLE端顯示的連線數並沒有體現出應有的壓力，那麼瓶頸在哪？應該是JBOSS上，JBOSS的連線池引數設定的太小，導致前端的請求卡在JBOSS處而不能正常通過JBOSS連線到後端ORACLE，從而導致前臺應用緩慢訂單不正常。 分析完畢後，告訴朋友增大JBOSS連線池引數，把<min-pool-size>調整為200，</min-pool-size>調整為500.後來朋友調整了JBOSS連線池引數後，問題得到了顯著緩解，記憶體使用率也降下來了。 這一事例告訴我們，一個水管中間最細處往往決定了通過的水流量，我們在優化後端ORACLE資料庫的同時也別忘了優化中介軟體的引數。 補充1、修改ORACLE最大連線數： #修改oracle最大連線數: alter system set processes = 1000  scope = spfile; 重啟資料庫: shutdown immediate; startup; 補充2、修改/etc/sysctl.conf檔案
net.ipv4.tcp_max_tw_buckets = 3000
表示系統同時保持TIME_WAIT套接字的最大數量，如果超過這個數字，TIME_WAIT套接字將立刻被清除並列印警告資訊。預設為180000，改為 3000。此項引數可以控制TIME_WAIT套接字的最大數量，避免伺服器被大量的TIME_WAIT套接字拖死。