在一顆硬碟上同時作 gmirror 與 ZFS

情形:有兩顆同樣大小的硬碟,想切出 10G 當 / 並作 gmirror,其他作 ZFS。

作法:先灌好 FreeBSD,把硬碟切成同一個 partition,例如說 ad0s1。 / 放在 ad0s1a,swap 放在 ad0s1b,ZFS 放在 ad0s1d。假設另一顆硬碟是 ad1,也同樣切成 a,b,d 三個與 ad0 slice 大小相同的 slice。

# gmirror load
# gmirror label -v -h -b round-robin gm0s1a ad1s1a
# newfs -U -O2 /dev/mirror/gm0s1a
# mount -o noatime /dev/mirror/gm0s1a /mnt
# echo ‘geom_mirror_load="YES"’ >> /boot/loader.conf
# vi /etc/fstab

把 /dev/ad0s1a 都改成 /dev/mirror/gm0s1a

# cd /
# tar -c –one-file-system -f – . | tar xpf – -C /mnt/

重開後,再把 ad0s1a insert 回去:

# gmirror insert gm0s1a ad0s1a
# gmirror rebuild gm0s1a ad0s1a

接著建立 ZFS:

# zpool create tank ad0s1d ad1s1d

這樣就完成了。

MySQL on SSD 的測試之一

最近 PIXNET 測試了另外三款 SSD(Mtron 3000Mtron 1000MemoRight MR25.2-032)跑 MySQL 的效能,並且跟 Mtron 7000 系列做了比較。之前測試的 Mtron 7000 系列資料可以在這裡這裡找到。

以下的測試環境,除了 Mtron 1000 系列是使用 Intel E5410 的 CPU 以外,其他的環境都是 8-way E5450 CPU、12G RAM 的 Debian Linux,跑 MySQL 5.1 Slave,用 MyISAM 當 backend。最大的 MyISAM Table 大概有 3GB。

  • Mtron 3000 系列:實際使用的時候,感覺的出來上跟 Mtron 7000 系列有差。在測試環境中,對讀取來說,到 CPU Bound 的時候,IO 大概使用了 70%。平均 MySQL 的 QPS (Query Per Second)約 5000~6000。對大量的寫入(同時也有讀取)來說,即使沒到 CPU Bound(大概 在 3000 qps),IO 會滿載。
  • Mtron 1000 系列:需要 slow start。使用上的感覺跟 SCSI 15krpm 兩顆硬碟作成的 RAID 0 差不多,讀取比 SCSI 硬碟快,但是寫入比較慢。在測試環境中,到 IO Bound 的時候大約可以達到 4000 qps。
  • MemoRight MR25.2-032:在測試環境中,到 CPU bound 時,IO usage 約 45%,平均 QPS 大約 6000 上下。iostat 裡面顯示的 iowait% 比較高,大約是 6%,而 Mtron 大概 1%。同時有讀取與寫入的時候,Memoright 的讀取比 Mtron 差。當 Mtron 7000 跟 3000 的 IO Usage 是 10 % 的時候,Memoright 的 IO usage 大概 35%。遇到對大量的寫入(同時也有讀取)來說,
    Memoright 的 IO usage 大概 90%,Mtron 3000 大概 100 %,Mtron 7000 大概 50%。

目前我們正在想辦法取得 STEC 與 Ritek 的 SSD 來測試,如果有推薦的廠商也歡迎留言。

FreeBSD: 用 ZFS 的 volume 當作 iSCSI Target

簡單的說,可以把 iscsi-target 的 extent 設成 ZFS 的 volume 就可以了…
不過我不知道如果 extent 的大小設超過 iscsi-target 會發生什麼事。

# zfs create -V 10g tank/iscsi
# cd /usr/ports/net/iscsi-target/ ; make install clean
# cat > /usr/local/etc/iscsi/targets
extent0         /dev/zvol/tank/iscsi     0       10GB
target0         rw      extent0         10.0.0.0/24
^D
# /usr/local/etc/rc.d/iscsi_target forcestart

這樣就可以用別的 iSCSI initiator 來連接 iSCSI Target 了。

MySQL on Mtron SSD 之二

我們把 E5410 換成 E5450 再做了一次測試,發現這次還是卡在 CPU Bound,但是比起 E5410 來說有效能上的改進(同樣是實際上線,E5410 的 qps 極限是 8000,平均是 4000 左右;E5450 極限也是 8000,但是平均可以到 5000)。接著我們調整了 thread_concurrency 與 thread_cache_size 之後,平均 qps 可以到 6000。

另外,這次發現大概有 40% 的 CPU Time 被 system 吃掉了。有沒有對 Linux 比較熟的長輩可以教一下怎麼看這些 CPU 是被用到哪裡去了?

加班

下午發生了緊急事件,於是就跟老闆還有老闆的老闆還有大神三個人衝到內湖機房,搞到早上五點天都亮了才結束…OTL
其實之前也有在機房加班到凌晨三四點啦,不過這次原因更囧了。haproxy萬歲啊!

另外也因為這次的事件,有幸拜會了B站的老闆,還有傳說中的第N代的BBS。B站的老闆說第一代BBS現在被供奉在公司的辦公桌旁,比起被當成皮球的某「有站」的BBS來說,還真是好命啊…

MySQL (MyISAM) 的備份

當系統小的時候,用 mysqldump 在離峰時間把資料 dump 出來還算可行。
雖然 Table 會暫時 Lock 住,但是因為小,所以速度可以很快,鎖住的時間可以不計。
但當系統大的時候就不能這樣做了。

好在已經有許多處理這個問題的經驗者。
解決這個問題的 Key Point 是「減少鎖 Table 的時間」,因此如果採用的 File System 或是 Volume Manager 有支援快速的 snapshot 功能的話,整個問題就簡單很多。步驟如以下所示:

  1. SLAVE STOP;
  2. FLUSH TABLE WITH READ LOCK;
  3. 作 snapshot
  4. UNLOCK TABLES;
  5. SLAVE START;

如果採用 LVM (Linux), ZFS (FreeBSD, Solaris) 或是 NetApp 的話,整個備份過程可以小於 5 秒鐘,因此可以做到每個小時備份一次而不影響正常使用。如果在 Slave 上做 snapshot 備份,則完全不會影響到寫入(READ LOCK時還是可以讀)。

高捷遊記

這次趁去墾丁的機會回了老家一趟,也因此搭了高捷。

IMG_1878
世運站

IMG_1879
高雄車站,高捷的地下車站都有月台門

IMG_1884
中央公園站

其實感覺跟台北捷運差不多,不過車廂比較少,所以比較擠。
還有就是驗票閘門有點秀逗,三次裡面有兩次單程票沒辦法一次就順利回收,要重新再試第二次才能順利回收。