Eric’s point of view and mumuring…
我們把 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 功能的話，整個問題就簡單很多。步驟如以下所示：
如果採用 LVM (Linux), ZFS (FreeBSD, Solaris) 或是 NetApp 的話，整個備份過程可以小於 5 秒鐘，因此可以做到每個小時備份一次而不影響正常使用。如果在 Slave 上做 snapshot 備份，則完全不會影響到寫入（READ LOCK時還是可以讀）。
這次趁去墾丁的機會回了老家一趟，也因此搭了高捷。
世運站
高雄車站，高捷的地下車站都有月台門
中央公園站
其實感覺跟台北捷運差不多，不過車廂比較少，所以比較擠。
還有就是驗票閘門有點秀逗，三次裡面有兩次單程票沒辦法一次就順利回收，要重新再試第二次才能順利回收。
23:58 <@sunpoet> wens 是新的不能亂洗澡站長。 
23:58 <@sunpoet> 原來之前改錯地方，現在 screenrc 裡面可以用 -b/-g 指定該視窗要哪個 encoding 啦。
00:06 < NotExist> sunpoet: 你用哪版@@ 我man沒看到 囧rz
00:06 * NotExist 想那功能也很久….
00:10 <@sunpoet> NotExist: 自己 patch …
00:15 <@sunpoet> NotExist: http://sunpoet.net/mira/screen-big5-gbk
00:16 <@sunpoet> 像這樣連大神的站 screen -b -t abpe 2 env LANG=C LC_ALL=en_US.ISO8859-1 telnet abpe.org
00:20 < NotExist> sunpoet: XD 感謝
00:20 <@sunpoet> NotExist: 因為我懶惰 :p
00:21 < NotExist> sunpoet: 科技始終來自於惰性 :p
感謝 sunpoet，作個備忘。
這次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。
果然是一分錢一分貨，拷貝資料庫花的時間比起 SCSI 10k RPM RAID0 少了 2/3。採用與MySQL 在創見 SSD 上的測試同樣的設定，並真正上線灌真實流量進去後，觀察到 CPU Bound 了。
Latest Comments
RSS