中文站技術(shù)故障總結(jié)----21條建議

1、阿里巴巴版權(quán)所有 1999-2008中文站技術(shù)故障總結(jié)中文站技術(shù)故障總結(jié)-2121條建議條建議 楊爭2008-6-19內(nèi)容內(nèi)容 建議、案例、原因。 編碼、設(shè)計、cache、SQL、應(yīng)用腳本、日志。 總結(jié)。阿里巴巴版權(quán)所有 1999-2008編碼編碼 建議建議1 1 建議建議1：代碼：代碼ci之前通過之前通過svn diff確認(rèn)修改的確認(rèn)修改的內(nèi)容，以避免把不應(yīng)該修改的代碼給內(nèi)容，以避免把不應(yīng)該修改的代碼給ci了。了。 案例：這種情況發(fā)生已經(jīng)不止一兩次了，有的是為了本次測試的方便，臨時把cache去掉了，但ci了時候沒有改回來；有的是修改了臨時配置文件，結(jié)果也ci上去。 原因：忘 ！阿里巴巴版權(quán)

2、所有 1999-2008編碼編碼 建議建議2 2 建議建議2：調(diào)用對象的方法，一定要明確該對調(diào)用對象的方法，一定要明確該對象是否會空，不能確定時要判斷象是否會空，不能確定時要判斷。 案例：由于NullPointException造成應(yīng)用bug的情況也是屢見不鮮。比如：商鋪升級項目發(fā)布，有兩個會員投訴無法使用布置櫥窗。后來查明原因，程序中的空指針異常所致，影響沒有過商鋪行為的TP會員。 原因：開發(fā)者常常會自認(rèn)為該對象不為null，而沒有去看代碼的實現(xiàn)或者沒有思考周全，漏掉了一些分支情況。阿里巴巴版權(quán)所有 1999-2008編碼編碼 建議建議3 3 建議3：編寫遠(yuǎn)程調(diào)用代碼，建議采用穩(wěn)定的開源軟件

3、(如httpclient)，盡量少自己直接sock編程。 案例：2005年exodus集群幾乎全部死掉,無法工作。 原因：貿(mào)易通接口的源代碼在連接服務(wù)器的時候SocketChannel使用不當(dāng)所致。注:SocketChannel是jdk1.4之后,NIO中的API,比傳統(tǒng)的Socket時候起來更方便,性能也會更好，但是不能和以前的Socket混用,否則就會出問題。阿里巴巴版權(quán)所有 1999-2002編碼編碼 建議建議4 4 建議建議4 4：不要往：不要往cookiecookie中設(shè)置過多過大的數(shù)據(jù)中設(shè)置過多過大的數(shù)據(jù)，同時中文站，同時中文站cookiecookie的的domaindomain不

4、要設(shè)錯。不要設(shè)錯。 案例：資訊上線之后出現(xiàn)的cookie過大的問題，造成后臺用戶無法登陸。 原因：系統(tǒng)現(xiàn)在cookie過于龐大. 導(dǎo)致大量使用代理服務(wù)器的用戶或者部分ISP會把過大HTTP header請求給屏蔽掉.造成客戶訪問不了我們的站點. 寫入cookie的域為 ，而網(wǎng)站寫入cookie的域為，這樣的會出現(xiàn)兩份的cookie發(fā)送。阿里巴巴版權(quán)所有 1999-2008編碼編碼 建議建議5 5 建議建議5 5：程序中打印日志時，一定要考慮該日：程序中打印日志時，一定要考慮該日志可能的增長量志可能的增長量。 案例：國際站的案例：國際站的usweb21服務(wù)器 /home 這個分區(qū)的空間會滿掉。

5、原因:由于BuyOfferToFeedbackOut.log這個日志太大,導(dǎo)致/home 這個分區(qū)的空間會滿掉。阿里巴巴版權(quán)所有 1999-2008設(shè)計設(shè)計 建議建議6 6 建議建議6 6：設(shè)計應(yīng)用時，要考慮其對系統(tǒng)性能的：設(shè)計應(yīng)用時，要考慮其對系統(tǒng)性能的影響。影響。 案例： 論壇Load過高。 原因：因為一些帖子的回帖數(shù)過多，而我們的顯示方式是樹狀顯示，并且會把一些body的內(nèi)容取出來處理，造成機(jī)器的cpu一直在處理這個事情而load過高?，F(xiàn)在已經(jīng)對程序做了修改優(yōu)化，并刪除了這個帖子，現(xiàn)在load已經(jīng)降下來了。阿里巴巴版權(quán)所有 1999-2008 建議建議7：使用使用synchronized

6、 (this)synchronized (this)要小心要小心。 案例：blog服務(wù)器不定時的報警。 原因：文章的cache dao的多個方法都采用了syncronized(this)塊同步，而cache dao是singleton，這樣鎖就是唯一的鎖，當(dāng)一個線程訪問cache dao的一個synchronized(this)同步代碼塊時，其他線程對該對象中所有其它synchronized(this)同步代碼塊的訪問將被阻塞。同步 建議7CACHE CACHE 建議建議8 8 建議建議8：任何數(shù)據(jù)放入任何數(shù)據(jù)放入CacheCache中都要考核這些中都要考核這些數(shù)據(jù)是否符合這三個指標(biāo)數(shù)據(jù)是否符

7、合這三個指標(biāo)( (更新頻率、訪問量更新頻率、訪問量、命中率、命中率) )。我們要把更新不頻繁，訪問量高。我們要把更新不頻繁，訪問量高，命中率高的數(shù)據(jù)放入，命中率高的數(shù)據(jù)放入CacheCache中。同時慎用中。同時慎用OSCACHEOSCACHE的文件持久化。的文件持久化。 案例：news服務(wù)器不同穩(wěn)定。 原因：貿(mào)易通inside這個頁面里面有一個調(diào)用getHtmlByUrl的方法，會根據(jù)不同的memberid，返回不同的拍賣信息。發(fā)現(xiàn) cache目錄下auction這塊內(nèi)容的文件有25000個，文件太多，嚴(yán)重占用了服務(wù)器的資源,導(dǎo)致服務(wù)器響應(yīng)慢，甚至出現(xiàn)too many open file 。

8、阿里巴巴版權(quán)所有 1999-2008CACHE CACHE 建議建議9 9 建議建議9 9：序列化對象時要考慮：序列化對象時要考慮sidsid變化造成的變化造成的影響。影響。 案例：中文站某個下午5:20開始，陸續(xù)有故障報上來，幾乎所有Free+會員的旺鋪無法訪問。 原因：member cache的類修改和新增了屬性，并沒有改動SUID的值。從cache中反序列化出來的MemberSpecialSign對象的multiSign字段的值為默認(rèn)值0，造成所有Free+會員的網(wǎng)站都無法訪問。阿里巴巴版權(quán)所有 1999-2008SQL SQL 建議建議1010 建議建議1010：所有的：所有的SQLS

9、QL語句都必須經(jīng)語句都必須經(jīng)DBADBA審核。審核。 案例：論壇數(shù)據(jù)庫發(fā)生異常情況，無法連接數(shù)據(jù)庫，于是DBA切換到備機(jī)，各個系統(tǒng)啟動正常，但是10分鐘后突然出現(xiàn)Load巨高從1以下一路竄升到了10,20,30直到70，所有和數(shù)據(jù)庫相關(guān)的系統(tǒng)再次崩潰。 原因：blog這邊一個可疑的sql。SELECT * FROM SQ_FORUM_THREAD WHERE MEMBER_ID=#memberId# AND ROWNUM to_date(#vdate#,gmt_createto_date(#vdate#,yyyy-mm-dd hh24:mi:ssyyyy-mm-dd hh24:mi:ss);)

10、; 不要使用: Select * from cmnty_user_feedback where gmt_create#vdate# gmt_create#vdate#。原因：直接使用 日期類型變量，在oracle中測試過程跟蹤的時候發(fā)現(xiàn)無法獲得這個變量的值。支付寶曾經(jīng)發(fā)現(xiàn)該類型變量存在bug，可能導(dǎo)致用不上該日期字段上的索引。阿里巴巴版權(quán)所有 1999-2008CLOB CLOB 建議建議1515 建議建議1515：建議數(shù)據(jù)庫表中：建議數(shù)據(jù)庫表中ClobClob字段獨立出來字段獨立出來為一張表。為一張表。 案例：阿寶二期發(fā)布后出現(xiàn)問題CLOB字段引起的問題。 原因：SQL本身并沒有問題，因為這

11、個表有CLOB字段，而且使用select *。 Select email from auction不包含CLOB字段邏輯讀只有20,SELECT * FROM AUCTION 包含CLOB邏輯讀有200。阿里巴巴版權(quán)所有 1999-2008SQL SQL 建議建議1616 建議建議1616：分頁：分頁SQLSQL語句務(wù)必保證語句務(wù)必保證ORDER BYORDER BY子句子句的唯一性的唯一性 。 案例： 原因：分頁的SQL中沒有保證ORDER BY子句的唯一性，這樣會導(dǎo)致分頁錯誤，有些記錄會在多頁中出現(xiàn)，而有些則永遠(yuǎn)都顯示不出來 。阿里巴巴版權(quán)所有 1999-2008建議建議1717 建議建議

12、1717：oracleoracle的驅(qū)動建議采用的驅(qū)動建議采用thinthin驅(qū)動，驅(qū)動，而不要采用而不要采用ocioci驅(qū)動。驅(qū)動。 案例：forum_web1到forum_web13 http頁面全部訪問超時， weblogic 全部僵死,重起后恢復(fù)。 blog_web2 HTTP 報警，超時，后來blog_web1,blog_web3也報超時，重啟服務(wù)，另每到周末blog_web就會不穩(wěn)定 。 原因：Oracle的oci驅(qū)動本身存在一定的問題，在一定情況下jvm會crash，且發(fā)現(xiàn)問題無法跟蹤 。阿里巴巴版權(quán)所有 1999-2008數(shù)據(jù)庫數(shù)據(jù)庫 建議建議1818 建議建議1818：數(shù)據(jù)庫

13、的變更，要必須提前：數(shù)據(jù)庫的變更，要必須提前1-31-3天提天提交交DBADBA并做好準(zhǔn)備，特別是一些大表或者表上并做好準(zhǔn)備，特別是一些大表或者表上有的有的triggertrigger或者或者packagepackage。 案例：中文站執(zhí)行了 offer 表增加字段的變化，導(dǎo)致detail的訪問也出現(xiàn)異常。 原因：中文站執(zhí)行了 offer 表增加字段的變化，然后trigger編譯沒有快速通過，估計這個時候碰巧有比較多的offer 數(shù)據(jù)在發(fā)生變化導(dǎo)致多個進(jìn)程都嘗試編譯tiggger。于是阻塞了offer 表的DML（增加、刪除、修改）語句。而offer表的阻塞導(dǎo)致應(yīng)用連接消耗光引起offer d

14、etail的訪問也出現(xiàn)異常，同時凡是應(yīng)用服務(wù)器有對offer進(jìn)程dml的應(yīng)該都會阻塞。阿里巴巴版權(quán)所有 1999-2008應(yīng)用腳本應(yīng)用腳本 建議建議1919 建議建議1919：應(yīng)用啟動腳本中必須：應(yīng)用啟動腳本中必須JBossJBoss啟動完畢啟動完畢后再啟動后再啟動apacheapache 。 案例：國際站下午程序發(fā)布失敗，首頁打不開，持續(xù)了10分鐘左右。 原因：由于發(fā)布時外部訪問量較大，而程序裝載時間較長，目前的應(yīng)用重啟機(jī)制是Resin與Apache同時重啟動，所以導(dǎo)致Resin尚未完全裝載程序之時即開始接受外部客戶請求，使得Resin被涌入的大量請求壓垮。阿里巴巴版權(quán)所有 1999-200

15、8應(yīng)用腳本應(yīng)用腳本 建議建議2020 建議建議2020：kill apachekill apache進(jìn)程時別忘了清除共享進(jìn)程時別忘了清除共享內(nèi)容。內(nèi)容。 ipcs -m|grep admin|awk print $2|xargs ipcrm shm ipcs -m|grep admin|awk print $2|xargs ipcrm shm ipcs -s|grep admin|awk print $2|xargs ipcrm sem ipcs -s|grep admin|awk print $2|xargs ipcrm sem 案例：中文站發(fā)布過程中我們注意到apache沒起來的情況還是有一些keywords發(fā)布，影響到應(yīng)用了，中間服務(wù)down了約35分鐘。 。 原因：由于共享內(nèi)存沒有清理，導(dǎo)致apache服務(wù)起不來。阿里巴巴版權(quán)所有 1999-2008日志日志 建議建議2121 建議建議2121：請消除：請消除所有所有的的velocityveloc