Quantcast
Channel: りんけーじ
Viewing all 62 articles
Browse latest View live

GlusterFSをESXiから使う(失敗)

$
0
0

普通の使い方を意識してやってみる。

ごみを消しておく。

# gluster volume stop gv0
# gluster volume delete gv0

2台にglusterfsを入れて、volumeを作る。
テスト用VMはzpoolがあるので、これをそのまま使う。

gluster1# zfs create -o mountpoint=/glusterfs-data zroot/glusterfs-data
gluster2# zfs create -o mountpoint=/glusterfs-data zroot/glusterfs-data
gluster1# gluster peer probe 10.0.0.2
gluster1# gluster volume create gv0 replica 2 10.0.0.1:/glusterfs-data/brick
gluster1# gluster start gv0

ESXiからはホスト10.0.0.1、フォルダ/gv0のNFSストレージに接続させる。


やたら時間がかかる。ディスクに負荷もかかっていない。
ログを見てみると酷いことになっていた。

/var/log/glusterfs/nfs.log

[2016-01-10 19:36:48.272299] W [client-rpc-fops.c:2478:client3_3_readdirp_cbk] 0-gv0-client-│0: remote operation failed: Invalid argument

/var/log/glusterfs/bricks/glusterfs-data-brick.log:

[2016-01-10 20:20:41.485157] E [posix.c:4902:posix_fill_readdir] 0-gv0-posix: seekdir(0x5) failed on dir=0x806813940: Invalid argument (offset reused from another DIR * structure?)
[2016-01-10 20:20:41.485283] I [server-rpc-fops.c:1882:server_readdirp_cbk] 0-gv0-server: 36451: READDIRP -2 (d3608328-6167-42fe-8ec8-e6cde384e1ab) ==> (Invalid argument)

風の噂から以下を試すも、効果なし。

# gluster volume set gv0 nfs.enable-ino32 on

結局いろいろ調べたらposix storageのバグっぽかったから、Bugとして登録しちゃった。

今日はucarpを入れて冗長構成を試すところまで行きたかったんだけど、横道に逸れちゃったのでまた後日。


GlusterFSとucarpを試す

$
0
0

GlusterFSとucarpを使って、冗長構成なNFSを作ってみる。
まぁ、難しいことは何もなく、普通に動いた。

aとbがGlusterFS/NFSサーバ、cがクライアント。
いずれもFreeBSD 10.1-RELEASE-amd64。

GlusterFSの設定。

a# zfs create -o mountpoint=/glusterfs-data zroot/glusterfs-data
b# zfs create -o mountpoint=/glusterfs-data zroot/glusterfs-data
a# gluster volume create gv0 replica 2 10.0.0.1:/glusterfs-data/brick 10.0.0.2:/glusterfs-data/brick
a# gluster volume start gv0

ucarpの設定は/etc/rc.confにて。

ucarp_enable="YES"
ucarp_addr="10.0.0.127"
ucarp_if="em0"
ucarp_src="10.0.0.1"
ucarp_pass="password"
ucarp_vhid="127"
ucarp_upscript="/usr/local/sbin/ucarp-up"
ucarp_downscript="/usr/local/sbin/ucarp-down"
ucarp_xparam="em0 ${ucarp_addr}"

b側はucarp_srcを10.0.0.2に。

あとは第3のホストからNFSをマウントするだけ。

c# mkdir /glusterfs
c# mount -t nfs 10.0.0.127:/gv0 /glusterfs

aやbをrebootしたりしてみても、キチンと接続は維持されている。
……でも実感がないので少々いじめてみる。

いじめ用スクリプトはこちら。

  • aがMASTER時に、aをshutdown。
    もちろん問題なし。ただし、shutdownしてから少しの間は固まる。
  • aがMASTER時に、a, bの順にshutdown、a, bの順に起動。
    aを起動しても回復しない(cは固まりっぱなし)が、bが起動してから回復。
    起動時にpeerをチェックしてるのかな?
  • aがMASTER時に、a, bの順にshutdown、b, aの順に起動。
    これも動作としては変わらず。すでに動いている場合はともかく、単独では起動できないらしい。

split brainになって壊れないかなーと思ったけどならない。
quorumが有効なのかと思って調べたけどそんなこともない。

# gluster volume set help
(...snip...)
Option: cluster.quorum-type
Default Value: none

そもそもquorumが有効だったら、片方が落ちた時点で書き込めなくなるハズだしね。

GlusterFSのdisperseを試す(失敗)

$
0
0

RAID-5/6のように効率の良い冗長化をするべく、disperseを試してみる。
結局xattrs絡み?で失敗。

# gluster volume create gv0 disperse redundancy 1 10.0.0.1:/glusterfs-data/brick 10.0.0.2:/glusterfs-data/brick 10.0.0.3:/glusterfs-data/brick

前回と同様に読み書き中に切断してみると、エラーが出たり止まったり。
self-healも失敗したりしてロクでもない。

/var/log/glusterfs/nfs.log:

[2016-01-11 21:09:56.061341] E [ec-helpers.c:400:ec_loc_setup_path] 0-gv0-disperse-0: Invalid path '' in loc
[2016-01-11 21:09:56.061450] I [dht-layout.c:663:dht_layout_normalize] 0-gv0-dht: Found anomalies in  (gfid = 820db491-6926-446d-ae73-06e35012b0da). Holes=1 overlaps=0
[2016-01-11 21:09:56.061557] E [nfs3-helpers.c:3616:nfs3_fh_resolve_inode_lookup_cbk] 0-nfs-nfsv3: Lookup failed: : Input/output error
[2016-01-11 21:09:56.061602] E [nfs3.c:2148:nfs3_write_resume] 0-nfs-nfsv3: Input/output error: (10.33.4.177:781) gv0 : 820db491-6926-446d-ae73-06e35012b0da
[2016-01-11 21:09:56.061632] W [nfs3-helpers.c:3401:nfs3_log_common_res] 0-nfs-nfsv3: XID: 54c917c4, WRITE: NFS: 5(I/O error), POSIX: 14(Bad address)

ここでついに、zfs(xattrをサポートしていない)にbrickを置いたことが災いした模様。
xattrは、NFS越しにxattrを使わなければ困らないだろうと甘く見ていた。

[Bugs] [Bug 1181048] lockless lookup cause disk to be kicked out

このあたりを読んでいて嫌な予感はしていた。
GlusterFSとZFSを組み合わせるには

仕方がないのでUFSにする。もちろんzvolで。

rc.conf:

zvol_enable="YES"

念のためglusterfsとどちらが先に起動するか見ておく。できればREQUIRESに書いてやりたいがとりあえず放置。

# rcorder /etc/rc.d/* /usr/local/etc/rc.d/*
root@gluster3:~ # rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | grep -E "glusterfsd|zvol"
/etc/rc.d/zvol
/usr/local/etc/rc.d/glusterfsd

zvolを作ってUFSを乗せる。格好悪いなぁ。
debugflagsをつけないとmountがoperation not permittedでコケる。

# zfs create -V 12G zroot/glusterfs-data
# newfs /dev/zvol/zroot/glusterfs-data
# echo '/dev/zvol/zroot/glusterfs-data /glusterfs-data ufs rw 0 0' >> /etc/fstab
# echo 'kern.geom.debugflags=0x10' >> /etc/sysctl.conf

あとは冒頭のgluster volume createをやり直してリトライ。

結果は……

[2016-01-11 23:00:05.651061] W [ec-combine.c:801:ec_combine_check] 0-gv0-disperse-0: Mismatching xdata in answers of 'LOOKUP'
[2016-01-11 23:00:05.651120] C [nfs.c:463:nfs_start_subvol_lookup_cbk] 0-nfs: Failed to lookup root: Input/output error

このあともいろいろ考えて試してみたもののうまくいかず。

  • 先のBugZillaをみると”ルートディレクトリのxattrsが違うよ”という報告が出てるから、もしかして/glusterfs-dataのマウント先である/がzfsなのが悪い?
    → zfs-ufs-ufsなマウントにしてみたけど解消せず。
  • xattrsにtrusted名前空間が使われているけど、FreeBSDのUFSはsystemとuserしかない。そりゃ失敗するよね?
    → ちゃんとuser名前空間に行くようになってた。libglusterfs/src/syscall.csys_lsetxattrとかで、OSごとに切り替えられてる。

わからないので持ち越し。

GlusterFSのdisperseを試す(その2)

$
0
0

とりあえずxattrsが云々というからにはzfsはダメだろうから、UFS on ZVOLな構成で続けてみた。
まだ道のりは長そう。

相変わらずマウントできないなーと思って3ノードのログを見比べていたらこんなものを見つけた。
タイミングとしてはgluster volume createであろう。

[2016-01-12 17:51:18.413120] E [client-handshake.c:1496:client_query_portmap_cbk] 0-gv0-client-2: failed to get the port number for remote subvolume. Please run 'gluster volume status' on server to see if brick process is running.

3台のうちある1台でだけ出ていて、これのせいかxattrsがbrickに設定されず、最終的に0-gv0-disperse-0: Mismatching xdata in answers of 'LOOKUP'に至っているものと推測。

下手な検索を何度かして、これにたどり着いた。

Bug 894556 – Failed to get the port number for remote subvolume error when starting a volume for the first time.

またBugですかいな。WORKSFORMEでCloseされてるけど。
NFS ServerとBrickのrace conditionだと言われてる。ということは、もしかして先にダミーのVolumeを作っておけばいい?

# gluster volume create dummy 10.0.0.1:/glusterfs-data/dummy 10.0.0.2:/glusterfs-data/dummy 10.0.0.3:/glusterfs-data/dummy
# gluster volume create disperse gv0 10.0.0.1:/glusterfs-data/dummy 10.0.0.2:/glusterfs-data/dummy 10.0.0.3:/glusterfs-data/dummy

これで先のエラーは出なくなった。WORKSFORMEじゃないよ、raceだってわかってるんだから直しなよ……。

で、これでも動かなかったので少し調べたら、rpcbindの設定が一台だけ間違っていた。恥ずかしい。
一台だけ、しかもこのマシンがucarpのMASTERを取ってて、以下の設定を追加してた。
これを外すことでとりあえずは解決。

rpcbind_flags="-h 10.0.0.127"

これでマウントして読み書きできるようになった。
できるが、書き込み中に一台のノードをぶっちぎったらエラーを山ほど吐きっぱなしになって復旧しなくなった。

[2016-01-15 01:01:54.466105] W [ec-combine.c:76:ec_iatt_combine] 0-gv0-disperse-0: Failed to combine iatt (inode: 11735403145588290470-11735403145588290470, links: 1-1, uid: 0-0, gid: 0-0, rdev: 322123661424-571232551144, size: 148176896-148209664, mode: 100644-100644)
[2016-01-15 01:01:54.466154] N [ec-generic.c:819:ec_combine_lookup] 0-gv0-disperse-0: Mismatching iatt in answers of 'GF_FOP_LOOKUP'
[2016-01-15 01:01:54.466169] W [ec-common.c:162:ec_check_status] 0-gv0-disperse-0: Operation failed on some subvolumes (up=7, mask=7, remaining=0, good=5, bad=2)
[2016-01-15 01:01:54.466222] E [ec-helpers.c:400:ec_loc_setup_path] 0-gv0-disperse-0: Invalid path '' in loc
[2016-01-15 01:01:54.466252] W [ec-common.c:121:ec_heal_report] 0-gv0-disperse-0: Heal failed (error 12)
[2016-01-15 01:01:54.466284] E [ec-helpers.c:400:ec_loc_setup_path] 0-gv0-disperse-0: Invalid path '' in loc
[2016-01-15 01:01:54.466333] I [dht-layout.c:663:dht_layout_normalize] 0-gv0-dht: Found anomalies in  (gfid = ae930c59-e4ab-4142-a2dc-86fbeccab3a6). Holes=1 overlaps=0
[2016-01-15 01:01:54.466396] E [nfs3-helpers.c:3616:nfs3_fh_resolve_inode_lookup_cbk] 0-nfs-nfsv3: Lookup failed: : Input/output error
[2016-01-15 01:01:54.466415] E [nfs3.c:2148:nfs3_write_resume] 0-nfs-nfsv3: Input/output error: (10.33.4.177:631) gv0 : ae930c59-e4ab-4142-a2dc-86fbeccab3a6
[2016-01-15 01:01:54.466430] W [nfs3-helpers.c:3401:nfs3_log_common_res] 0-nfs-nfsv3: XID: 5408ef49, WRITE: NFS: 5(I/O error), POSIX: 14(Bad address)

というわけでさらに持ち越し。
いい加減動いて欲しい。

GlusterFSのdisperseを試す(その3)

$
0
0

この間の続き。やっと解決。
FreeBSDとLinuxのmajor/minor/makedev関数の違い、statが通常ファイルに対して返すrdev値の違いによる問題。

[2016-01-15 01:01:54.466105] W [ec-combine.c:76:ec_iatt_combine] 0-gv0-disperse-0: Failed to combine iatt (inode: 11735403145588290470-11735403145588290470, links: 1-1, uid: 0-0, gid: 0-0, rdev: 322123661424-571232551144, size: 148176896-148209664, mode: 100644-100644)

sizeはとりあえずいい。healなんだから、大きさが違うこともある。
でもrdevとやらは良くない匂いがする。

rdevはそもそもキャラクタデバイスなんかを表す番号のはず。
エラーログにある数字は一体なんなのか。

(gdb) printf "%16llx\n%16llx\n", 322123661424, 571232551144

      4b00110070
      85001d00e8

ますます怪しい。
この値を作っているのはlibglusterfs/src/iatt.hの以下の部分。

static inline int
iatt_from_stat (struct iatt *iatt, struct stat *stat)
{
        /* snip */
        iatt->ia_rdev       = ia_makedev (major (stat->st_rdev),
                                          minor (stat->st_rdev));

これはおなじみstruct statから、glusterfsの内部で使うstruct iattに変換している模様。
ではia_makedevmajorminorはどこにあるのか。
ia_makedevはすぐ近く(同じiatt.h)に。

ia_makedev (uint32_t ia_maj, uint32_t ia_min)
{
        return ((((uint64_t) ia_maj) << 32) | ia_min);
}

majorminorは、FreeBSDの場合は/usr/include/sys/types.hにある。

#define major(x)        ((int)(((u_int)(x) >> 8)&0xff)) /* major number */
#define minor(x)        ((int)((x)&0xffff00ff))         /* minor number */
#define makedev(x,y)    ((dev_t)(((x) << 8) | (y)))     /* create dev_t */

ずいぶんと面白い定義になってるけど、きっと"歴史的経緯"というやつだろう。
で、こいつらのせいでrdevは本来の値から変な変形を受けている。
struct statからstruct iattが作られたのなら、こうなるはずだ。

stat側: 11223344
iatt側: 3311220044

これに先の値を当てはめて元に戻してみる。

iatt側1: 4b00110070
stat側1: 00114b70 (=1133424)
iatt側2: 85001d00e8
stat側2: 001d85e8 (=1934824)

それっぽいので、このrdev値をもつファイルを探してみよう。

# ssh root@10.0.0.1 "find /dummy-root/glusterfs-data | xargs -n 1 stat -f '%r %R'" > /tmp/stats-1.txt
# ssh root@10.0.0.2 "find /dummy-root/glusterfs-data | xargs -n 1 stat -f '%r %R'" > /tmp/stats-2.txt
# ssh root@10.0.0.3 "find /dummy-root/glusterfs-data | xargs -n 1 stat -f '%r %R'" > /tmp/stats-3.txt
# grep -E "1133424|1934824" /tmp/statall*
/tmp/statall2.txt:1133424 /dummy-root/glusterfs-data/brick/.glusterfs/ae/93/ae930c59-e4ab-4142-a2dc-86fbeccab3a6
/tmp/statall2.txt:1133424 /dummy-root/glusterfs-data/brick/random.dat
/tmp/statall3.txt:1934824 /dummy-root/glusterfs-data/brick/.glusterfs/ae/93/ae930c59-e4ab-4142-a2dc-86fbeccab3a6
/tmp/statall3.txt:1934824 /dummy-root/glusterfs-data/brick/random.dat

出てきた。

ところで、rdevってregular fileに付くの……?

# stat -f '%r %N' / /COPYRIGHT /dummy-root
4294967295 /
4294967295 /COPYRIGHT
120 /dummy-root

/はZFS。UFSだとregular fileもrdevは有効な値になる……?

ちょっとバージョンは違うけどFreeBSD 9.0のソースコードより、
sys/ufs/ufs/dinode.h:

/*                                                              
 * The di_db fields may be overlaid with other information for  
 * file types that do not have associated disk storage. Block   
 * and character devices overlay the first data block with their
 * dev_t value. Short symbolic links place their path in the    
 * di_db area.                                                  
 */
#define di_rdev di_db[0]

意訳するとdi_dbフィールドはディスク領域を割り当てないようなファイルタイプについては他の情報が載ってる場合があるよ
デバイス系だとdev_t番号、すなわちrdevの値。ディスク領域を割り当てるようなファイル、つまりregular fileの場合、ここは本来Direct disk blocksなので、きっと割り当てブロックの情報が入るのであろう。
つまり、regular fileに対して実行したstatのst_rdevは読んではいけない。

POSIXのstatの定義はどうなっているか。
stat - get file status
sys/stat.h

はっきりとは書かれていないが、構造体定義にst_rdevDevice ID (if file is character or block special).と書かれているので、character/block device以外については不定と考えるべきだろう。少なくとも、いつも同じ値を返す義理はない。

となればglusterfsのバグ。さくっと直して続けてみる。

[2016-01-16 01:27:35.331128] W [ec-common.c:162:ec_check_status] 0-gv0-disperse-0: Operation failed on some subvolumes (up=7, mask=5, remaining=0, good=5, bad=2)
[2016-01-16 01:27:35.331231] I [ec-heal.c:546:ec_heal_init] 0-ec: Healing '(null)', gfid db8166d5-06be-4d04-bbf1-de9f2b911ccb
[2016-01-16 01:27:35.331278] E [ec-helpers.c:473:ec_loc_parent] 0-gv0-disperse-0: Parent inode missing for loc_t
[2016-01-16 01:27:35.331319] W [ec-common.c:121:ec_heal_report] 0-gv0-disperse-0: Heal failed (error 5)

これはどうやらディレクトリがHealできていないのが原因らしい。

client# ls -al /glusterfs

もしくは、実運用などでまとめてHealするなら、 client# find /glusterfs -exec stat {}\; >/dev/null
でできる。

これでエラーもおさまった。
先の件もバグに登録済み。

あとはESXiから使う話に戻ろう。

py-opencvがmakeできない

$
0
0

うっかりpkg installして、手動ビルドしたopencvが上書きされちゃった。
ffmpegがないとH.264が読めないじゃんさ……。

そのまま再ビルドしようとしたらvulnerableだといってインストールさせてくれない。
しょうがないからとports treeを更新してからやり直したら、ビルドがコケた。

結果的にはports側のpkg-plistを書き換えて対応。

# make
(snip)
===>   Registering installation for opencv-2.4.9_7 as automatic
(snip)
pkg-static: Unable to access file /usr/ports-work/opencv/stage/usr/local/share/OpenCV/haarcascades/haarcascade_eye.xml: No such file or directory
(他多数)

ports壊れた?
make cleanしてもdistcleanしても変わらず。
py-opencvは内部的にopencvらしい(当たり前か)なので、それらをcleanしたら直るか?とやってみても変わらない。

# cd /var/db/ports
# rm -rf graphics_opencv graphics_py-opencv

これでもだめか。
しょうがないからデバッグしよう。

元ファイルはdata/haarcascades/以下にちゃんとある。
対応するCMakeList.txtdataにある。
ということは参照されてない……?

CMakeは使ったことがないからわからないけど、add_directoryでサブディレクトリのCMakeList.txtを読んでくれそうな気がする。
で、直下のCMakeList.txtをみると、add_directory(data)がない。

あれー……?ということでports直下のMakefileを見てみると、

.if defined(OCV_SLAVE)
        @${REINPLACE_CMD} -e 's|add_subdirectory(data)||g' \
                ${WRKSRC}/CMakeLists.txt
.endif

OCV_SLAVEは、どうやらpy-opencvからmakeするとOCV_SLAVE=pythonになる模様。

さてこの変更は2014/09に導入されていて、そんなに新しいわけではない。
みんなビルドできてる?

Update to 2.4.9 (opencv側の更新)
Update graphics/*opencv* to 2.4.7 (py-opencv側の更新)

そして、なんでdataを排除してるんだろう?
インストールしないならpkg-plistからも削除しないといけない。しかもpy-opencvのビルド時だけという条件付きで。
portsのマニュアルを少し読んでみる。

Chapter 7. Advanced pkg-plist Practices

Makefile中でPLIST_SUBA=Bの形式で書いて、pkg-plist%%A%%を書くとBになる。そしてpkg-plistの@commentで始まる行は無視されるので、これを使って対象外にするんだけど……。
どうやらopencvのplistを生成するターゲットは別の経路から起動されているようで適用できない。

今回はしょうがないからpkg-plistから問題のファイルを(無条件で)削除して対応。

VMware ESXiの仮想マシン強制リセット

$
0
0

VMware ESXiで動いている仮想マシンが突如クラッシュしてはまった。
電源OFFもリセットも聞かなくて困ったのでメモ。

要はkillすればいい。

とりあえずVMware FusionやvSphere Clientが寝ぼけているだけの可能性を考慮して、sshからvim-cmdしてみる。

~ # vim-cmd vmsvc/getallvms
Vmid       Name                         File                         Guest OS       Version   Annotation
(...snip...)
6      feather-core   [himawari] feather-core/feather-core.vmx   windows7_64Guest   vmx-07              
~ # vim-cmd vmsvc/power.on 6
Powering on VM:
Power on failed
~ # vim-cmd vmsvc/power.off 6
Powering off VM:
Power off failed

VMware Fusionでは電源操作のボタンがグレーになったままで制御不能。

/var/log/hostd.logによるとこんなのが出ているけど、さっぱり。
状態機械が壊れたかね……。

2016-02-16T11:52:38.970Z [5D680B90 error 'vm:/vmfs/volumes/ac1adf04-f1d9bbec/feather-core/feather-core.vmx'] Invalid transition requested (VM_STATE_SETTING_SCREEN_RES -> VM_STATE_SETTING_SCREEN_RES): Invalid state

ルータやらサーバやらが同居しているホストなので再起動はしたくない。
しょうがないので少し頑張る。

~ # ps -c | grep feather
18192674 18192674 vmx                  /bin/vmx -ssched.group=host/user -# name=VMware ESX;version=5.0.0;buildnumber=623860;licensename=VMware ESX Server;licenseversion=5.0 build-623860; -@ pipe=/tmp/vmhsdaemon-0/vmx7c0a24ea84a42345; /vmfs/volumes/ac1adf04-f1d9bbec/feather-core/feather-core.vmx
18190627      vmm0:feather-core   
18192677      vmm1:feather-core   
18190630 18192674 vmx-vthread-5:feather-core /bin/vmx -ssched.group=host/user -# name=VMware ESX;version=5.0.0;buildnumber=623860;licensename=VMware ESX Server;licenseversion=5.0 build-623860; -@ pipe=/tmp/vmhsdaemon-0/vmx7c0a24ea84a42345; /vmfs/volumes/ac1adf04-f1d9bbec/feather-core/feather-core.vmx
18192679 18192674 vmx-mks:feather-core /bin/vmx -ssched.group=host/user -# name=VMware ESX;version=5.0.0;buildnumber=623860;licensename=VMware ESX Server;licenseversion=5.0 build-623860; -@ pipe=/tmp/vmhsdaemon-0/vmx7c0a24ea84a42345; /vmfs/volumes/ac1adf04-f1d9bbec/feather-core/feather-core.vmx
18192680 18192674 vmx-vcpu-0:feather-core /bin/vmx -ssched.group=host/user -# name=VMware ESX;version=5.0.0;buildnumber=623860;licensename=VMware ESX Server;licenseversion=5.0 build-623860; -@ pipe=/tmp/vmhsdaemon-0/vmx7c0a24ea84a42345; /vmfs/volumes/ac1adf04-f1d9bbec/feather-core/feather-core.vmx
18194729 18192674 vmx-vcpu-1:feather-core /bin/vmx -ssched.group=host/user -# name=VMware ESX;version=5.0.0;buildnumber=623860;licensename=VMware ESX Server;licenseversion=5.0 build-623860; -@ pipe=/tmp/vmhsdaemon-0/vmx7c0a24ea84a42345; /vmfs/volumes/ac1adf04-f1d9bbec/feather-core/feather-core.vmx
18193087 18193087 grep                 grep feather

きっとPID, PPIDの順だろうと推測すれば、最初に出ている18192674がマスタープロセスっぽい。
そうとわかればkillする。

~ # kill 18192674

再度ps -cでプロセスが消えていることを確認、あとはvim-cmdでpower onして解決。

Windows 10インストール

$
0
0

Windows 8.1でゲームをやってたらよく止まることがあって、イライラしたのでOSを入れなおしてみた。
要らないサービスが山盛りだったのでいろいろ無効化。自分用にGistに登録したのでメモを兼ねて置いておく。

Windows 10 Disable Services.bat

ちなみに遅い原因はOSではなく、GPUでもなく、My Documentsをネットワークドライブにしていたからだった。
EVE Onlineは大量にログを出力する関係、Killing Floor 2は書いてはいないが何かを読み込んでいる気がする。
(書き込みはバックアップソフトが同期を取った際のログで分かるが、読み込みは分からなかった。開いているハンドルでも見れば分かるかもしれないが。)


ehci0の割り込みがおかしい

$
0
0

なんだか最近、10秒ごとにgstatの結果表示やらSSHやらが固まると思ったら、interrupt stormっぽい現象が起きてた。
秒間180000件も割り込みが起きてりゃ、いろいろおかしくなるでしょう。

踏んだバグは、どうやらこの辺らしい。

[ehci] Extremely high interrupt rate on ehci/uhci IRQ16 80% cpu utilization on CPU0

FreeBSD 9系、10系ともにJun 17 2015, つまり2015/06/17に修正版がコミット済みなので、きっと9.4-RELEASEには入っている。
が、我が家で問題を起こした子はストレージなので怖くてアップグレードなんてできない。ので、また今度にでも検証の予定。

参考までに、vmstat -iの出力はこんな感じ。
ehci0のrateがひどい。ころすきか。

[alraune:~] root# vmstat -i
interrupt                          total       rate
irq16: ehci0                189959870759     181976
irq23: ehci1                   100515935         96
cpu0:timer                     490818324        470
irq264: mpt0                   170437921        163
irq265: em0                    363774409        348
irq266: em1:rx 0                35215428         33
irq267: em1:tx 0                    4345          0
irq268: em1:link                       2          0
irq269: ahci0                   91384771         87
cpu1:timer                     467425458        447
cpu3:timer                    1175161820       1125
cpu2:timer                     422516053        404
Total                       193277125225     185154

system(kernel)のCPU使用率

$
0
0

先日ehci0の割り込みが暴れたサーバをちょっとだけアップデートした。
結局怖いのでUSB接続のHDDはやめにして、SATA接続に。

しかし起動してみると重いときがある。
おかしいと思って割り込みを見ても正常だけど、system(kernel)のCPU使用率が異常に高い。

どうやらtopで調べるとzfsの書き込み負荷が原因のようだったので、とあるzfscompressionを調整して解決。

問題発生時のtopはこんな感じ。これはいじりまわした後なので多少ましになっていて、元はload averageが10を超えていた。
topの-s1は更新周期1秒を、-Sはシステムプロセスの表示、-Hはスレッドの表示。
これでsystem%の内訳が見られる。

# top -s1 -SH

last pid: 92403;  load averages:  4.56,  3.61,  3.89                                     up 2+19:45:36  08:26:33
955 processes: 23 running, 913 sleeping, 1 zombie, 18 waiting
CPU:  0.2% user,  0.0% nice, 59.3% system,  0.0% interrupt, 40.5% idle
Mem: 404M Active, 998M Inact, 13G Wired, 1624K Cache, 6528K Buf, 741M Free
ARC: 11G Total, 2633M MFU, 7893M MRU, 36M Anon, 256M Header, 935M Other
Swap: 6144M Total, 576K Used, 6143M Free

  PID USERNAME      PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND

    0 root          -16    0     0K  9920K CPU0    0 628:50 15.77% kernel{zio_write_issue_}
    0 root          -16    0     0K  9920K -       3 628:39 15.77% kernel{zio_write_issue_}
    0 root          -16    0     0K  9920K CPU2    2 628:34 15.77% kernel{zio_write_issue_}
    0 root          -16    0     0K  9920K -       1 628:44 15.48% kernel{zio_write_issue_}

明らかにzio_write_issue_が原因。zfs関連でCPUを食いそうなのはdedupとcompressionと当たりをつけて、dedupは使っていないことからcompressionを調査。

# zfs get compression | grep -E 'local$'                       
sakura/elasticsearch                               compression  gzip-9    local
storage/db/zabbix                                  compression  gzip-9    local

どちらも常時大量に書いていそうなので、片方ずつzfs set compression=noneを試し、結局両方とも影響があったのでgzip-4に落としたところ軽くなった。

Change Logは追っていないけど、gzip-9の挙動が変わった……のかな?

XtreemFSをFreeBSDでビルドする

$
0
0

まだまだ長い旅路の途中。
成果物はGitHubの2510/xtreemfs (freebsd branch)に。

# pkg install bash gmake openjdk8 apache-ant python27 cmake boost-all fusefs-libs
# mount -t fdescfs fdesc /dev/fd
# git clone https://github.com/2510/xtreemfs
# setenv JAVA_HOME /usr/local/openjdk8
# gmake ANT_BIN=/usr/local/bin/ant PYTHON=python2.7 CC=cc CXX=c++
(中略)
BUILD SUCCESSFUL
# gmake ANT_BIN=/usr/local/bin/ant PYTHON=python2.7 CC=cc CXX=c++ install
# sh /etc/xos/xtreemfs/postinstall_setup.sh

今日のところはビルドだけ。
またそのうち、ね。

# /etc/init.d/xtreemfs-osd start
/etc/init.d/xtreemfs-osd: line 19: /etc/init.d/functions: No such file or directory

失敗集

ここから先はビルドを通す過程の記録。

gmake: -c: Command not found

# gmake
gmake: -c: Command not found
gmake: -c: Command not found
gmake: -c: Command not found
Makefile:185: recipe for target 'check_server' failed
gmake: *** [check_server] Error 127

bashが入ってないとこんなこと言われる。
-cがないってことからsh -cを想像すれば辿り着けるんだろうけど、私には無理だった。

make: “/root/XtreemFS-1.5.1/Makefile” line 1: Need an operator

# make
make: "/root/XtreemFS-1.5.1/Makefile" line 1: Need an operator
make: "/root/XtreemFS-1.5.1/Makefile" line 3: Need an operator
(以下略)

gmakeじゃなくてmakeしている場合。
FreeBSDではよくあること。

javac not found! Make sure a JDK is installed and set JAVA_HOME.

javac not found! Make sure a JDK is installed and set JAVA_HOME.
Makefile:185: recipe for target 'check_server' failed
gmake: *** [check_server] Error 1

書いてある通り。ちゃんとsetenv(もしくはexport)してくださいな。

ant not found!

# gmake
java ok
ant not found! Make sure ant is installed and set ANT_HOME.
Makefile:185: recipe for target 'check_server' failed
gmake: *** [check_server] Error 1

antは/usr/bin/ant${ANT_HOME}/bin/antを探すけれど、FreeBSDはどっちにもない。
Makefileを修正する。

ifeq "$(ANT_HOME)" ""
        ANT_BIN = /usr/bin/ant                                                                                                                                                                                                   
else
        ANT_BIN = $(ANT_HOME)/bin/ant                                                                                                                                                                                            
endif

を、

ifeq "$(ANT_HOME)" ""
        ANT_BIN := /usr/bin/ant                                                                                                                                                                                                   
else
        ANT_BIN := $(ANT_HOME)/bin/ant                                                                                                                                                                                            
endif

に変更。
ビルド時はgmake ANT_BIN=/usr/local/bin/ant

C++ ok (/usr/local/bin/bash: line 0: [: !: binary operator expected)

java ok
ant ok
/usr/local/bin/bash: line 0: [: !: binary operator expected
C++ ok

C++ okなんだからokでいいと思った?(cmakeが入ってなくてもokって言われる)
pkg install cmakeすること。ちなみにcmakeが入っていても同じエラーを吐くので、Makefileのcheck_clientターゲットの、

@if [ ! $(WHICH_GPP) -a ! $(WHICH_CLANGPP) ];
@if [ ! $(CMAKE_BIN) ]; then echo "cmake not found";exit 1; fi;

を、以下のように直してやる。

@if [ ! -x "$(WHICH_GPP)" -a ! -x "$(WHICH_CLANGPP)" ];
@if [ -n "$(shell $(CMAKE_BIN) --version 2>/dev/null)" ]; then echo "cmake not found";exit 1; fi;

javacやantは-eでチェック、g++やclangはバージョンも見るためにwhichでパスを拾って$(shell ...)をチェックしてる。
cmakeはバージョンに興味はないけど、whichしてないので-eが使えない。まぁ、setenv CMAKE_BIN ...とすればいいだけなんだけどね。

python ok (python:: syntax error in expression)

root@xtreemfs-test-1:~/XtreemFS-1.5.1 # gmake
java ok
ant ok
C++ ok
/usr/local/bin/bash: [[: python:: syntax error in expression (error token is ":")
python ok

python okなんだからokでいいと(以下略
これもMakefileが悪い。(python入ってないのにokって言われる)
pkg install python27して、ln -s /usr/local/bin/python27 /usr/local/bin/pythonしましょう。
もちろんMakefileも直す。

PYTHON := python

check_testターゲット

@if [ -z "$(shell which $(PYTHON) 2>/dev/null)" ]; then echo "python >= 2.4 required! (not installed)"; exit 1; fi;
@if [ "$(shell $(PYTHON) -V 2>&1 | head -n1 | cut -d' ' -f2 | cut -d. -f2)" -lt 3 -a "$(shell $(PYTHON) -V 2>&1 | head -n1 | cut -d' ' -f2 | cut -d. -f1)" -lt 3 ]; then echo "python >= 2.4 required! (version error)"; \
exit 1; fi;

testターゲット

$(PYTHON) ./tests/xtestenv -c ./tests/test_config.py short
# gmake ANT_BIN=/usr/local/bin/ant PYTHON=python2.7

Configuring incomplete, errors occurred!

CMake Error at /usr/local/share/cmake/Modules/FindBoost.cmake:1657 (message):
  Unable to find the requested Boost libraries.

  Unable to find the Boost header files.  Please set BOOST_ROOT to the root
  directory containing Boost or BOOST_INCLUDEDIR to the directory containing
  Boost's headers.
Call Stack (most recent call first):
  CMakeLists.txt:151 (FIND_PACKAGE)


CMake Error at CMakeLists.txt:153 (message):
  The boost library was not found on your system.  If needed, you can also
  download and compile it on your own.  After compiling boost locally, set
  the the environment variable BOOST_ROOT to the boost base directory before
  executing 'make' e.g., 'export BOOST_ROOT=/Users/xyz/boost_1_47_0'.


-- Configuring incomplete, errors occurred!
See also "/root/XtreemFS-1.5.1/cpp/build/CMakeFiles/CMakeOutput.log".
See also "/root/XtreemFS-1.5.1/cpp/build/CMakeFiles/CMakeError.log".
Makefile:275: recipe for target 'client' failed
gmake: *** [client] Error 1

これは簡単。pkg install boost-all
似たようなエラーがvalgrind, fuseが見つからない場合に出る。
特にfuseはpkg install fuseではなくpkg install fusefs-libsなので注意が必要。

Could not find or load main class org.apache.tools.ant.launch.Launcher

/usr/local/bin/ant -D"file.encoding=UTF-8" -f java/foundation/build-1.6.5.xml jar
Error: Could not find or load main class org.apache.tools.ant.launch.Launcher
Makefile:318: recipe for target 'foundation' failed
gmake: *** [foundation] Error 1

/bin/bash: bad interpreter: No such file or directory

# gmake ANT_BIN=/usr/local/bin/ant PYTHON=python2.7 install
/usr/local/bin/bash: etc/init.d/generate_initd_scripts.sh: /bin/bash: bad interpreter: No such file or directory
Makefile:94: recipe for target 'install-server' failed
gmake: *** [install-server] Error 126

bashは/binにあるとは限らない。これもFreeBSDではよくあること。

ただ、etc/init.d/generate_initd_scripts.shの最初の行を直してやればいいように見えて、大量のスクリプトが同様の依存をしているので腹立たしい。
面倒なので一掃。(tcshじゃない人は!の前のエスケープを外してね)

# find . -print0 | xargs -0 -n 1 sed -i '' -e 's=^#\!/bin/bash$=#\!/usr/local/bin/bash='

groupadd: not found

# sh /etc/xos/xtreemfs/postinstall_setup.sh
Generated UUID for service: dir
Generated UUID for service: mrc
Generated UUID for service: osd
/etc/xos/xtreemfs/postinstall_setup.sh: groupadd: not found

packaging/postinstall_setup.sh中のLinuxに固有なユーザ・グループ作成コマンド群が原因なので、pwで置き換える。

groupadd $XTREEMFS_GROUP

pw groupadd $XTREEMFS_GROUP
useradd -r --home $XTREEMFS_HOME -g $XTREEMFS_GROUP $XTREEMFS_USER

は、

pw useradd $XTREEMFS_USER -L daemon -d $XTREEMFS_HOME -g $XTREEMFS_GROUP

としてみた。
ところでuseradd-rはCreate a system accountらしいので、こちらではlogin class指定に置き換えてやった。意味は違うけど。

/var/lib: No such file or directory

# sh /etc/xos/xtreemfs/postinstall_setup.sh
Generated UUID for service: dir
Generated UUID for service: mrc
Generated UUID for service: osd
mkdir: /var/lib: No such file or directory

FreeBSDでは/var/libは使いません。
欲しいらしいのでくれてやりましょう。
packaging/postinstall_setup.sh中のmkdirを、片っ端からmkdir -pで置き換え。

stat: illegal option — c

root@xtreemfs-test-1:~/XtreemFS-1.5.1 # sh /etc/xos/xtreemfs/postinstall_setup.sh
Generated UUID for service: dir
Generated UUID for service: mrc
Generated UUID for service: osd
stat: illegal option -- c
usage: stat [-FLnq] [-f format | -l | -r | -s | -x] [-t timefmt] [file ...]

stat(1)の仕様違い。
どうやらstat -c %U /var/lib/xtreemfsしたいらしいので、stat -f %Su /var/lib/xtreemfsに直してやる。
対応関係はこんなところか。

  • stat -c %U → stat -f %Su
  • stat -c %G → stat -f %Gu
  • stat -c %a → stat -f %p

ただ%a%pは完全に互換ではなく、例えば以下のようになってしまう。
この関係で余計なchmodが走るけど……誰も気にしないだろう。

# chmod 640 /etc/xos/xtreemfs/dirconfig.properties
# stat -f %p /etc/xos/xtreemfs/dirconfig.properties
100640

100000は、/usr/include/sys/stat.hによればregular fileを表す模様。

#define S_IFREG  0100000                /* regular */

gmake cleanしてgmakeしたらundefined reference

[ 81%] Linking CXX executable mount.xtreemfs
libxtreemfs.a(RPC.pb.cc.o): In function `xtreemfs::pbrpc::protobuf_AssignDesc_pbrpc_2fRPC_2eproto()':
/root/xtreemfs/cpp/generated/pbrpc/RPC.pb.cc:(.text+0x86): undefined reference to `google::protobuf::DescriptorPool::FindFileByName(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&) const'

うまくいったと思って整理したらこれだよ。
静的ライブラリとしてビルドしたprotobufとXtreemFS本体で、使っているC++コンパイラが違っているために起こっているみたい。
protobufはgccを優先し、XtreemFSはcmakeがclang++を優先している。(試行錯誤時、gccがない状態でprotobufがconfigureされたせいで、1回目は成功していたようだ。)
gmakeの引数にCC=cc CXX=c++というおまじないのような指定を追加して対応。

DISPLIOで遊んでみる

$
0
0

すっかり忘れていたDISPLIOが届いたので、軽く遊んでみた。

電子ペーパーは初めてだったので、まずこのあたりの感想が出る。

  • バックライトがないのに見やすいのが驚き。
  • 表示の切り替えが遅い。液晶の応答速度というレベルではなくて、秒オーダーで消して再描画しているのが見える。砂鉄でお絵かきするおもちゃみたい。
  • 解像度はやや低め。

DISPLIO本体についてはこんな感じ。

  • 電池の持ちがすばらしい。表示の更新間隔にも依存するけれど、(サイトの表記を信じるなら)数ヶ月というのはすごい。
  • ちょっと分厚い。持ち運ぶモノではないし、置いて使うことや安定性を考えれば特に気にはならない。
  • モノは綺麗。下側だけちょっと加工が甘い(型から切り離した跡?)ところは気になる。
  • つつくと更新してくれるはずだけど、つつき方が悪いのか感度が悪いのか、なかなか言うことを聞かない。
  • Web画面上で部品をおいてJavaScriptでちょいちょいとコードを書けばアプリが出来上がる。楽ちん。

開発まわりはまだあまり手をつけてないけど、2時間ほど触った感じだとこんなところ。

  • 楽ちんなんだけど、APIの資料が見つからなくてちょっと辛い。Listってどう使うのさ……。
  • 解像度の都合もあって、細かい文字は見えない。9pt(下のお試しモノがそう)だと、数字がなんとか認識できるくらい。フォント設定でもう少しナントカなるかも?
  • 画像が使えるので、うまくアイコンを活用して文字を減らす工夫が必要かな。

これは開発用画面での表示なので、デバイスでの表示はもっと荒い。
ちなみに表示しているのは我が家のIDSからルータのファイアウォールに送っている情報。
20160508_displio

XtreemFSをFreeBSDで動かす(1)

$
0
0

昨日の続きをちょっとだけ。
成果物は例によってGitHubにて。(@f22dea0)

  • インストール先を/から/usr/localに変更。
    /etc/xos/usr/local/etc/xosに。しかし/var/lib/xtreemfsはそのまんま。
  • Linux init.d scriptをFreeBSD rc.d scriptに変換。/etc/rc.confに以下の記述が必要。
    xstreemfs_dir_enable="YES"
    xstreemfs_mrc_enable="YES"
    xstreemfs_osd_enable="YES"
    

とりあえず起動はした。
http://<hostname>:30636/ でMRC、http://<hostname>:30638でDIR、http://<hostname>:30640でOSDの状態が無事見えたので、そこそこ動いてはいるのだろう。
明日以降はfuseでマウントして遊んでみる予定。

XtreemFSをFreeBSDで動かす(2)

$
0
0

続き。あっさり動いてがっかりした。

まず作成。FreeBSDでmkfsはないな……。newfs_xtreemfsにしたい。

# mkfs.xtreemfs pbrpc://localhost/test
Trying to create the volume: pbrpc://localhost/test

Using options:
  Owner:                        root
  Owning group:                 wheel
  Mode:                         777
  Access Control Policy:        POSIX
  Quota:                        0

  Default striping policy:              RAID0
  Default stripe size (object size):    128
  Default stripe width (# OSDs):        1

Successfully created volume "test" at MRC: pbrpc://localhost/test

マウント。こっちもmount.xtreemfsじゃなくてmount_xtreemfs

# mkdir /mnt/xtfstest
# mount.xtreemfs pbrpc://localhost/test /mnt/xtfstest
# ls -al /mnt/xtfstest
total 9
drwxrwxrwx   1 root  wheel   0 Jan  1  1970 .
drwxr-xr-x  17 root  wheel  23 May  9 02:49 ..

mountfstabでやりたいなら、mount -t xtreemfs -o mountprog=mount.xtreemfs pbrpc://localhost/test /mnt/xtfstestのように書ける。(-tは完全に飾り)

書き込みテスト。遅いのは仮想マシンのVMDKがSMB/CIFS越しだから。きっと。

# dd if=/dev/urandom of=/mnt/xtfstest/test.dat bs=65536 count=1024
1024+0 records in
1024+0 records out
67108864 bytes transferred in 39.693073 secs (1690695 bytes/sec)

OSDのWeb画面表示。どこにもFreeBSDって出ないから少し寂しい。
20160509_xtreemfs_osd

最後にxtfsutil。
これは失敗。mountの出力がどうのと言ってるから、きっとmountコマンドの結果を分析しているところがあるのだろう。

# xtfsutil test.dat
xtfsutil failed: No matching mounted XtreemFS volume found in 'mount' output for path: /mnt/xtfstest/test.dat

また明日。

XtreemFSをFreeBSDで動かす(3)

$
0
0

FreeBSD向けのバグもいろいろ直したので、今回は冗長構成にしてみる。

packaging/freebsd/make-package.shでpkg用パッケージも作れるようにしておいた。
GlusterFSのときに作ったものを流用して作ったけど、manifestの書き方がどうも間違ってる気がする。けど今のところ動いてるので放っておく。

あ、xtfsutilが動かないバグはまだ直してないよ。

MRC, DIR, OSDをそれぞれ冗長構成にしてみる。
テスト用ノードは3台で、xtfs1/2/3。

まず/etc/hostsに以下を書いておく。これは(冗長構成とかになってれば)DNS任せでも(きっと)いいところ。

10.0.0.1 xtfs1
10.0.0.2 xtfs2
10.0.0.3 xtfs3

次に設定ファイルを変更していく。

  • /usr/local/etc/xos/xtreemfs/dirconfig.properties:
    babudb.plugin.0 = /usr/local/etc/xos/xtreemfs/server-repl-plugin/dir.properties
    

    コメントアウトをはずす。

  • /usr/local/etc/xos/xtreemfs/mrcconfig.properties:
    # Directory Service endpoint
    #dir_service.host = localhost
    #dir_service.port = 32638
    dir_service.host = xtfs1
    dir_service.port = 32638
    dir_service1.host = xtfs2
    dir_service1.port = 32638
    dir_service2.host = xtfs3
    dir_service2.port = 32638
    

    dir_servicelocalhostから変更して、dir_service1dir_service2を追加。

    #babudb.sync = ASYNC
    babudb.sync = FDATASYNC
    

    ASYNCFDATASYNCにする。

    babudb.plugin.0 = /usr/local/etc/xos/xtreemfs/server-repl-plugin/mrc.properties
    

    コメントアウトをはずす。

  • /usr/local/etc/xos/xtreemfs/osdconfig.properties
    mrcconfig.propertiesと同様にしてdir_serviceの定義を変更・追加する。
  • /usr/local/etc/xos/xtreemfs/server-repl-plugin/dir.properties
    babudb.repl.participantsを変更する。
    babudb.repl.participant.0 = xtfs1
    babudb.repl.participant.0.port = 35678
    babudb.repl.participant.1 = xtfs2
    babudb.repl.participant.1.port = 35678
    babudb.repl.participant.2 = xtfs3
    babudb.repl.participant.2.port = 35678
    
  • /usr/local/etc/xos/xtreemfs/server-repl-plugin/mrc.properties
    dir.propertiesと同様にしてbabudb.repl.participantsを変更する。

あとはサービスを(再)起動してあげればいい。

無事つながればhttp://10.0.0.1:30638でDIRの状態を見たときにほかのノードが見えるはず。
Service Registryに3台分のMRC/DIR/OSD、つまり9個のエントリが見えていればOK。

ちなみにstatus_page_urlがlocalhostになるけど原因不明。
きっとまだどこか変えるべきところが残っている……のかも。


XtreemFSをFreeBSDで動かす(4)

$
0
0

やっとxtfsutilを直した。最新はea0bf85

次はレプリケーションのテストか耐障害性のテストをしたい。
けどそろそろMacBookにVM 3台乗せてテストするのは辛くなってきたな……。

# xtfsutil test
Path (on volume)     /test
XtreemFS file Id     ab63c953-80a7-42fb-86b1-c97afbcbbbbb:2
XtreemFS URL         pbrpc://xtfs1:32638/test/test
Owner                root
Group                wheel
Type                 file
Replication policy   none (not replicated)
XLoc version         0
Replicas:
  Replica 1
     Striping policy     STRIPING_POLICY_RAID0 / 1 / 128kB
     OSD 1               b2b67461-1ce7-11e6-b639-000c2974491c (10.0.0.1:32640)

ここから先は直したものメモ。

No matching mounted XtreemFS volume found

# xtfsutil test
xtfsutil failed: No matching mounted XtreemFS volume found in 'mount' output for path: /mnt/xtfstest

mountの結果から/dev/fuse[0-9]の正規表現に一致するようなデバイスを探しているけど、FreeBSD 10.1では/dev/fuseであって数字が付かない。昔は付いてたのかな。
正規表現をいじって対応。かんたん。

This is a known issue of FUSE for FreeBSD 0.4.4

# xtfsutil test
xtfsutil read back the same text which was written into the pseudo control file: {"operation":"getattr","path":"/test"}

This means a file content cache prevents xtfsutil from working correctly.
This is a known issue of FUSE for FreeBSD 0.4.4.
1 of 1 operation(s) failed.

xctlという制御用ファイルにJSONを書いてcloseして、すぐにまたJSONを読む処理で失敗しているらしい。
fuse daemonが返すはずの結果ではなくて、直前に自分が書いたものが読めるらしく、怒る。

cacheされて困るならO_DIRECTでも付ければいいのに、と思って付けたら直った。

XtreemFSをFreeBSDで動かす(5) 書き込み速度測定

$
0
0

またESXi用に使おうと思って、とりあえず書き込み速度を計ってみた。

結果、6.8MB/sという非常に悲しい数字をもらった。

ちなみに、rc.confの記述内容がxstreemfs_*_enableとかになってたので、xtreemfs_*_enable修正している

構成はこんな感じ。

* ストレージはiSCSI越しのNAS(NETGEAR ReadyNAS 104)
* DIR/MRC/OSDすべてを同じノード上に配置したシングル構成。(number of replica=1)
* iSCSIからレイテンシへの影響を軽減するため、 システム用SSDをZILに使用したZFSをOSDのデータ領域に使用。

20160528_xtfs_testenv

# mkfs.xtreemfs pbrpc://localhost/test
# mkdir /mnt/xtfstest
# mount.xtreemfs pbrpc://localhost/test /mnt/xtfstest
# dd if=/dev/zero of=/mnt/xtfstest/test bs=65536 count=65536

遅いのでtopを見てみる。

last pid:   974;  load averages:  2.24,  1.42,  0.93                                    up 0+00:19:31  22:07:32
45 processes:  3 running, 42 sleeping
CPU: 49.6% user,  0.0% nice, 48.4% system,  1.2% interrupt,  0.8% idle
Mem: 267M Active, 279M Inact, 808M Wired, 815M Buf, 6477M Free
ARC: 381M Total, 28M MFU, 328M MRU, 20M Anon, 894K Header, 4589K Other                                          
Swap: 4096M Total, 4096M Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE   C   TIME    WCPU COMMAND
  658 xtreemfs     26  20    0  3507M   112M RUN     1  19:12  94.97% java
  928 xtreemfs     35  20    0  3506M   114M uwait   1   0:43  52.69% java                                      
  941 root         11  25    0   120M 15856K RUN     0   0:32  44.68% mount.xtreemfs
  966 root          1  21    0 12344K  1920K fu_ans  1   0:02   2.59% dd

そして結果。

65536+0 records in
65536+0 records out
4294967296 bytes transferred in 697.924677 secs (6153912 bytes/sec)

6MB/s。48Mbps……。

ちなみに、OSD領域に直接書いてみると、

# dd if=/dev/zero of=/var/lib/xtreemfs/objs/test bs=65536 count=65536
65536+0 records in
65536+0 records out
4294967296 bytes transferred in 112.445004 secs (38196159 bytes/sec)

38.2MB/s。308Mbpsくらい。
つまりXtreemFSが遅い。きっと、主にCPU負荷で。

CPU: Intel(R) Celeron(R) 3205U @ 1.50GHz (1496.57-MHz K8-class CPU)

ちょっとCPUをケチりすぎたかな……。

おまけ その1

新しくインストールした直後、作ったパッケージを持っていったら……

# pkg install xtreemfs-1.5.1.txz
(中略)
[1/1] Extracting xtreemfs-1.5.1:   0%Child process pid=99734 terminated abnormally: Segmentation fault

ひどい。

仕方がないので手動インストールした。

# cd /
# tar -jxf /root/xtreemfs/packaging/freebsd/package/xtreemfs-1.5.1.txz /usr
# /usr/local/etc/xos/xtreemfs/postinstall_setup.sh

おまけ その2

将来ノードとして稼動させる用にマシンを一台調達したので、いろいろ設定してみていた。

ZFSがマウントされる前に起動して、システムボリュームをOSD扱いされる事故の防止処置。

# mkdir -p /var/lib/xtreemfs/objs
# chflags schg /var/lib/xtreemfs/objs

サービス起動順の制御。
zfsがiscsid/iscsictlの後になればいいように見えるが、iscsictlが接続完了を待ってくれないので結局待ち処理を書かないとダメ。
長くなったのでGistに置いた。(zfs-iscsi)

XtreemFSをFreeBSDで動かす(6) 書き込み速度の改善

$
0
0

どうもFreeBSD+OpenJDKのバグで、Selector.select(int)がタイムアウト前に返ってくる模様。
このせいでMRCやOSDのあるスレッドが空回りしてCPUを食いつぶすことがある。(よくある)

これを直してやって、7.4MB/sまで改善した。(前回は6MB/s)

# dd if=/dev/zero of=/mnt/xtfstest/test bs=65536 count=4096
4096+0 records in
4096+0 records out
268435456 bytes transferred in 36.120514 secs (7431662 bytes/sec)

2016/05/31追記:

上記はiSCSI+ZFS+SSD ZILでの測定結果。
気になって夜も眠れないので、UFS on SSDにOSDを置いて計ってみたら、6.7MB/sになった。
遅くなってるけど、きっと測定誤差だと信じたい。(だとすると改善も誤差だけど……)

# dd if=/dev/zero of=/mnt/xtfstest/test bs=65536 count=4096
4096+0 records in
4096+0 records out
268435456 bytes transferred in 39.965025 secs (6716759 bytes/sec)

正直なところ心が折れそうだけど、GlusterFSは(xattrが必要だから)zfsのzilで加速、とかができないし、微妙に柔軟性が足りない気がするのでもう少しがんばりたい。

過去に一度対策を入れているが、うまく動かないことがある、ということでコメントアウトされていたので、ちょっと手を入れてみた

ただ、コミットではselectが空回りしたら25msだけsleepする動作(もともとそう書いてあったんだよ!)をするので、最悪の場合どこかで25msのレイテンシを稼いでしまう。
このレイテンシが問題になるようなら、このスレッドはselectしながら定期的にタイマー(自称poorman’s timer)をチェックする動作をしているので、selectorをpipeか何かで定期的(現在のselect timeout時間ごと)に起こすようにしてやれば、selectorのtimeoutなしにできるハズ。

今のところスループットに悪さはしていないようなので、いったん放置。

GlusterFSをESXiから使う(2)

$
0
0

XtreemFSに見切りをつけてGlusterFSに戻ってきた。

前回はVMware ESXiからつなぐとデータストアを表示しても何も表示されないままとなってそのうち切断されていたので、ここを調査&修正。
修正版はGitHubにcommit/push済み。(4853f4d)

一応これで直ってはいるけれど、コミットログ(の怪しい英語)にある通り、seekdirをreaddirでエミュレートするという暴挙に走っているのでそのうち動かなくなる可能性大。というかUFSじゃないときっと動かない。
そもそもopendirしてtelldirが返したものを、あとでopendirしなおしてseekdirするのが悪いと思う。

ちなみにXtreemFSで困ったパフォーマンスについては、概算で10MB/s程度出てる。
あっちよりマシだけど、実用にはまだちょっと遅い。
とはいえ、まだまだチューニングをまったくしていないし、ローカルのSSD相手に実行すれば数字が改善するあたり、まだ見込みはありそう。

ちなみにXtreemFSはもともとパフォーマンスはあまりよくない模様。この辺が参考になった。

Performance comparison of Distributed File Systems on 1Gbit networks

ここに出てくるFhgFSはBeeGFSになっている模様。こいつもそのうち試してみたい。(FreeBSDにportingできれば)

iscsi initiator+gjournalが固まる

$
0
0

glusterfs環境のパフォーマンステストのため、iscsi initiatorでNASに接続している/dev/da*に、gjournal labelでローカルなSSDをjournalとしてくっつけた。
newfsはうまくいってmountgluster volume createしてgluster volume start、と思ったら固まってしまった。

いろいろ条件を変えて速度測定したかったのになぁ……。

# iscsictl -A -a
# gjournal label /dev/da1 /dev/gpt/zil
# newfs /dev/da1.journal
# mount /dev/da1.journal /mnt/test
# gluster volume create test 10.0.0.1:/mnt/test/brick1
# gluster volume start test

最後で固まる。
不思議に思ってgstatしてみると、/dev/da1がキューに何か1個抱えたまま固まっている。
なんとここで、dd if=/dev/da1 of=/dev/null count=1すると直る。
でも少しアクセスしたりするとまた止まる。

いろいろ試してみると、この現象はglusterfsを通さなくても起きる。最短だと、以下の通り。
count=1くらいだと起きないけど、まとまったアクセスをすると詰まる模様。

# iscsictl -A -a
# gjournal label /dev/da1 /dev/gpt/zil
# dd if=/dev/da1.journal of=/dev/null

つまり、iscsi initiatorとgjournalは組み合わせるな、ということ??
単純にiscsi initiatorかgjournalのバグな気もするけど。いや、NAS側のiscsi targetのバグという線もあるか。
いずれにしてもめんどくさい。

Viewing all 62 articles
Browse latest View live