您在這裡

服務器磁盤文件統計數據,準備購置高速硬盤

James Qi 在 2011年4月3日 - 17:50 發表

  前一陣子新換了3台服務器,都是配置的16核(4路4核)CPU、16G内存,算是很強大了,不過配置的硬盤隻是2個1T普通7200轉台式機硬盤,根據這些天的觀察,在添加數據、更新模闆的時候,用iostat查看會遭遇明顯的IO瓶頸,在cpu、内存富餘很多的情況下,磁盤的利用率長期100%。

  我們把MySQL和Web(包括Squid和Apache)服務的數據放在兩塊不同的硬盤上,先以為隻是MediaWiki網站全文檢索時MySQL的MyISAM數據庫大文件頻繁讀寫使硬盤應付不過來,後來根據仔細觀察,發現MySQL的全文檢索本身性能不好,在處理大量數據的時候容易使CPU卡住,同事調試了Sphnix來做全文檢索可以輕易對付一個網站目前平均每分鐘2次的搜索量。不過在Drupal網站新建全文索引表的過程中,确實還是遇到明顯的硬盤瓶頸,平均每秒隻能生成5條左右,當網站數據量在數十萬以上時需要耗費以幾十小時來記的時間,這個過程中硬盤處于繁忙狀态,無法多個網站同時生成。

  後來又在MediaWiki模闆更新中也感覺硬盤處理不過來,今天詳細統計了目前幾個主要服務(Squid, Apache, MySQL)的磁盤使用情況,列表如下:

服務器編号 服務名稱 占用空間 文件數量 文件平均大小 備注說明
17 Squid 92G 10M 9.2K 數量大于Apache下靜态文件,原因不明?
Apache 47G 3.6M 13K 目前全為MediaWiki網站
MySQL 105G 23K 4.6M 有其它幾台服務器上的冗餘數據,暫未删除
22 Squid 18G 1.5M 12K 隻緩存MediaWiki網站,不緩存Drupal網站
Apache 105G 6.9M 15K 大部分MediaWiki(約92G/2.8M=13K),小部分Drupal(約13G/0.25M=51K,還有更多頁面暫未生成靜态緩存文件)
MySQL 43G 9.8K 4.4M 有一個暫複制到23上使用
23 Squid 7.7G 0.47M 16K  
Apache 56G 2.8M 19K 目前全為MediaWiki網站
MySQL 12G 4.6K 2.6M 有一個暫從22複制過來使用

  從上面的統計來看,Squid和Apache下存在數以百萬、千萬記的緩存文件,在目前的硬盤下肯定難以對付随機性很大的訪問,需要用更好的專用磁盤來處理。

  上周就考慮過更換或者添加磁盤的事情,鑒于主闆不直接支持SCSI、SAS磁盤以及RAID陣列,就考慮用萬轉的SATA磁盤或者固态硬盤,萬轉SATA硬盤可選的不多,主要就是WD的迅猛龍(以前的猛禽升級版),固态硬盤雖然型号多、速度快,但容量小、價格高、壽命短,主要是發燒友放在個人機器中用,我們覺得暫時還不适合用在服務器上。

  今天已經在淘寶上訂貨,6塊WD3000HLFS(容量300G,2張單碟150G,緩存16M,傳輸120MB/s,讀取尋道4.2ms,寫入尋道4.7ms,平均無故障140萬小時),每塊430元,價格共2580元,準備在3台服務器中每台添加2塊這種每分鐘10000轉的硬盤,讓服務器的整體性能有個大的提高。以後如果還需要更多的硬盤還可以繼續添加。

  不過對于Squid、Apache和MySQL這3種服務如何放置在2塊新硬盤以及2塊以前的7200轉硬盤上,還沒有完全确定,初步的想法是:Squid、系統及備份、Apache、MySQL的數據各放置在一塊硬盤上,前面兩個放在7200轉上,後面兩個放在10000轉上,具體還需要與同事以及一些朋友交流後再定。看到這裡的網友如果有好的建議歡迎留言,謝謝!

回應

訪問最多的應該是MySQL文件,我們已經将MyISAM的key buffer加到到4G了,但肯定還是有一些需要訪問磁盤的。另外,上面寫的Squid, Apache下的小文件數量太多、占用空間也很大,我們16G的内存也難以滿足。後面除了增加高速硬盤外,也在想其他辦法,确實要設法避免io瓶頸。謝謝關注!

James Qi / 祁勁松

我們以前就是這樣做過,MySQL, Squid, Web都放置在不同的機器上,但其中任何一個環節出現問題或者瓶頸,也都影響最終的用戶訪問。後來改為根據不同的網站(我們有比較多的網站)進行分割,而某個網站的不同功能(MySQL, Squid, Web等)進行合并到一台配置好的服務器上。
在訪問量不大、數據量不大、功能不複雜的情況下,哪一種方式都可以,而出現密集訪問大數量網站的時候,就都會遇到瓶頸,正在設法通過硬件、軟件的辦法來解決。

James Qi / 祁勁松

我一直有關注您的博客。。我發現您的多數網站,都是以大量的數據來獲取流量,因此需要很好的服務器,以及解決其中的技術問題。如果不想被這些技術問題煩擾,倒是可以考慮不做那麼龐大的數據庫内容,轉而提供優質的内容,以較小的數據來獲取更多的流量。很多個人站長,他們的數據不過千條左右,都能獲取不錯的流量及收入。之前的留言我有提過的,如果您做英文産品的介紹和評論相關的網站,收入應該很客觀,做幾千個網頁就ok, 雖然你郵編庫的數據有幾十萬,但搜索的人少,不如做熱門産品搜索的人多。。

謝謝關注及留言。您說的那種方式與我現在的方式是兩種做法,就我個人而言比較喜歡做數量多、讓很多人來浏覽、同時也能有不錯收入的網站,我不太喜歡隻圍繞收入和産品來做網站。
各人的看法和選擇不同,都有自己的道理,呵呵。
我們以前也做過數量少而内容精的網站,也會遇到一些發展中的問題。現在是希望把網頁數量做龐大,而每個頁面也都把内容設法盡量展示得好一些,這個過程也有很多問題需要解決。
多多交流!

James Qi / 祁勁松

發表新回應

Plain text

  • 不允許使用 HTML 標籤。
  • 自動將網址與電子郵件地址轉變為連結。
  • 自動斷行和分段。