當記憶體512遇上Access資料庫600M，IO磁盤受傷了

伺服器記憶體就512m，access資料庫（文章庫）600多m，結果竟然就是io受傷了。

雖然本人目前對access恨入之骨，皆因囊中羞澀,暫時不得不與之同流合污。

然而這個隐藏多年的内傷，如果不是那一天，客服把我伺服器給關機了，估計到現在也沒察覺，讓io受傷了好幾個月了。

以下是故事的過程，有興趣掃一眼，沒興趣直接拉到後面看結果：

就在那天，伺服器讓客服給直接關機了，理由是：cpu持續三小時100%，io磁盤每秒讀寫50m，為不影響其它使用者，直接給關了，讓處理完再開機。

前面的cpu百分百是忽悠我的，因為你對客戶說，因磁盤讀寫問題而關機，比較懸，如果說cpu滿了而關機，都直覺容易了解。

不過，因為剛才我還在看着伺服器，cpu正常，根本不可能持續三小時百分”（當然了，偶爾應用程式池剛重新開機時，瞬時十來秒上到100%這個我知道，由于是短暫的，我一直沒查明真相）我讓客服給我截圖，并恢複開機，我說cpu我會處理。

神奇的客服，給我截了另一張圖，說我磁盤讀寫超标，讓我處理完再開機。

從這圖看的出來，這台伺服器上至少擠了好幾十個vps使用者了。

磁盤讀寫超标，是件很懸的事件，首先這超标的标準是什麼？硬碟每秒讀寫速率達到多少才算超标？這超标又怎麼影響到其它使用者了？

當然了，誰家的網站不經常讀寫io呢，這vps就這麼丁點記憶體，肯定重點就會轉發到硬碟去了，習慣性思維以為是自己的程式問題，因為實在平時對磁盤讀寫沒怎麼在意，好像開發這麼久，還沒怎麼和磁盤的負載扯上關系，這一塊是一片空白。

于是，當開機後，使用者一張一張的截圖，說讓我處理，着實把我弄急了：

沒辦法，我隻好暫時把秋色園網站停止，說我要去吃飯了（八九點還不讓人吃飯），然後問客服，降下來沒有，客服說：我看到依然還是有問題 。 我先斷開你的網絡把，你吃完飯後回來 聯系我處理。

我急了，肯定不能斷開網絡了，畢竟微網誌粉絲精靈服務還在運作，沒辦法，我下了下手，把粉絲精靈服務也給關了，問，現在正常了沒有，客服又來一張圖說：現在正常一些了 0.59是1分鐘内的負載，1.68是五分鐘内的平均負載

我特糾結，伺服器一共就兩網站，這全都關了，你隻是正常了點，靠，直接把遠端密碼發給對方，你去折騰，我去吃飯。

快速吃完回來問客服情況怎樣，對方三弄幾弄，說正常了，我問弄什麼了，對方說：“app_data 這個目錄 我随便改了名字。   除此之外 我都沒有動 ”。

這目錄下就放着資料庫，我說難道和資料庫有關？裡面有一個資料庫600多m（文章表）。

客服說可能，但不确定。

于是我把秋色園解析解到其它地方，然後再開啟網站，自己通路一下，才剛開，客服馬上問我幹啥了，負載又上去了，弄的我隻好網站又停了，停了還沒用，客服一樣叫高，接着又來一張圖：

說實在，我都不明白這些代表啥意，于是問了，這些怎麼看，對方回答“高于 1 即資源超載，三個數字1分鐘，5分鐘，10分鐘内的系統平均負載”。

我糾結了：不占cpu，不占記憶體，不占帶寬，如果磁盤也不占，這網站怎麼折騰？

還有這磁盤，是讀高，還是寫高？

對方答複“隻能看一個系統分析值 ，就是vps虛拟化自帶的分析圖”。

接下來，我又把資料庫的檔案夾給改名了，看似得到的回複是正常了，瞬時好似問題的根源，就在于600多m的access資料庫上。

結果：

多年隐藏的内傷表現：

當access的資料庫大小超過記憶體的大小時，相關問題主要表現在磁盤讀寫超标（這個正常沒法知道）。

内傷一：界面影響特卡（可能會以為是cpu或記憶體問題）。

内傷二：還會影響到其它vps使用者（這個更不可能得知了）。

内傷三：同時應用程式池重新開機變慢（會誤以為是程式寫的不好）。

内傷四：記憶體占用明顯上去了（誤以為緩存了html導緻的)。

為此，access雖然上限是2g，具體還得看你記憶體有多少，通常硬體不佳記憶體小才用access，是以在使用時，量力而大！！！

版權聲明：本文原創發表于部落格園，作者為路過秋天，原文連結：

http://www.cnblogs.com/cyq1162/archive/2012/01/20/2327698.html