Gea-Suan Lin's BLOG for Work
Gea-Suan Lin's BLOG for Work
星期三, 1月 16, 2013
星期一, 12月 31, 2012
FreeBSD 與 Linux 下強制重開...
現在人居然在辦公室... (苦哈哈)
遇到 process 用 kill -9 砍不掉時,不能用 reboot 重開,這會導致 reboot 卡死。如果機器很遠的話就很苦了...
苦啊苦啊苦啊...
星期六, 12月 22, 2012
星期日, 12月 16, 2012
FreeBSD 下 lagg 在 /etc/rc.conf 的設定方式
如果在 FreeBSD 的 /etc/rc.conf 裡想要搞定 Link Aggregation (lagg) 的設定,主要是這幾條:
cloned_interfaces="lagg0"
ifconfig_igb0="up"
ifconfig_igb1="up"
ifconfig_lagg0="laggproto failover laggport igb0 laggport igb1 123.45.67.89/24"
如果要跑其他模式 (像是 LACP) 的話就把 failover 改成其他的選項就可以了...
星期日, 11月 25, 2012
用 tpcc-mysql 測試 LSI 的 Nytro MegaRAID NMR 8100-4i
先說結論,這是張不錯的 RAID + Flash 加速卡。
十一月初的時候合作的 SI 廠商丟信件來,問我們對 LSI 的 Nytro MegaRAID Application Acceleration Card 有沒有興趣。架構上就是本來的 RAID 卡加上 Flash Cache,原廠說可以快 10 倍。
我的慣例是先問價錢,價錢在可能的範圍才會測試。所以就請廠商提供價錢:(因為是建議售價,這邊就直接貼出來了)
8100-4i 100GB/s SSD 建議售價NT$62,900
8110-4i 200GB/s SSD 建議售價NT$93,900
8120-4i 800GB/s SSD 建議售價NT$239,000
硬體設備是 Intel Xeon E5620*2 + 8GB RAM,用 8100-4i 接四顆 Seagate SAS 15KRPM 300GB 硬碟跑 RAID1+0。Flash 部分是兩顆 50GB SLC Flash,跑 RAID1 後掛到本來的 RAID1+0 加速。
首先是 W=100,測試資料 10GB 的情況:
- 有 Cache:
- 16 threads:5443.300 TpmC
- 32 threads:16247.400 TpmC
- 64 threads:21203.900 TpmC
- 128 threads:23206.100 TpmC
- 256 threads:20845.500 TpmC
- 沒有 Cache:
- 16 threads:1080.500 TpmC
- 32 threads:1434.100 TpmC
- 128 threads:1304.800 TpmC
再來是測 W=1000,測試資料 86GB 的情況:
- 有 Cache:
- 64 threads:800.367 TpmC
- 128 threads:1270.367 TpmC
- 256 threads:1053.467 TpmC
- 沒有 Cache:
- 64 threads:443.567 TpmC
- 128 threads:348.133 TpmC
- 256 threads 在最後 Stop threading 的地方一直跑不完,重跑三次都一樣。
第一個測的是資料量超過 RAM,但還沒超過 Flash 大小。第二個測的是資料量超過 Flash 大小的情況。
可以看出來當超過 RAM 時增加的效能很不錯。
星期五, 11月 23, 2012
用 tpcc-mysql 測試 MySQL InnoDB 效能
因為跟廠商借了張 NMR8100-4i 要測試效能,而這張有兩個 50GB 的 SLC NAND Flash,想要跑看看如果拿來給 database 用的效能如何。
TPC-C 是用來模擬線上交易服務所產生的資料庫 query 藉以測試效能 (另外還有 TPC-E 與 TPC-H 是測試不同面向)。而 tpcc-mysql 則是 Percona 維護的 open source 專案,專門拿來測試 MySQL 的效能,面向則是跟 TPC-C 接近。
所以就決定拿 tpcc-mysql 來當測試工具 (因為 Percona 的關係)。
建議第一次玩的人可以在 AWS EC2 上開一台 Ubuntu server 玩看看,反正爛掉可以重來,不用太擔心要還原...
首先先安裝 bzr 與 build-essential 以及 libmysqlclient-dev,然後將 source code checkout 下來:
TPC-C 是用來模擬線上交易服務所產生的資料庫 query 藉以測試效能 (另外還有 TPC-E 與 TPC-H 是測試不同面向)。而 tpcc-mysql 則是 Percona 維護的 open source 專案,專門拿來測試 MySQL 的效能,面向則是跟 TPC-C 接近。
所以就決定拿 tpcc-mysql 來當測試工具 (因為 Percona 的關係)。
建議第一次玩的人可以在 AWS EC2 上開一台 Ubuntu server 玩看看,反正爛掉可以重來,不用太擔心要還原...
首先先安裝 bzr 與 build-essential 以及 libmysqlclient-dev,然後將 source code checkout 下來:
# apt-get install bzr build-essential libmysqlclient-dev# cd /tmp# bzr branch lp:~percona-dev/perconatools/tpcc-mysqlcheckout 後要先上這個 bug report 裡面提供的 patch,雖然標題是 9.04 64bits,但在 12.04 64bits 下還是沒修正:「tpcc_start core dump on Ubuntu 9.04 64bit」。
修正完成後直接編就可以了:
# cd src# make
接下來的東西可以看 README 裡的說明。
首先先建立 database (我取 tpcc1000),然後再把 create_table.sql 與 add_fkey_idx.sql 倒進去。
然後用 tpcc_load 產生資料塞進資料庫:
# ./tpcc_load 127.0.0.1:3306 tpcc1000 root rootpassword 1000
上面這是單一 process 在塞,可以考慮用 load.sh 同步塞 (速度快很多,不過 script 寫死用 root 塞,密碼是空的,你可以自己改裡面的內容):
# ./load.sh tpcc1000 1000
我自己測試發現 W=100 約 10GB 資料,W=1000 約 86GB 資料。測試的時候要注意有沒有超過 memory size。通常是 fit memory 測一次,over memory 再測一次。我的例子是測 fit flash size 一次,over flash size 一次。
第一次倒測試資料進去的時候,我通常會先調整 my.cnf,讓他不要每次 flush to disk,這樣寫入速度會快很多。
雖然說快很多,W=1000 的情況下我也跑了八個小時 I/O bound 才產生出 86GB 資料。
倒完資料後要把 my.cnf 改成要測試的設定,然後重跑 mysqld,接著跑 tpcc_start 實際測試:
# ./tpcc_start -h127.0.0.1 -P3306 -dtpcc1000 -uroot -prootpassword -w1000 -c32 -r 60 -l3600
上面的 -c 是 thread 數量,-r 是 warmup 時間,-l 則是測試的時間。這個例子裡會 warmup 60 秒,再加上 3600 秒的測試 (一小時)。
最後他會給你 TpmC 數字,這數字愈大表示效能愈好。
大致上就是這樣,話說回來,NMR8100-4i 這張卡帶來的效能不錯耶...
星期三, 10月 31, 2012
一個晚上,把該踩的地雷都踩完了...
大概吧... 不知道還有多少地雷要踩 :o
弄 OpenVPN,直接把踩到的地雷列一下:
弄 OpenVPN,直接把踩到的地雷列一下:
- FreeBSD 上用 pf 不能直接對 interface 開放,因為 OpenVPN 可能會在 pf 都跑完後才跑起來。查資料的時候有找到資料說,可以讓 pf 不要 cache 這部份,不過測了老半天測不出來,最後還是用 IP range 來做。
- OpenVPN 2.2 已經改成一個 interface 通殺所有 client,而不是一個 client 一個 interface,測了老半天發現是誤會一場,manpage 裡有寫現在變成這樣。(不知道從哪個版本變成這樣,至少裝的 2.2 是...)
- 如果 dhcp-option 只推 dhcp-option DNS 而沒有推 dhcp-option DOMAIN,Ubuntu 下的 DNS 設定不會生效,據說是 spec feature... +_+
- 如果要吃 RADIUS,可以透過 PAM 處理。不過 pam.d 的設定檔內只能用 try_first_pass,不能用 use_first_pass,原因看一下 FreeBSD 的 pam_radius manpage,裡面有說明。
- 另外,如果要用 RADIUS,記得設定 template_user 避免有 local account 的人會過,沒有 local account 的人就掛了...。
暫時踩到這些...
星期三, 7月 11, 2012
用 Percona Xtrabackup 複製資料給 slave 用
在幾乎都是 InnoDB table 的環境下,可以用 Percona Xtrabackup 產生出一份完整的資料,提供給 MySQL Slave 用。主要是參考這兩份文件:
我安裝 Percona Xtrabackup 是透過 apt-get,如果要用其他安裝方式也可以,這邊就不提了。
跑法是先在 master 機器上跑 innobackupex:(要記得 /data 下得有足夠的空間放檔案)
我安裝 Percona Xtrabackup 是透過 apt-get,如果要用其他安裝方式也可以,這邊就不提了。
跑法是先在 master 機器上跑 innobackupex:(要記得 /data 下得有足夠的空間放檔案)
# innobackupex /data/db/
# innobackupex --apply-log /data/db/xxx/
其中第二個指令中的 xxx 是 innobackupex 產生的目錄。
等這些指令跑完後,就可以把整個目錄複製到別台使用,在 xtrabackup_binlog_info 裡面有 master 的 binlog 資訊可以讓你設定。
其中比較要注意的地方是不能加上 --compress,因為 --apply-log + --compress 會失敗,這個問題在 Percona Xtrabackup 的 Launchpad 上有看到有 ticket 在處理了。
等這些指令跑完後,就可以把整個目錄複製到別台使用,在 xtrabackup_binlog_info 裡面有 master 的 binlog 資訊可以讓你設定。
其中比較要注意的地方是不能加上 --compress,因為 --apply-log + --compress 會失敗,這個問題在 Percona Xtrabackup 的 Launchpad 上有看到有 ticket 在處理了。
標籤:
backup,
database,
db,
innodb,
percona,
replication,
slave,
xtrabackup
星期二, 6月 26, 2012
XtraBackup 2.0.1
Percona 更新了 XtraBackup:「Announcing Percona XtraBackup 2.0.1」。
對於使用 Percona XtraDB Cluster (Galera Cluster) 的人,幾乎都應該設定 XtraBackup 為 full resync 工具。在 resync 過程中才不對讓提供資料的 server 停止服務 (如果用 rsync 當 resync 工具,會停止服務)。
這個版本修正了一個之前遇到的問題:當單檔超過 8GB 的時候會爛掉。
之前的解法是自己用 bzr 把 2.0 branch 拉下來編一個 xtrabackup-5.5 出來用 (我遇到的時候其他人也已經遇到了,patch 也已經進 branch 2.0 了),現在只要 apt-get 裝起來就可以了...
標籤:
backup,
mysql,
percona,
tar,
xtrabackup
星期日, 6月 24, 2012
在 Mac 上的 DNS split tunnel
不論是 Cisco ASA 的 IPSec client,還是 Juniper SA SSLVPN 連線,在 Mac 上遇到 DNS split tunnel 設定時都不太正常,常常會不吃 VPN 給的 DNS 設定。
剛剛在網路發現「Split Tunnel DNS or per domain DNS」這篇方法,測了一下至少是有用的?算是一個方向...
先在 /etc 下建立 resolver 目錄,然後把公司的 DNS 設定丟進去,看起來就 okay 了?
訂閱:
文章 (Atom)