MySQL 的 Thread Pool (Percona 版本) 實測

MySQL Thread Pool 的介紹可以參考 Percona 的文章:,以及 DK 的介紹:MySQL 上的 Thread Pool…

一言以蔽之:資源使用量有減少,但看不出明顯的效能改善,可能是負載還不夠大。

MySQL Thread 數量(開啟 Thread Pool 前):

MySQL Thread 數量(開啟 Thread Pool 後):

System Thread 數量(開啟 Thread Pool 前):

System Thread 數量(開啟 Thread Pool 後):

可以看到在同樣約 2000 個 MySQL Thread 的情況下,開啟 Thread Pool 的 System Thread 數量只有約 200 個;開啟前約需要 3000 個 Thread。兩張圖是使用配備完全相同的兩台機器測試的。

Galera Cluster 的 gcache.size 設定

gcache.size 的大小會影響 Node 加入 Cluster 時,需不需要完整複製資料。如果資料更動程度過大,在 gcache 裡面已經找不到更動部份的話,就需要完整複製資料;反之則可以直接 apply gcache 裡面的變更。Understanding gcache in Galera 很詳細的說明了 gcache 的用途。

gcache.size 的預設值是 128MB。查了一下資料,是使用 MMAP 的方式來應用1,所以可以盡量設定大一些。雖然 mysqld 看起來會很肥,但實際上是吃不到那麼多記憶體的。我們是設定成 8G。

  1. http://www.percona.com/files/presentations/percona-live/nyc-2012/PLNY12-galera-cluster-best-practices.pdf []

利用 Percona Playback warm-up MySQL 資料庫…

Percona Playback 是一套可以將事先記錄下來的 SQL Query Log 在指定的 MySQL Server 上重作一次的工具,目前最新的版本是 0.5,支援讀取 slow query log 或是 tcpdump capture file。Percona 標榜可以完全按照 Query Log 的 Pattern (包含 thread concurrency,query 所花的時間等等)來重作一次 Query,不過測試的結果還是有點落差。

首先先在 Production 的 Server 上面紀錄 Query Log。因為 Percona Playback 0.5 的 Slow Query Reader 是爛的(bug 1035217),所以只能用 tcpdump:
tcpdump -w log.dump dst port 3306 and dst ip 192.168.1.1

記錄到足夠長度的 log 之後,把 log 放到要測試的 MySQL 機器上,開始執行 percona playback。要注意的是,所有的 Log (包含 UPDATE, DELETE, INSERT 等等會修改資料庫內容的 Query)都會被執行,如果要在 Slave 上跑的話,記得要事先濾掉,才不會造成 Master Slave 不同步的狀況。
percona-playback --input-plugin=tcpdump --tcpdump-filelog.dump --tcpdump-mode=fast --mysql-host=127.0.0.1 --mysql-username=root --mysql-schema=mydb

官方文件是使用 --tcpdump-mode=accurate,速度慢很多,使用 --tcpdump-mode=fast 會快不少。

Percona 的 MySQL Indexing: Best Practices

連結在這:http://www.percona.com/webinars/2012-08-15-mysql-indexing-best-practices

裡面除了介紹 MySQL Index 的種類與運作方式以外,也提到了「正確」的下 Index 的方法。由於 Index 會影響寫入的速度,並不是下愈多 Index 就越好的,而是應該視應用的 Performance critical query 的狀況來下適當的 Index。推薦會碰到 Database 的人(包含 netadmin 與 developer)都要去看看。

MySQL 5.1 GA

雖然說已經 Generally Available,PIXNET已經踩到好幾次地雷了……
除了 InnoDB 有用錯Index的情形,甚至還有吃到 signal 11就再起不能的事 Orz

如果你現在有空機器,可以試試看 MySQL 5.1 比 5.0 好的 Performance (尤其是 SMP)
而 5.1 的 MyISAM 的表現跟穩定性也不錯。
但是如果你用的是InnoDB,請以alpha的態度對待5.1.30 GA……

Mtron SSD…

最近事忙,忘了上來寫…

大約一個月之前,PIXNET 買的 Memoright 有一顆發生故障,硬碟直接從 OS 端消失,完全看不到了 XD
重開之後,BIOS也抓不到。懷疑是 SATA 連接線的問題,所以重新插了一次,就 OK 了,用到目前還沒有中地雷。
結果大概一週前, Mtron MSP-SATA70 32G 也掛了一顆 XD
Linux 抱怨寫入會有 Error,於是也重開機,重接線,結果運氣不好,還是會有 Error。現在這顆 SSD 已經飄洋過海回韓國檢查了…

MySQL on SSD 的測試之一

最近 PIXNET 測試了另外三款 SSD(Mtron 3000Mtron 1000MemoRight 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 來測試,如果有推薦的廠商也歡迎留言。

MySQL on Mtron 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 是被用到哪裡去了?