星期日, 9月 21, 2008

Cacheboy 1.5

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

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

星期三, 9月 17, 2008

Bug Report

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

星期六, 9月 13, 2008

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 非常高的情況好很多。

星期二, 9月 09, 2008

利用 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 後應該是穩定不少,接下來再來想辦法解決頁面生成過慢的問題。

星期六, 9月 06, 2008

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。

星期三, 9月 03, 2008

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,現在沒有這個東西總是覺得怪怪的。

星期二, 9月 02, 2008

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 高很多,至少會慢慢把圖吐出來而不會破圖。

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

星期一, 9月 01, 2008

MySQL 與 DRBD

沒想到才 9/1 就遇上第一次 MySQL 當掉跳到另外一台的情況,而且還是最大的那個 cluster。也如同預期的有 warm up 的問題... (Cache 尚未全部讀入,速度比較慢,造成頁面生成時間過久而產生 500 或其他類似的症狀)

這個時間 (星期一下午) 的量,看起來要花十分鐘 warm up,這是最大的一台,其他台應該會更快。

Google SSO 的通知 (SAML implement)

前陣子 Google 寄信來說我們的 Google Apps SSO implement 有問題,需要修正送出的格式。照著信件裡的說明改完,過沒多久又寄信來通知說有問題,然後還透過台灣 Google 打電話到公司來。

花了一些時間比較 Google 提供的範例,結果看了老半天看不出來... 決定等 Google 停權的那一刻再來檢查。(因為這陣子實在是沒時間跟美國人慢慢耗)

通知信是寫 8/28 (美國的時區,我忘了是哪個),我記成 9/1,今天到公司要查正確的時間才發現早就過了,而且 Google Apps 的 SSO 登入看起來也都沒問題,省了下午要盯住的時間...