某局點公升級(nginx變ats，同時去掉前端的nginx負載層)，公升級之後服務就不正常，硬生生的看著十幾萬連線，沒有流量，各種排錯，可謂是把心提到嗓子眼驚心動魄的半小時，雖然做了很好的業務機制，服務不正常使用者可以直接回源，不過對於我們的流量而言肯定是個鋸齒了，回顧一下排查過程。
公升級過程不說了，公升完後對業務配置、健康心跳、磁碟設定、本地回源dns簡單做了檢查，沒發現問題。接下來就是切流量過來，前端的dns按照網域名稱雜湊將請求分發過來，流量迅速到了100m還在上公升，連線數到了幾萬（網域名稱質量不好，很多動態的，所以也算正常），但過了幾分鐘流量驟降，一直降到了幾m，觀察連線數沒降反公升，記憶體幾乎吃滿。
（當前連線數）
（進出流量及cpu、記憶體、tcp重傳1秒重新整理動態監控圖，記憶體越跑越滿，tcp重傳越來越高）
神經馬上緊張起來了，先檢查dns是否正常，因為本地回源dns如果壞掉，會出現這種攢了大量連線無法服務的情況，然而測試發現本地回源dns服務正常，看來不是簡單問題，crt開啟多個視窗，開始監測：
tailf /var/log/messages |grep kernel 沒有報錯，系統層面應該沒什麼問題。
tailf /opt/ats/var/log/trafficserver/diags.log 沒有明顯報錯，只是過一段時間會提示連線太多，丟棄連線，說明業務肯定是不正常了，不過定位不了是**的錯誤。
tstop開啟後檢視整體的情況，發現正常重新整理，但是每次重新整理有些資料不能正常顯示，記憶體快取和硬碟快取的容量都沒有顯示，為什麼沒有顯示呢，是設定錯誤了麼，然後再去檢查磁碟設定，發現records.config記憶體快取設定為記憶體的一半12g，storge.config設定也沒問題，繼續檢查。
tsar –l 1 監測，磁碟io都為0，所有的盤都不寫盤，於是想到底是因為沒有流量導致不寫盤的，還是寫不了盤導致沒有流量的呢，先假設不寫盤才沒流量的吧，不寫盤有兩種情況一是盤壞了二是磁碟的許可權不對，馬上檢查，發現所有的資料盤擁有者所有組均為tserver，而且檢查了全為裸盤，貌似沒有問題。
(許可權檢視後發現沒問題)
tsar –n 1 繼續檢查下歷史資料，發現ats啟動的瞬間是有流量的，緊接著流量驟降，而且磁碟剛開始是有io的，越來越懷疑是硬碟問題但沒有證據。後來想，做個測試，乾脆不用硬碟，直接上記憶體，竟然有流量了，而且相對穩定，終於定位出問題了。
（將盤全部注釋掉）
繼續想，難道所有的硬碟都壞了麼，加入乙個硬碟試試吧，依舊不行，繼續想下去，為什麼tstop計算不出快取呢，於是列出所有磁碟的大小，發現這個局點的每塊磁碟居然有將近2t左右，圖如下：
（只有乙個盤是186.5g，其餘的盤都在2t）
繼續想可能是磁碟太大了，ats無法加入進來吧，
於是更改使用磁碟的大小（300g），重啟ats，問題解決，
松了一口氣，驚心動魄半小時。
（磁碟大小配置更改，直接指定大小）
（更改重啟後，業務恢復正常）
本文出自 「奔跑的linux」 部落格，請務必保留此出處
十 連線查詢
10.1 sql92語法 連線查詢 也可以叫跨表查詢，需要關聯多個表進行查詢 1 顯示每個員工資訊，並顯示所屬的部門名稱 以上輸出，不正確，輸出了56條資料，其實就是兩個表記錄的乘積，這種情況我們稱為 笛卡兒乘積 出現錯誤的原因是 沒有指定連線條件 2 指定連線條件 以上結果輸出正確，因為加入了正確...
負債十幾萬學英語，你學的也許只是「焦慮」
人的時間 精力都非常有限，分不清主次，不僅無法增加你的核心競爭力，相反可能讓你陷入陷阱，失去方向。知道 nz zhidao 跟你談談，負債十幾萬學英語，值得嗎？學英語以至致於揹負了十幾萬元的貸款，你敢相信嗎？為什麼揹負貸款也要學英語？林燦事後回憶 銷售一直對我說，就是沒學英語找不到工作，學了英語才有...
mysql 幾十連線 mysql的幾種連線方式
下面是例子分析 表a記錄如下 aid anum 1 a20050111 2 a20050112 3 a20050113 4 a20050114 5 a20050115 表b記錄如下 bid bname 1 2006032401 2 2006032402 3 2006032403 4 20060324...