Cacheboy 1.5

把 Cacheboy 1.4 換成 1.5 後，CPU 使用率下降許多... 之前在 80~100 Mbps 的時候會達到 CPU bound，現在看起來要到 500Mbps 以上才會到 CPU bound。拿來跑小檔案的 cache 應該會相當好，不過這也等測過才知道...

不過，不論是 Squid 還是 Cacheboy，都沒有支援 deflate 與 gzip 壓縮，所以還是沒辦法拿來擋 CSS/JavaScript 的靜態檔案，這點還得再想辦法...

Bug Report

負責把外部的 bug report 轉成內部 ticket system report 果然是一件很累的事情，剛剛的兩個小時才殺了 150 個，精神就已經開始委靡了...

PHP require_once 效率問題

測試後終於有個好解法了，感謝 mailing list 上提出的建議...

重點在於 include_path 的設定，儘量在第一個 search directory 就找到要的檔案。我們的作法是設一個 class 的目錄，用 symbolic link 把所有的 class file 或是 class directory 放進去，接著用 Zend Framework 的 Zend_Loader::registerAutoload() 在 new 的時候自動讀入，最後把 Zend Framework 裡所有的 require_once 都拿掉。

這樣的速度比起原來 system 非常高的情況好很多。

利用 DRBD 生出 MySQL slave

簡單說明一下，這篇要說明的環境是：在 DRBD 上跑 MySQL，上面檔案系統是 XFS，資料庫全部都是 InnoDB，已經有設定好 server-id 並打開 binlog。現在想要把這台 MySQL 轉成 master，另外要想辦法從這台資料庫複製一份適當的資料跑 MySQL slave。

想法是先把 MySQL 的寫入動作擋住，然後把資料 sync 回 filesystem，這時候到備援機上 disconnect DRBD，再回到原來的 MySQL server 上開放寫入的動作。這時候備援機上的 DRBD 就是一份完整的 data。

詳細的指令大致上是這樣：

1. 先在 DRBD primary 上的 MySQL 上跑 FLUSH TABLE WITH READ LOCK;，然後跑 SHOW MASTER STATUS; 把 binlog position 記起來。
2. 在同一台機器上跑 sync; sync; sync 把 buffer 裡的東西都寫回硬碟。
3. 到 DRBD secondary 上跑 drbdadm disconnect [drbd_resource]，其中 [drbd_resource] 要記得換成你自己在用的 resource name。
4. 回到 DRBD primary 上直接 Ctrl-C，或是下 UNLOCK TABLES; 釋放鎖定。
5. 這時候到 DRBD secondary 上先把 monitor program 停掉，以免他亂來。
6. 接下來還是在 DRBD secondary 上，要「催眠」這台主機的 DRBD 是 primary：drbdadm primary [drbd_resource]。
7. 「催眠」完後跑 mount -o ro /dev/drbd0 /mnt，用 read-only 狀態掛到 /mnt。如果不小心掛成非 read-only 也沒關係，等下記得重新 resync 就可以了。
8. 把掛上來的 /mnt 整份資料複製出來，丟到預定要當 MySQL slave 的機器上。
9. 複製完成後 unmount /mnt，然後告訴 DRBD「其實你是 secondary」：drbdadm secondary [drbd_resource]。
10. 然後告訴 DRBD 需要重新 sync 檢查：drbdadm -- --discard-my-data connect [drbd_resource]。
    
11. 理論上這樣就完成了。接下來就是第一次如何設定 MySQL slave 的步驟，講 MySQL replication 的書籍應該都有說。

今天加了 MySQL slave 後應該是穩定不少，接下來再來想辦法解決頁面生成過慢的問題。

DRBD 與 MMM

換了 24GB 記憶體後機器當了四次，軟體方面，懷疑是不是 InnoDB 參數的問題，一開始設 18GB (75%)，剛剛改成 16GB (66%)，希望這樣就能解決...

如果不能解決，懷疑到硬體頭上就頭痛了，因為這樣就得再幹一組機器出來用。

另外以後確定了，資料庫一定要買有 IPMI 卡的，不然重開機這件事情得 call 機房處理 (上班時間還要補文件)，對我們與機房都不方便。

另外開始考慮 MMM 了，downtime 比 DRBD 少，承載量比 DRBD 大 (因為多一台可以當 slave)，再加上因為平常就有 slave，所以 warm up 時間一定會比 DRBD 短。

但這東西大約是去年春天才出來的，沒看到夠大的 site 在用... (這也是當初選 DRBD 的原因之一)

幫 mysql database 加記憶體

當初搞 HA 的好處之一，星期六早上六點半 (也就是現在) 可以在中斷服務 (<5mins) 的情況下，直接到機房加記憶體。

步驟很簡單，先 shutdown 備援機，加記憶體，上線後等備援機看起來沒問題後 shutdown 另外一台，再加記憶體。

這次加記憶體把其中一個 cluster 從 12GB 加到 24GB (大約全 PIXNET 2/5 的 user 的 Blog 資料在上面)，打算用這個方法先解決 mysql 的過載問題。

Update：好像還是太久，大約 10mins。

Pix_Db 與 Pix_ORM

整理一下，找機會 open source 出來。這兩個 class 都是 PHP5 的 class，儘量使用 PHP5 的語言特性以及 interface，讓使用的人更方便使用。

Pix_Db 主要的特性包括：

1. 以 JSON 檔為設定檔。(這點在考慮改寫)
2. 以 PDO MySQL 為底層，只打算支援 MySQL。
3. 比其他 Database Wrapper 方便的操作方式，像是 $dbh->query('DELETE FROM comment WHERE blogid = ?, articleid = ?', $id, $article);，而非 array($id, $article)！
   
4. 多台 Slave 時的 Round-Robin 以及 failover。
5. Master/Slave 架構時，如果判斷 SQL query 有寫入動作，使用 Master 連線。
6. 解決單一 handler 配合 transaction 互相干擾的問題。
7. 同樣帳號密碼的連線能夠重複使用。
8. 只有一個檔案。
9. 目前只有 293 行。
   

Pix_ORM 是一套 ORM framework，但與目前的 ORM framework 不同的地方在於：

1. 架構在 Pix_Db 上。
2. 不需要指定 columns，也不會到資料庫裡查 table metadata。
3. 僅需要指定 primary key。
4. 支援 has_one 與 has_many，目前沒打算支援 have_many (many-to-many)，因為可以用前兩者配合出來。
5. 可以自己寫 aliases 做到更特殊的效果。
6. 目前只有 510 行。

目前還在研究要用什麼 license，以及程序問題...

Mercurial 對應於 Subversion 的 svn:externals

答案是：沒有。至少官方 Wiki 上是寫 0.9.5 沒有這個功能。(現在已經 1.0.2 了)

我想要把 Hasname_Controller 對應到內部的 Mercurial Repository，想要用類似的功能，結果發現本功能並不存在：Externals。

雖然不是什麼大問題，不過用慣了 svn:externals，現在沒有這個東西總是覺得怪怪的。

Mercurial

commit mail 的部份主要是參考這篇：Setting up Mercurial to e-mail on changes，寫的還可以，自己多 try 幾次後就大概懂了。

終於把 Mercurial 的 commit mail 搞定了，不過這是內建的 commit mail hook。接下來要試著跑自訂的程式，這樣才能在 commit 後上 IRC 上叫叫叫...

Cacheboy 1.4

Cacheboy 的 CPU usage 比起 Squid 3 高出不少，即使都是大檔案，Cacheboy 的 CPU usage 限制只能到 120Mbps 就上不去，但 Squid 3 在 100Mbps 的時候還是只有 20% CPU usage...

不過如果是大量的小檔案造成 I/O bound 時就差很多了，看得出來 Cacheboy 的穩定性比 Squid 3 高很多，至少會慢慢把圖吐出來而不會破圖。

兩者適合用在不同的地方，放著跑，繼續測試...