最近事忙,忘了上來寫…
大約一個月之前,PIXNET 買的 Memoright 有一顆發生故障,硬碟直接從 OS 端消失,完全看不到了 XD
重開之後,BIOS也抓不到。懷疑是 SATA 連接線的問題,所以重新插了一次,就 OK 了,用到目前還沒有中地雷。
結果大概一週前, Mtron MSP-SATA70 32G 也掛了一顆 XD
Linux 抱怨寫入會有 Error,於是也重開機,重接線,結果運氣不好,還是會有 Error。現在這顆 SSD 已經飄洋過海回韓國檢查了…
最近事忙,忘了上來寫…
大約一個月之前,PIXNET 買的 Memoright 有一顆發生故障,硬碟直接從 OS 端消失,完全看不到了 XD
重開之後,BIOS也抓不到。懷疑是 SATA 連接線的問題,所以重新插了一次,就 OK 了,用到目前還沒有中地雷。
結果大概一週前, Mtron MSP-SATA70 32G 也掛了一顆 XD
Linux 抱怨寫入會有 Error,於是也重開機,重接線,結果運氣不好,還是會有 Error。現在這顆 SSD 已經飄洋過海回韓國檢查了…
情形:有兩顆同樣大小的硬碟,想切出 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
這樣就完成了。
今天就是 Firefox 3 的正式發表日期了,大家快去下載吧!
14:29 < @j> 原來 miss the boat 意思是”錯失良機”…
14:30 < @l> nice boat 就是 “大好機會”
14:30 < @g> XD
如果你把 TMPFS 跟 ZFS 一起用,要小心 ZFS 把 kmem 吃完導致 TMPFS 沒空間可用。
最近 PIXNET 測試了另外三款 SSD(Mtron 3000、Mtron 1000、MemoRight 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。
目前我們正在想辦法取得 STEC 與 Ritek 的 SSD 來測試,如果有推薦的廠商也歡迎留言。
簡單的說,可以把 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 了。
我們把 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 是被用到哪裡去了?
當系統小的時候,用 mysqldump 在離峰時間把資料 dump 出來還算可行。
雖然 Table 會暫時 Lock 住,但是因為小,所以速度可以很快,鎖住的時間可以不計。
但當系統大的時候就不能這樣做了。
好在已經有許多處理這個問題的經驗者。
解決這個問題的 Key Point 是「減少鎖 Table 的時間」,因此如果採用的 File System 或是 Volume Manager 有支援快速的 snapshot 功能的話,整個問題就簡單很多。步驟如以下所示:
如果採用 LVM (Linux), ZFS (FreeBSD, Solaris) 或是 NetApp 的話,整個備份過程可以小於 5 秒鐘,因此可以做到每個小時備份一次而不影響正常使用。如果在 Slave 上做 snapshot 備份,則完全不會影響到寫入(READ LOCK時還是可以讀)。