Linux 上 MySQL Scalability 的問題

先前提到在 的問題,在 Update on the linux scaling situation. 提到了兩個 link:

在第一個 link 裡,在一台 4 CPU 的 PPC 64 有發現類似的現象:

中間 debug 的過程就不講了,最後發現是 malloc() 的問題,用 LD_PRELOAD 把 提供的 替換掉後就恢復了:

那個法鵝大站的站長,如果你覺得 太慢的話掛個 LD_PRELOAD 的 patch 上去... :p

FreeBSD 上跑 MySQL server 的效率問題

前幾天提到的 MySQL 在 FreeBSD 與 Linux 上的效率 有比較完整的 benchmark 以及資訊了,下面這張圖 (點進去後找大圖看比較清楚) 有 2.6.{18,19,20.1} 這三個版本的 testing,同時也確定是使用 5.0.33 (with MyISAM) 測試。

更完整的說明參考 Exciting new data from the sysbench comp 這篇。

MySQL 在 FreeBSD 與 Linux 上的效率

之前在 FreeBSD 的 ULE 2.0 提到要拿 測試 的 ULE 2.0,初步的測試結果出爐了:Benchmarking with sysbench.

綠色的是 FreeBSD 7-current CVS 版本,而紅色的是 Fedora Core 6 (沒有說明 kernel 版本),跑的是 MySQL 5.0.x (也沒有講真正的版本),所以這份數據... 先看過就好,要有詳細的測試環境資訊才能決定要不要催眠色 far 把 換掉...。(對 Fedora Core 比較熟的人可以說明一下 Fedora Core 6 的 default kernel 是 2.4 還是 2.6?)

Jim Gray 失蹤

1998 年因 Database & Transaction Processing 而獲得 James N. Gray 搭著小船在 San Francisco 外海失蹤,目前沒有收到求救呼叫,也找不到他的船隻:Jim Gray Is Missing

在台灣應該有不少人看過 Jim Gary (James Gary) 本人,因為去年 有邀請三位 得主 () 來台灣參加 『21世紀的運算』學術研討會,當時在圓山飯店舉辦。

FreeBSD 的 ULE 2.0

這陣子 在改寫 上的 SCHED_ULE,也就是

據他在 ULE cpu selection. 這篇的說法,在 8 core CPU 的 上跑 測試,ULE 2.0 比 4BSD 快了 300%。(不過據下面 comment 的數字,應該是快 200%,30k v.s. 10k)

然後他就想要弄個 出來測試,但他對於 的 tuning 不熟,所以就寫了一篇 Linux vs bsd database shootout! Sort of.,希望找到人幫他 tune,結果 魔頭之一 跳出來說他可以幫忙 的部份。

Anyway,很多人都很期待這次的 benchmark,畢竟 發展的重點是在多 CPU 環境 (尤其是 2 core 與 4 core),而非單 CPU 環境。

之前幫 far ( 站長,很糟糕的學弟 XD) 弄 search 功能的時候就聽到他在抱怨對 不熟,可是不得不在上面跑 ... 我想他應該頗高興的 :p

MySQL 裡的 Falcon

把 Falcon Storage Engine 放進 source tree 後 (MySQL Falcon Storage Engine Open Sourced),有人就在 上跑起來,同時對 MyISAM 與 InnoDB 做了一些簡單的 benchmark:InnoDB vs MyISAM vs Falcon benchmarks - part 1,跑出來的結果是 Falcon 大敗... :p

這陣子的測試都還說不準,要等到把一些整合上的問題修掉後再回來看。

PS:在 Falcon Storage Engine Design Review 這篇有些 Falcon 設計上的解釋,也許可以稍微解釋為甚麼 Falcon 跑起來這麼慢...

MySQL 將不會使用 GPLv3

決定將 MySQL 5.0 與 5.1 的版權宣告從 "GPLv2 或之後的版本" 改成 "GPLv2",換句話說,避免使用 GPLv3 授權:MySQL Changes License To Avoid GPLv3

這避免了如果有人拿 的 source code 改出另外一個版本後使用 GPLv3 所產生的問題:如果這個新的版本有很好的功能, 想要 porting 回 MySQL tree 裡時會產生 GPLv3 感染的問題。

MySQL 的使用

參加了在 總部辦的 ,他記錄了一些重點可以參考:MySQL Camp Google Notes

除了一般簡單的分散技巧外 (所謂的二十六台 密技?:p),另外還講了使用 master/slave 時應該要注意的問題,以及修改原始程式碼配合極短的 DNS TTL 達到很短的 downtime。

Slashdot 的 Comment 數超過 MEDIUMINT 的限制

上看到這則讓人 XD 的報導:Slashdot Posting Bug Infuriates Haggard Admins

的後端是 ,Comment 都放在同一個 Table 裡面。一開始他們用 MEDIUMINT (224) 來放 Comment ID,在五年前的時候他們改成 Unsigned Integer (232),但是忘了改 Index 的部分,於是昨天就出問題了...

裡把 Index 改好其實也很簡單,只是一個 ALTER 指令,但是在一千多萬筆資料的 Table 裡重建 Index 最少要三個小時,所以只好發一篇文章跟大家道歉,因為為了轉換會關掉一些功能... XD