幹壞事是進步最大的原動力
本來是在 R60 上裝 Ubuntu 7.10，結果裝完後發現 8.04 已經到 RC stage 了，乾脆重裝成 8.04，等到正式 release 的時候升級到最新版。
裝完後什麼都不需要調整，就可以很順暢的使用 TouchPad、無線網路，而且 Function Key 也都正常運作。另外該有的軟體也都有了，像是 Firefox (居然是 3.0b5) 與 OpenOffice。
輸入法先換成 gcin，字型的部份把 FireflyTTF 以及文泉驛正黑 裝上後就差不多了。小紅點的 Scroll 功能的部份則是加了兩三行到 /etc/X11/xorg.conf 內。
把 Subversion、SVK、Git 都裝好後，即使想在沒有網路的地方開發軟體仍然很方便。
應該會跑一陣子看看有什麼不足的，桌機先維持 Windows XP… XD
Update：相關的設定可以參考 racklin 寫的「安裝 Ubuntu 8.04 於 Thinkpad T61 雜記」
在 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 的事情，還是得累積經驗…
如果有想到其他值得提的事情再寫好了…
最近進了四顆創見 SSD MLC 顆粒 32GB 硬碟 (連結應該沒錯) 跑 RAID 1+0，就讓 jnlin 在 Debian 上跑 MySQL 5.1 測試 MyISAM 的效率，測試的結果相當慘，寫入的速度在個位數 qps (對… <10 query per second)，而且不是模擬資料，是 Real Data 的 Replication Update…
測過的 Filesystem 包括 ext3 與 XFS，block size 也調整過好幾次，RAID 1+0 的部份是軟體做，這部份的 block size 也調整過，不過不管怎麼測，速度都還是上不去。
在 Mtron SSD 硬碟還沒有開始在台灣代理之前，用一堆 RAM 加上 15K RPM SCSI 硬碟做 RAID 1+0 比較便宜，而且也比較穩定…
Update：我要求 jnlin 將測試的想法丟到網頁上，現在可以在他的 blog 上看到了：「MySQL 在創見 SSD 上的測試」。
測試的結論是，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 執行壓縮程式…
RFC 1323，也就是 TCP window scaling，通常事由 kernel 底層處理的，這次 Amazon 宣佈支援 RFC 1323 應該是系統升級的關係：Increasing Amazon S3 Data Transfer Performance…
翻了一些文件，看起來是 Linux 2.4 的舊版 (而且是很舊的版本？) 換到 2.6 時順便帶來的效益？
最近要衝一個註冊頁面，某位不能吃牛肉的老闆叫我就直接衝 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"
這樣就可以了。