搜索有個(gè)應(yīng)用就是每次都會(huì)去查一個(gè)接口，接口返回用戶的信息數(shù)據(jù)，從而展現(xiàn)不同的篩選和排序效果。大致流程如下

    s.taobao.com(hz)-> memcache ->電信custom接口 ->master-db

    s.taobao.com(qd)-> 網(wǎng)通custom接口 -> slave-db

    接口環(huán)境是php(cgi) + nginx，接口已經(jīng)運(yùn)行很久，未出過異常

    搜索訪問custom接口，然后接口去查數(shù)據(jù)庫(kù)(數(shù)據(jù)庫(kù)是主從復(fù)制，數(shù)據(jù)同步，各自機(jī)房讀各自的數(shù)據(jù)庫(kù)，寫的話都寫master-db)

    有一點(diǎn)，就是電信機(jī)房是有memcache層的，而網(wǎng)通機(jī)房一直沒有(考慮到網(wǎng)通機(jī)房流量不高，并且機(jī)房cache不同步，從上線起就網(wǎng)通機(jī)房一直未使用cache)

    有一次搜索上線，這個(gè)上線的版本有個(gè)改動(dòng)就是把電信機(jī)房的memcache也取消了，然后 電信機(jī)房流量暴增

    看pv統(tǒng)計(jì)：

    [admin@linux ~]$ xxx.sh “find ./ -name ‘access*’|xargs wc -l|awk ‘END{print$1}’” fe

    cmd :find ./ -name ‘access*’|xargs wc -l|awk ‘END{print }’

    type:fe

    server1

     27720029 total(28號(hào)是11428684total)

    ———-

    server2

     27719910 total(28號(hào)是11429158total)

    ———-

    server3

     21084539 總計(jì)

    ———-

    server4

     21086051 total

    網(wǎng)通機(jī)房流量一直都是2KW左右，從未出任何問題

    就是昨天電信custom接口流量暴增后，出現(xiàn)了異常，電信機(jī)房機(jī)器負(fù)載一度達(dá)到48左右，QPS達(dá)到1533，直到凌晨0：24分才降到1以下

    應(yīng)用也報(bào)了短暫的超時(shí)警報(bào)，不過php和nginx運(yùn)行還是比較蛋定，重啟依然非?？?，終端也沒有出現(xiàn)很卡的情況

    29號(hào)流量：

    28號(hào)流量：

    異常就是error.log在上線后飆到3個(gè)G?。?！

    而且錯(cuò)誤全都是Can’t connect to MySQL server on ’1.1.1.1′ (99)

    即便在命令行下用mysql -h1.1.1.1 -u -p

    也間歇性地連接不上，但是據(jù)dba描述，數(shù)據(jù)庫(kù)監(jiān)控?zé)o任何異常，數(shù)據(jù)庫(kù)上其他部門的應(yīng)用也無異常

    不知是否機(jī)器負(fù)載過高導(dǎo)致大量time wait，導(dǎo)致mysql連接超時(shí)或連接不上

    以下是晚上0點(diǎn)13分的監(jiān)控：

    80端口連接數(shù)(CurrentConnection): 16

    nginx進(jìn)程數(shù)量: 10

    php進(jìn)程數(shù)量: 130

    TCP連接狀態(tài):

    TIME_WAIT 26258(不知是否和他有關(guān))

    FIN_WAIT1 1

    FIN_WAIT2 6

    ESTABLISHED 893

    按理說，custom的網(wǎng)通接口流量一直是日均2KW，從未出現(xiàn)過異常，杭州機(jī)房接口飆到2.7KW就抗不住了，load直線上升，

    為了排除cache引起的流量導(dǎo)致接口異常，22：30左右重新上了2個(gè)文件，把杭州機(jī)房的memcache重新開啟，

    開啟后慢慢load是降了，但是mysql錯(cuò)誤依舊只是沒那么多了

    現(xiàn)在去機(jī)器上看，還是大量錯(cuò)誤，提取日志如下

    2011/12/3010:23:58 [error] 23859#0: *19554416 FastCGI sent in stderr: “PHPWarning: mysql_connect() [

    后來跟dba不斷溝通排查，發(fā)現(xiàn)電信機(jī)房和網(wǎng)通機(jī)房的/etc/sysctl.conf配置有所區(qū)別

    網(wǎng)通機(jī)房多了下面幾行

    net.ipv4.tcp_syncookies =1

    net.ipv4.tcp_tw_reuse = 1

    net.ipv4.tcp_tw_recycle =1

    net.ipv4.tcp_fin_timeout= 5

    原因就在這，把配置同步到杭州機(jī)房后，問題就解決了，總結(jié)如下：

• 問題描述
• 上線異常導(dǎo)致qps：1500+，負(fù)載：48+，雖然nginx+php表示很淡定沒掛，但error.log飆到了3G/天，全是Can’t connect to MySQL server on ‘*.*.*.*’ (99)
• 解決異常后，error.log日志少了，但TIME_WAIT依舊減不下去，數(shù)據(jù)庫(kù)依舊連接是失敗
• 問題排查
• Mysql Config ? (no problem)
• max_connect_errors = 50000 (no problem)
• max_connections = 1000 (no problem)
• max_user_connections = 950 (no problem)
• OS Config ? (problem, 按以下修改問題就解決了)
• vi /etc/sysctl.conf// 編輯net.ipv4.tcp_syncookies = 1net.ipv4.tcp_tw_reuse = 1

      net.ipv4.tcp_tw_recycle = 1

      net.ipv4.tcp_fin_timeout = 5

      // 讓參數(shù)生效

      /sbin/sysctl -p

• 問題原因
• 報(bào)錯(cuò)”Can’t connect to MySQL server on ‘*.*.*.*’ (99) ” 參考MySQL Client端錯(cuò)誤代碼說明：錯(cuò)誤代碼為99，99的含義：$perror 99 OS error code 99: Cannot assign requested address 這是一個(gè)本地OS的拋錯(cuò)，表示無法分配本地地址資源(應(yīng)該是端口)，socket無法創(chuàng)建
• Google一下” Cannot assign requested address”，多半是由于客戶端請(qǐng)求過于頻繁，而Server端練級(jí)關(guān)閉后本地暫時(shí)處于TIME_WAIT，所以暫時(shí)端口都不可用導(dǎo)致。因此修改下OS參數(shù)就ok了
• 問題反思
• 這個(gè)問題非常緊急么？緊急！
• 參考文章《nginx+php產(chǎn)生大量TIME_WAIT》：http://leven.blog.51cto.com/1675811/382097，遇到這樣的問題，我們應(yīng)該第一時(shí)間想到端口不可用，首先會(huì)導(dǎo)致nginx連不上php-cgi導(dǎo)致服務(wù)不可用，其次才是php-cgi連不上mysql，因此非常重要！
• 為什么mysql不使用長(zhǎng)連接pconnection呢？
• pconnection mysql占用大量資源，并且在大并發(fā)情況下，例如個(gè)性化，活動(dòng)促銷等，連接過多導(dǎo)致無數(shù)的連接失敗error，并牽制apache(nginx)ThreadsPerChild的參數(shù)
• 高并發(fā)下的最佳實(shí)踐？
• apache短連接，nginx短連接，mysql短連接，雖然TIME_WAIT多了，但可通過修改OS內(nèi)核加速TIME_WAIT的復(fù)用，經(jīng)驗(yàn)之談?。?/li>

【編輯推薦】

1. Linux中history歷史命令使用方法詳解
2. Linux下使用mke2fsk格式化分區(qū)的方法
3. Ubuntu 11.10 利用終端環(huán)境備份還原