<?xml version="1.0" encoding="UTF-8"?><!-- generator="WordPress/2.5.1" -->
<rss version="0.92">
<channel>
	<title>Jui-Nan Lin's Blog</title>
	<link>http://jnlin.org</link>
	<description>Eric's point of view and mumuring...</description>
	<lastBuildDate>Tue, 13 May 2008 16:16:59 +0000</lastBuildDate>
	<docs>http://backend.userland.com/rss092</docs>
	<language>en</language>
	
	<item>
		<title>FreeBSD: 用 ZFS 的 volume 當作 iSCSI Target</title>
		<description>簡單的說，可以把 iscsi-target 的 extent 設成 ZFS 的 volume 就可以了...不過我不知道如果 extent 的大小設超過 iscsi-target 會發生什麼事。  # zfs create -V 10g tank/iscsi# cd /usr/ports/net/iscsi-target/ ; make install clean# cat &#62; /usr/local/etc/iscsi/targetsextent0&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; /dev/zvol/tank/iscsi&#160;&#160;&#160;&#160; 0&#160;&#160;&#160;&#160;&#160;&#160; 10GBtarget0&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; rw&#160;&#160;&#160;&#160;&#160; extent0&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; 10.0.0.0/24^D# /usr/local/etc/rc.d/iscsi_target forcestart 這樣就可以用別的 iSCSI initiator 來連接 iSCSI Target 了。 </description>
		<link>http://jnlin.org/2008/05/14/291/</link>
			</item>
	<item>
		<title>MySQL on Mtron SSD 之二</title>
		<description>我們把 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 是被用到哪裡去了？ </description>
		<link>http://jnlin.org/2008/05/07/290/</link>
			</item>
	<item>
		<title>加班</title>
		<description>下午發生了緊急事件，於是就跟老闆還有老闆的老闆還有大神三個人衝到內湖機房，搞到早上五點天都亮了才結束...OTL其實之前也有在機房加班到凌晨三四點啦，不過這次原因更囧了。haproxy萬歲啊！ 另外也因為這次的事件，有幸拜會了B站的老闆，還有傳說中的第N代的BBS。B站的老闆說第一代BBS現在被供奉在公司的辦公桌旁，比起被當成皮球的某「有站」的BBS來說，還真是好命啊...  </description>
		<link>http://jnlin.org/2008/04/29/289/</link>
			</item>
	<item>
		<title>MySQL (MyISAM) 的備份</title>
		<description>當系統小的時候，用 mysqldump 在離峰時間把資料 dump 出來還算可行。雖然 Table 會暫時 Lock 住，但是因為小，所以速度可以很快，鎖住的時間可以不計。但當系統大的時候就不能這樣做了。 好在已經有許多處理這個問題的經驗者。解決這個問題的 Key Point 是「減少鎖 Table 的時間」，因此如果採用的 File System 或是 Volume Manager 有支援快速的 snapshot 功能的話，整個問題就簡單很多。步驟如以下所示：  SLAVE STOP; FLUSH TABLE WITH READ LOCK; 作 snapshot  UNLOCK TABLES; SLAVE START; 如果採用 LVM (Linux), ZFS (FreeBSD, Solaris) 或是 NetApp 的話，整個備份過程可以小於 5 秒鐘，因此可以做到每個小時備份一次而不影響正常使用。如果在 Slave ...</description>
		<link>http://jnlin.org/2008/04/23/287/</link>
			</item>
	<item>
		<title>高捷遊記</title>
		<description>這次趁去墾丁的機會回了老家一趟，也因此搭了高捷。
世運站
高雄車站，高捷的地下車站都有月台門
中央公園站
其實感覺跟台北捷運差不多，不過車廂比較少，所以比較擠。還有就是驗票閘門有點秀逗，三次裡面有兩次單程票沒辦法一次就順利回收，要重新再試第二次才能順利回收。
&#160; </description>
		<link>http://jnlin.org/2008/04/22/286/</link>
			</item>
	<item>
		<title>這就是網路公司的員工旅遊&#8230;</title>
		<description> </description>
		<link>http://jnlin.org/2008/04/22/283/</link>
			</item>
	<item>
		<title>screenrc 指定視窗 encoding</title>
		<description>23:58 &#60;@sunpoet&#62; wens 是新的不能亂洗澡站長。 :P23:58 &#60;@sunpoet&#62; 原來之前改錯地方，現在 screenrc 裡面可以用 -b/-g 指定該視窗要哪個 encoding 啦。00:06 &#60; NotExist&#62; sunpoet: 你用哪版@@ 我man沒看到 囧rz00:06&#160; * NotExist 想那功能也很久....00:10 &#60;@sunpoet&#62; NotExist: 自己 patch ...00:15 &#60;@sunpoet&#62; NotExist: http://sunpoet.net/mira/screen-big5-gbk00:16 &#60;@sunpoet&#62; 像這樣連大神的站 screen -b -t abpe 2 env LANG=C LC_ALL=en_US.ISO8859-1 telnet abpe.org00:20 &#60; NotExist&#62; sunpoet: XD 感謝00:20 &#60;@sunpoet&#62; NotExist: 因為我懶惰 ...</description>
		<link>http://jnlin.org/2008/04/18/281/</link>
			</item>
	<item>
		<title>TAMAMA~</title>
		<description> </description>
		<link>http://jnlin.org/2008/04/16/280/</link>
			</item>
	<item>
		<title>MySQL 在 Mtron SSD 上的測試</title>
		<description>這次PIXNET進了2顆 32G Mtron MSP-SATA70（Spec 上寫的寫入速度為 90MB/s，讀取速度為 120MB/s），裝在 8-way、12G RAM 的 Debian Linux 上，跑 MySQL 5.1 Slave，用 MyISAM 當 backend。最大的 MyISAM Table 大概有 3GB。  這次一開始就採用 RAID 0, 4KB stripe size + XFS (4 KB Data Size) + noop disk scheduler。測試開始時，從DB Master複製資料所需的時間，大概是兩顆 SCSI 10k RPM + XFS 的 1/3，約 70MB/s。接著 replication ...</description>
		<link>http://jnlin.org/2008/04/12/279/</link>
			</item>
	<item>
		<title>Mtron SSD 在 MySQL (MyISAM) 上跑了兩個小時</title>
		<description>果然是一分錢一分貨，拷貝資料庫花的時間比起 SCSI 10k RPM RAID0 少了 2/3。採用與MySQL 在創見 SSD 上的測試同樣的設定，並真正上線灌真實流量進去後，觀察到 CPU Bound 了。  </description>
		<link>http://jnlin.org/2008/03/27/278/</link>
			</item>
</channel>
</rss>
