幹壞事是進步最大的原動力
在 Jeff Roberson (也就是目前 FreeBSD 上 SCHED_ULE 的維護者) 的 blog 上說了這樣的話：(原文章連結)
MyISAM performance is terrible in FreeBSD 7.0 due to the user-space pthread_rwlock implementation. Just a word of warning if you intend to deploy a database server based on 7.0. I am certain we will have this fixed in 7.1. It will most likely be in CURRENT in a week or two.
所以不是我在「FreeBSD 上的 MySQL 效率」這裡想的 Filesystem I/O 問題？來等 Jeff Roberson 的 patch 吧…
最近很少寫 Blog (程式沒寫幾行，倒是一堆行政上面的事情)，不過 Twitter 上倒是常常念。
最近忙一些事情，像是寫不完的採購簽呈 (還好有一部分交給 slzzp 了)，然後是開不完的會，如果要抽時間寫程式的話，就得在一般人下班後才有空了…
不管怎麼樣，最近看 jnlin 玩，以及我自己玩一些東西，有些有趣的想法，寫下來紀錄起來。
FreeBSD 7.0 的 SCHED_ULE 長期觀察下來 (超過兩個月) 算是相當穩定，這點在目前 PIXNET 的 Web Server 端可以看出來 (在 FreeBSD 跑 apache22 event 是使用 threading，配合 FastCGI 跑 PHP)，但 gjournal 與 ZFS 在效率以及穩定度上都還不堪使用。(指 heavy I/O)
MyISAM 的讀取速度非常快，但不利於大量 Update (因為寫入的動作需要 table lock)。在國外的討論裡，一般都是推薦使用 InnoDB 解決這類 table 的情況，但實際上目前 InnoDB 的備份問題比起 MyISAM 麻煩 (經驗也是一個大問題)，這點可能還要再考慮。
要解決 table lock 的問題，另外一種方式是透過拆 table，而且目前看起來拆 table 撐 performance 的方式似乎相當可行 (在概念上，這是一種 HyperDB 的變形)，所以最近應該會對這個方向大量研究。不過就得做不少 Denormalize 的事情，還是得累積經驗…
如果有想到其他值得提的事情再寫好了…
測試的結論是，FreeBSD 現在缺乏穩定而且高效率的 Filesystem 讓 MySQL MyISAM 使用。
先解釋一下現在的環境，有兩台 Tyan Server，上面都是 Dual Quad Core 與 12GB RAM (6*2GB)，接兩顆 73GB SCSI 硬碟，兩台的差異在於 CPU，新進的這台是 E5410 (2333Mhz，2*6144KB L2)，舊的是 E5320 (1866Mhz，2*4096KB L2)。
舊的是目前 PIXNET production 的 MySQL database，跑 Debian/amd64，kernel 是 2.6.22，檔案系統是 XFS。另外一台則是前陣子另外進的，裝了 FreeBSD/amd64 7.0-BETA2，然後透過 make kernel & make world 升級到 7.0-PRERELEASE，跑 SCHED_ULE，檔案系統是 UFS2。依照慣例，noatime 與 nodiratime 之類的參數都會設上去，兩台都是跑 MySQL 5.1.22-rc，都是 MySQL slave。
要複製 slave 很簡單，把 production 停機 (利用使用者比較少的時候，其他的 slave 會負責這台本來的事情)，整個目錄複製一份到新的 FreeBSD 上，改 server_id 後跑起來後 MySQL 會跟 master 更新。
然後用 databases/mytop 看 replication delay 的情況 (原版的 mytop 沒有這個訊息，這是 FreeBSD ports patch 的功能)，發現即使是放著跑 replication sync，某些時候 UPDATE 的速度反而會跟不上 master，跟不上時的 I/O 是滿載的 (透過 gstat 看的)
目前測過最好的情況是這樣跑：gstripe -s 16384 將 da{0,1} 串起來，用 async + noatime。其他的情況包括：
以效率來看，短期內還是會跑 Debian/amd64 養 MySQL…
另外補充一點，本來是在開啟 gjournal 的情況下用 rsync 把資料複製到本機，結果發生 kernel panic，後來是先複製完再使用 gjournal，這個部份還要到其他機器看看到底是怎麼一回事…
FreeBSD 7.0 看起來會在二月放出，似乎會有很多人想要上 ZFS 測試，不過我們自己拿 FreeBSD ZFS 在 RAID 上的穩定度其實還不太夠，另外效率上也不太讓人滿意…
有台 12 顆硬碟的機器，上面是跑 amd64 1GB 記憶體 (目前應該是 4GB 了，下面測試時是 1GB)，ZFS 的架構是前六顆硬碟跑一組 RAIDZ1，後六顆也跑一組。常常跑到 out of kernel memory，加到 4GB 後還是一樣，要改動開機參數，換句話說這部份還沒有寫的很傻瓜… 效率上，在刻意關掉 atime 以 “FTP” 測試 Random Read 的速度卡在 I/O，非常慘的數字：10MBytes/sec。
另外最近剛好看到 Joyent’s weblog 上提到他們在 ZFS 踩到大地雷：Bingodisk and Strongspace: What Happened?。(不過他們跑的好像是 OpenSolaris)
我個人覺得，目前拿 ZFS 跑 RAID 的 Code Quality 還要再加強，不過對於一般個人用，拿來打 snapshot 應該是沒什麼問題，我們在 Pixnet 是拿 ZFS 放 log，因為可以開 filesystem gzip，這樣就不用每天跑 cron 執行壓縮程式…
最近要衝一個註冊頁面，某位不能吃牛肉的老闆叫我就直接衝 RoR 了，不過公司已經有人研究 RoR，而且我跟 Ruby 不熟的情況下，我決定去用以 Python 開發的 django。
django 的文件也不少，不過我第一份當然是先看 ericsk 最近寫的 用 Python + django 10分鐘內作出一個 blog，但是我照著這份文件做發現一直有問題，後來發現到：FreeBSD ports 的 www/py-django 是 0.96.1，這個版本叫做 maxlength，而在之後的版本才是 max_length。
這個問題在官方的 ticket system 裡有提到，如果有興趣看的人可以直接看裡面的討論：maxlength should be max_length。
PS：剛剛又中了一個地雷，已經不想 Google 找答案了，決定先裝 www/py-django-devel 試看看。
寫這篇是要補 Enable core dump in Linux and FreeBSD 這篇沒提到的部份。
對於 setuid 或是 setgid 程式，FreeBSD 基於安全性原因是不會產生 core 的。如果有需要產生 core 需要修改 kern.sugid_coredump 的值：
# sysctl kern.sugid_coredump=1
這個在 Varnish 的 mailing list 上遇過，無意間看到這個參數才發現的：Varnish crash (SIGABRT) about every 10 mins。
辦公室裡面的 NAT Server 是一台 FreeBSD，用 ipnat 包這塊，不過一直沒有設定 UPnP，昨天想到的時候想起 Leeym 應該有寫過 UPnP 的文章，可是卻找不到…
結果找了其他軟體發現 miniupnpd 也很簡單，在 FreeBSD Ports 裡也已經存在了，於是就裝起來測試，發現沒什麼問題… (賀)
基本上只要啟動 PF，設定好 minipnpd.conf 後，在 /etc/pf.conf 加上：
rdr-anchor "miniupnpd" anchor "miniupnpd"
這樣就可以了。
這兩篇差了一年：
在大光頭投影片裡的 Slide 36：
It’s good to be back.
前幾天發現 3gp 已經被包成 shared library，叫做 AMR Codecs as Shared Libraries，而且 ffmpeg 也已經靠這個 library 處理 3gp 了，不用像以前那樣自己去抓 zip 下來解開搞老半天。
不過因為我對 FreeBSD ports 裡的 multimedia/ffmpeg 已經絕望了 (結構太亂改不動)，所以我乾脆自己弄個 ports 出來包，四個檔案 (Makefile、distinfo、pkg-descr、pkg-plist) 我就直接丟到 wiki 上了：ffmpeg。
這一包裡面儘量把能包的都包進來了，除了 rmvb 以外，要轉檔應該沒什麼問題，有興趣的人可以自己整合回自己的 ports 架構裡。
MySQL 在 NetBSD 上的效率 這篇提到的效率差別已經確認是 FreeBSD 7-CURRENT 的 malloc() debugging code 所造成，拿掉以後就接近了：Re: Thread benchmarks - FreeBSD corrections。
這兩張圖分別是 FreeBSD/NetBSD 的 SCHED_4BSD 與 SCHED_ULE/SCHED_MSVR 效率差異：
