之前一直有遇到在 pf 裡面用 route-to 之後網路連線緩慢的問題(大概只有 10kb/s),不過一直沒時間去追。最近花了點時間去追這個問題,發現在使用 route-to 並且開啟 TSO 之後,重送以及 out-of-order 的 packet 變得異常多:
拿掉 TSO 或是 route-to 其中一個設定,狀況就會變好。在 core team 修正這個 bug 之前,只好先暫時 disable TSO 了。
Eric’s point of view and mumuring…
之前一直有遇到在 pf 裡面用 route-to 之後網路連線緩慢的問題(大概只有 10kb/s),不過一直沒時間去追。最近花了點時間去追這個問題,發現在使用 route-to 並且開啟 TSO 之後,重送以及 out-of-order 的 packet 變得異常多:
拿掉 TSO 或是 route-to 其中一個設定,狀況就會變好。在 core team 修正這個 bug 之前,只好先暫時 disable TSO 了。
必須的程式:mplayer、subtitleripper、transcode
首先先抓出該 DVD 內有幾個字幕軌道:
mplayer -dvd-device $RIPDIR dvd://$TITLE -vo null -ao null -frames 0 -v
$TITLE 是該影片位在 DVD 的哪個 Title 中。
輸出結果應該如下:
...... DVD successfully opened. audio stream: 0 format: ac3 (5.1) language: en aid: 128. audio stream: 1 format: ac3 (stereo) language: en aid: 132. number of audio channels on disk: 2. subtitle ( sid ): 0 language: en subtitle ( sid ): 1 language: es subtitle ( sid ): 2 language: pt subtitle ( sid ): 3 language: ko subtitle ( sid ): 4 language: zh subtitle ( sid ): 5 language: th subtitle ( sid ): 6 language: es subtitle ( sid ): 7 language: pt subtitle ( sid ): 8 language: ko number of subtitles on disk: 9 ......
再接下來抓出字幕:
tccat -i $RIPDIR -T $TITLE -L | tcextract -x ps1 -t vob -a 0x24 > subs-zh
註:0×24 為 0×20 + 4 (language:zh 的 index)
再接下來轉成 idx+sub:
subtitle2vobsub -o vobsubs-zh -i $RIPDIR/VIDEO_TS/VTS_01_0.IFO < subs-zh
就會生出 vobsubs-zh.idx 與 vobsubs-zh.sub 了。
中了個令人無言的地雷……
FreeBSD 有一個well-known的參數調整:mbuf clusters的最大值(kern.ipc.nmbclusters)。當使用的mbuf clusters超過設定的最大值時,網路就會不通。不過,我們可以在 /boot/loader.conf 裡面把 kern.ipc.nmbclusters 設為 0,表示不設定最大值,這樣他就會被Kernel Space Memory的大小限制住(一個 mbuf cluster 要吃約 2KB 的Kernel Memory)。
最近我們發現這樣設定的機器在有大量 TCP out-of-order 封包的網路環境下,網路效能表現非常差,於是做了很多交叉比對以及測試。最後發現有這樣問題的機器有兩個特點:netstat -s -p tcp 的結果,out-of-order packets 的 counter 都是 0,而且packets discarded due to memory problems 的 counter 很多。
最後找到 Maillist上的資料,發現在 kern.ipc.nmbclusters 設定為 0 的情況下,net.inet.tcp.reass.maxsegments 也跟著被設定成 0 了,調整回預設值 1600 就解決這個問題了。
今天因為某組Web機器當機實在當太嚴重了,因為我們發現問題是出在NFS,所以我們把 KDB 跟 DDB 編進去準備來找問題。
當發生問題的時候,由於機器不會當死,所以可以在Console按Ctrl-Alt-ESC進DDB。進了DDB以後,可以用textdump(4)來紀錄所下的指令以及其output。紀錄的資料會dump在dump device(通常是swap),等下次開機的時候會存到/var/crash裡面。
大概的作法是這樣:
如果發現出來的結果會被截掉的話,要把textdump的capture buffer加大:
sysctl debug.ddb.capture.bufsize=196608
把 FreeBSD 從 7.0-RELEASE 升級到 7.1-BETA2 以後,發現只有 Local Account 會去查該 Account 屬於 ldap 裡面的 group,而 LDAP Account 不會,只會查 Local Group 跟 Main Group(gidNumber 指定的 Group)。
找了半天,改了 nsswitch.conf 與 nss_ldap.conf,還是不會動,最後自暴自棄開始翻 Mailling list,結果看到這篇:[Working fix] Problems combining nss_ldap/pam_ldap with pam_mkhomedir in FreeBSD 7.0
Developers doesn’t like "soft".
當場囧在那邊。最後把 soft 改成 hard,這個問題就解決了….Orz
源於 OpenBSD,port 到 FreeBSD 的 pf 本身就可以作 load balancer,但是不能作 healthy check。要作 healthy check 的話,必須加上 relayd。另外用 CARP(4) 與 PFSYNC(4) 可以做到 Active-Standby 的 Redundancy HA,也就是當一台 SLB (Server Load Balancer) 死掉的時候,另一台會自動起來提供服務。詳細的作法在參考資料有,因此這裡不贅述。基本的想法為:
這樣就可以達到 Layer 4 Switch 的功能,在 relayd 裡面稱為 REDIRECT 模式,缺點是 pool 內所有的 server 都必須把 default gateway 設為 SLB。
另外 relayd 也可以採用類似 haproxy 的方式,由 relayd 跟 client 與 server 各建立一個連線,作 Layer 7 的 forwarding。這在 relayd 裡面稱為 RELAY 模式。
設定 relay 模式的時候,可以對 HTTP Header 作修改,例如加上 X-Forwarded-For Header,或是根據 Host Header 或者 URI 來決定要分配到的 Pool。另外 healthy check 也可以由管理者自行撰寫 script,因此可以作比較複雜的檢查。設定方式可以參考 RELAYD.CONF(5)。
比起 haproxy 來說,relayd 可以輕易的達到 Full Transparent Proxy (後端的 Server 看到的 source ip 是真正的 ip)的功能而不需要 patch kernel,而且也可以作 graceful restart( haproxy 在 restart 的時候服務會中斷);不過 haproxy 有許多的實例已經驗證過它的效能,可以吃滿 10Gbps 網路,但 relayd 在 RELAY 模式的 效能還是未知數。另外,由於 relayd 與 pf 綁的很緊,因此目前只有 OpenBSD 與 FreeBSD 版,不能在 Linux 上執行。
參考資料:
情形:有兩顆同樣大小的硬碟,想切出 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
這樣就完成了。
如果你把 TMPFS 跟 ZFS 一起用,要小心 ZFS 把 kmem 吃完導致 TMPFS 沒空間可用。
簡單的說,可以把 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 了。
當系統小的時候,用 mysqldump 在離峰時間把資料 dump 出來還算可行。
雖然 Table 會暫時 Lock 住,但是因為小,所以速度可以很快,鎖住的時間可以不計。
但當系統大的時候就不能這樣做了。
好在已經有許多處理這個問題的經驗者。
解決這個問題的 Key Point 是「減少鎖 Table 的時間」,因此如果採用的 File System 或是 Volume Manager 有支援快速的 snapshot 功能的話,整個問題就簡單很多。步驟如以下所示:
如果採用 LVM (Linux), ZFS (FreeBSD, Solaris) 或是 NetApp 的話,整個備份過程可以小於 5 秒鐘,因此可以做到每個小時備份一次而不影響正常使用。如果在 Slave 上做 snapshot 備份,則完全不會影響到寫入(READ LOCK時還是可以讀)。
Recent Comments