雖然說已經 Generally Available，PIXNET已經踩到好幾次地雷了……
除了 InnoDB 有用錯Index的情形，甚至還有吃到 signal 11就再起不能的事 Orz
如果你現在有空機器，可以試試看 MySQL 5.1 比 5.0 好的 Performance (尤其是 SMP)
而 5.1 的 MyISAM 的表現跟穩定性也不錯。
但是如果你用的是InnoDB，請以alpha的態度對待5.1.30 GA……
Archive for the 'MySQL' Category
最近事忙，忘了上來寫…
大約一個月之前，PIXNET 買的 Memoright 有一顆發生故障，硬碟直接從 OS 端消失，完全看不到了 XD
重開之後，BIOS也抓不到。懷疑是 SATA 連接線的問題，所以重新插了一次，就 OK 了，用到目前還沒有中地雷。
結果大概一週前， Mtron MSP-SATA70 32G 也掛了一顆 XD
Linux 抱怨寫入會有 Error，於是也重開機，重接線，結果運氣不好，還是會有 Error。現在這顆 SSD 已經飄洋過海回韓國檢查了…
最近 PIXNET 測試了另外三款 SSD（Mtron 3000、Mtron 1000、MemoRight MR25.2-032）跑 MySQL 的效能，並且跟 Mtron 7000 系列做了比較。之前測試的 Mtron 7000 系列資料可以在這裡與這裡找到。
以下的測試環境，除了 Mtron 1000 系列是使用 Intel E5410 的 CPU 以外，其他的環境都是 8-way E5450 CPU、12G RAM 的 Debian Linux，跑 MySQL 5.1 Slave，用 MyISAM 當 backend。最大的 MyISAM Table 大概有 3GB。
- Mtron 3000 系列：實際使用的時候，感覺的出來上跟 Mtron 7000 系列有差。在測試環境中，對讀取來說，到 CPU Bound 的時候，IO 大概使用了 70%。平均 MySQL 的 QPS (Query Per Second)約 5000~6000。對大量的寫入（同時也有讀取）來說，即使沒到 CPU Bound（大概 在 3000 qps），IO 會滿載。
- Mtron 1000 系列：需要 slow start。使用上的感覺跟 SCSI 15krpm 兩顆硬碟作成的 RAID 0 差不多，讀取比 SCSI 硬碟快，但是寫入比較慢。在測試環境中，到 IO Bound 的時候大約可以達到 4000 qps。
- MemoRight MR25.2-032：在測試環境中，到 CPU bound 時，IO usage 約 45%，平均 QPS 大約 6000 上下。iostat 裡面顯示的 iowait% 比較高，大約是 6%，而 Mtron 大概 1%。同時有讀取與寫入的時候，Memoright 的讀取比 Mtron 差。當 Mtron 7000 跟 3000 的 IO Usage 是 10 % 的時候，Memoright 的 IO usage 大概 35%。遇到對大量的寫入（同時也有讀取）來說，
Memoright 的 IO usage 大概 90%，Mtron 3000 大概 100 %，Mtron 7000 大概 50%。
目前我們正在想辦法取得 STEC 與 Ritek 的 SSD 來測試，如果有推薦的廠商也歡迎留言。
我們把 E5410 換成 E5450 再做了一次測試，發現這次還是卡在 CPU Bound，但是比起 E5410 來說有效能上的改進（同樣是實際上線，E5410 的 qps 極限是 8000，平均是 4000 左右；E5450 極限也是 8000，但是平均可以到 5000）。接著我們調整了 thread_concurrency 與 thread_cache_size 之後，平均 qps 可以到 6000。
另外，這次發現大概有 40% 的 CPU Time 被 system 吃掉了。有沒有對 Linux 比較熟的長輩可以教一下怎麼看這些 CPU 是被用到哪裡去了？
當系統小的時候，用 mysqldump 在離峰時間把資料 dump 出來還算可行。
雖然 Table 會暫時 Lock 住，但是因為小，所以速度可以很快，鎖住的時間可以不計。
但當系統大的時候就不能這樣做了。
好在已經有許多處理這個問題的經驗者。
解決這個問題的 Key Point 是「減少鎖 Table 的時間」，因此如果採用的 File System 或是 Volume Manager 有支援快速的 snapshot 功能的話，整個問題就簡單很多。步驟如以下所示：
- SLAVE STOP;
- FLUSH TABLE WITH READ LOCK;
- 作 snapshot
- UNLOCK TABLES;
- SLAVE START;
如果採用 LVM (Linux), ZFS (FreeBSD, Solaris) 或是 NetApp 的話，整個備份過程可以小於 5 秒鐘，因此可以做到每個小時備份一次而不影響正常使用。如果在 Slave 上做 snapshot 備份，則完全不會影響到寫入（READ LOCK時還是可以讀）。
這次PIXNET進了2顆 32G Mtron MSP-SATA70（Spec 上寫的寫入速度為 90MB/s，讀取速度為 120MB/s），裝在 8-way、12G RAM 的 Debian Linux 上，跑 MySQL 5.1 Slave，用 MyISAM 當 backend。最大的 MyISAM Table 大概有 3GB。
這次一開始就採用 RAID 0, 4KB stripe size + XFS (4 KB Data Size) + noop disk scheduler。測試開始時，從DB Master複製資料所需的時間，大概是兩顆 SCSI 10k RPM + XFS 的 1/3，約 70MB/s。接著 replication qps 大概在 3000-4000 左右徘徊，最高大約是 15000 qps。
實際使用上（同時有 SELECT 與 UPDATE），大概 8000 qps 是極限，接著就會遇到 CPU Bound，對於較複雜的 SQL Query （SELECT … IF EXISTS）會開始卡。如果只計算單純的 SELECT QUERY，則可以到約 15000 qps。
看了 Kevin Burton 的文章 , PIXNET 決定找目前市場上買的到的 SSD 來測試跑 MySQL，後來是進了4顆 創見32GB MLC SSD，裝在 8-way、12G RAM 的 Debian Linux 上，跑 MySQL 5.1 Slave，用 MyISAM 當 backend。最大的 MyISAM Table 大概有 3GB。
一開始我們用 64KB stripe size 跑 RAID0，但是就如 DK 說的慘不忍睹，用 XFS 每秒的 replication qps 大概在 5~20 上下徘徊，改用 EXT3 也沒有長進，關掉 disk scheduler 也沒用，於是我們試著改 stripe size 到 4KB，不過也沒有顯著增加，對單一大 Table 的 qps 還是只有 5~20，不過若是對小一點的 Table 倒是可以到 300 左右。後來我們想繼續降低 stripe size，但發現不管是 LVM 還是 md(4) 都只支援最低 4KB。
最後發現，這顆創見 SSD 只支援到 UDMA Mode 4，而且規格裡面寫 random write 只有大概 1.6MB/s，但是平常我們的 replication write 就大概要 3MB/s，peak 到 11MB/s（XFS），而創見 SLC 的 SSD 大概也只支援到 4MB/s，還是太慢。
結論：台灣市場上目前的 SSD 效能還不夠好，而國外的 Mtron 還太貴，C/P值不夠好，兩顆 32G 就可以多加一台機器了。
Recent Comments