os:linux:centos:techmemo
CentOS向け技術メモ
CentOS で NFS で nobody
CentOSを利用してて、何かのはずみでNFSでmountしたDiskに置かれているファイルのOwnerがnobodyになる問題の解決策
localhost nfsidmap[xxxxx]: nss_getpwnam: name 'foo@localdomain' does not map into domain 'bar.baz'
こんなlogが出た場合、以下が考えられる。
- NISがおかしい
- NISなんか使ってないが、resolv.confなどでなんらかの設定をぶち込んだ
- NISをやめた
今回は、2と3で引っかかった
こういうときには、
- NIS関連の設定をなくす
- nfsidmap -v -c を実行し、cacheをクリアする
- /etc/idmapd.confを修正する
vi /etc/idmapd.conf ========== Domain = localdomain ==========
- mount -o remount /path/to/mountedFS
結構はまった。
ちょっとFilesystemの試験をしてみた
試験環境は XenServer 6.2上のFVMのCentOS 7。 vCPU x1, Mem 1024M, HDD 10G(boot)+1G(試験用)
試験内容は
- 試験用の1GのDiskに、下記のscript-1で出来る限りのファイル/Directoryを作成する
- そのファイルシステムに対し、ls -Rを実行してかかった時間を計測。また、作成できたファイル数を数える
- 試験用の1GのDiskに、下記のscript-2でファイルをDirectoryを作成する。
- 作成時間、ls -Rにかかる時間、消去時間を計測
今回は、簡易な試験なので、複数回実施するような事はしない
えー、決定的ミスが発見されたため、以下書き直しました。
- 元々の試験では、Kernel内のCacheの効果で、Cacheの性能しか見えなかった
試験用script
まず、File作成制限を測定する為のScript
- script1
#! /bin/sh for i in `seq 1 33000`; do mkdir $i for j in `seq 1 33000`; do touch $i/$j done done
- script2
#!/bin/bash set_START() { START=`cat /proc/uptime | cut -d ' ' -f1` } get_ELAPS() { END=`cat /proc/uptime | cut -d ' ' -f1` ELAPS=`echo "scale=7; $END - $START" | bc` } make_dir() { echo "Gen $m Dirs" sync ; echo 3 > /proc/sys/vm/drop_caches set_START for i in `seq 1 $1`; do mkdir $i done get_ELAPS echo "make $1 dirs: $ELAPS sec" } touch_file() { sync ; echo 3 > /proc/sys/vm/drop_caches set_START for i in `seq 1 $2`; do touch $1/$i done get_ELAPS echo "touch $2 file: $ELAPS sec" } access_file() { sync ; echo 3 > /proc/sys/vm/drop_caches set_START ls -R > /dev/null get_ELAPS echo "access all files: $ELAPS sec" } remove_file() { sync ; echo 3 > /proc/sys/vm/drop_caches set_START rm -rf * get_ELAPS echo "remove all files: $ELAPS sec" } mkdir mnt for k in ext4 xfs btrfs; do /sbin/mkfs.$k -F /dev/xvdb mount /dev/xvdb mnt cd mnt echo "Filesystem: $k start" for m in 16384 24576 ; do make_dir $m for n in 1 5 9 13; do touch_file $n 8192 done access_file; remove_file make_dir $m for n in 1 13; do touch_file $n 16384 done access_file; remove_file make_dir $m for n in 1 ; do touch_file $n 32768 done access_file; remove_file done cd .. echo "Filesystem: $k end" umount mnt done
試験結果
今回の試験は、XenServer上のVMで実施したため、以下の隠しパラメータがあります。
- DiskはRemoteにあるFreeNASで供給したiSCSI Diskを使用している
- つまり、伝送遅延やSCSIコマンド解析等による性能劣化、FreeNASのRAID1構成による性能劣化が(暗黙に)含まれている
- XenServer上では、他のVMも動いているため、CPU時間を占有できた訳ではない
- が、XenServer自体はすかすかで、負荷も低い為、大きな影響は無かったはず
script1 試験結果
FS | Generate | memo | |
---|---|---|---|
Dir | File | ||
ext2 | 2 | 33000*1+32523*1 =65523 | 容量は空いているが、Diskfullになる |
ext3 | 2 | 33000*1+32523*1 =65523 | 容量は空いているが、Diskfullになる |
ext4 | 2 | 33000*1+32523*1 =65523 | 容量は空いているが、Diskfullになる |
xfs | 111 | 107*33000+32128+11+11+0 =3563150 | 容量を使い切る |
btrfs | 33 | 33000*33+20358*1 =1109358 | 容量を使い切る |
これを見ると、ファイルが増えた場合、xfsとbtrfsは空き領域を使ってどんどんinodeを作って行く(btrfsに関してはそもそもinodeなのか?という疑問があるが)ように見える。 対して、extfs系は、UNIX系のFSの伝統に従って、inodeの数を決めうちしているように見える。
ext2fs> df /dev/xvdb 999320 3904 926604 1% /root/ext4 ext3fs> df /dev/xvdb 999320 3904 926604 1% /root/ext4 ext4fs> df /dev/xvdb 999320 3904 926604 1% /root/ext4 xfs> df /dev/xvdb 1038336 1038192 144 100% /root/xfs btrfs> df /dev/xvdb 1048576 976320 8192 100% /root/btrfs
script2 試験結果
ext4 filesystem | |||||||
---|---|---|---|---|---|---|---|
Create 16384 Directories | Create 24576 Directories | ||||||
File Create | 8192 x4 | 16384 x2 | 32768 x1 | 8192 x4 | 16384 x2 | 32768 x1 | |
make dirs | 18.00 sec | 18.62 sec | 18.51 sec | 28.50 sec | 28.48 sec | 28.57 sec | |
create file | 6.56 sec | 13.30 sec | 27.70 sec | 6.90 sec | 13.87 sec | 27.86 sec | |
create file | 6.56 sec | 13.34 sec | 6.87 sec | 13.88 sec | |||
create file | 6.55 sec | 6.92 sec | |||||
create file | 6.58 sec | 6.89 sec | |||||
create total | 26.25 sec | 26.64 sec | 27.70 sec | 27.58 sec | 27.75 sec | 27.86 sec | |
ls -R | 7.44 sec | 6.79 sec | 7.08 sec | 13.45 sec | 10.52 sec | 10.45 sec | |
rm -rf | 10.43 sec | 8.80 sec | 10.77 sec | 12.32 sec | 11.48 sec | 12.08 sec |
xfs filesystem | |||||||
---|---|---|---|---|---|---|---|
Create 16384 Directories | Create 24576 Directories | ||||||
File Create | 8192 x4 | 16384 x2 | 32768 x1 | 8192 x4 | 16384 x2 | 32768 x1 | |
make dirs | 18.85 sec | 18.99 sec | 19.10 sec | 28.51 sec | 28.47 sec | 28.93 sec | |
create file | 6.89 sec | 13.80 sec | 27.95 sec | 7.04 sec | 13.88 sec | 27.76 sec | |
create file | 6.89 sec | 13.83 sec | 6.92 sec | 13.83 sec | |||
create file | 6.88 sec | 6.89 sec | |||||
create file | 6.91 sec | 6.96 sec | |||||
create total | 27.57 sec | 27.63 sec | 27.95 sec | 27.81 sec | 27.71 sec | 27.76 sec | |
ls -R | 7.28 sec | 7.30 sec | 7.59 sec | 10.47 sec | 9.27 sec | 10.27 sec | |
rm -rf | 7.88 sec | 8.71 sec | 7.95 sec | 11.02 sec | 11.64 sec | 11.84 sec |
btrfs filesystem | |||||||
---|---|---|---|---|---|---|---|
Create 16384 Directories | Create 24576 Directories | ||||||
File Create | 8192 x4 | 16384 x2 | 32768 x1 | 8192 x4 | 16384 x2 | 32768 x1 | |
make dirs | 19.22 sec | 19.15 sec | 19.37 sec | 28.97 sec | 28.88 sec | 28.97 sec | |
create file | 6.97 sec | 13.94 sec | 28.07 sec | 6.97 sec | 13.97 sec | 28.05 sec | |
create file | 6.97 sec | 13.94 sec | 7.03 sec | 13.93 sec | |||
create file | 6.96 sec | 7.01 sec | |||||
create file | 6.95 sec | 7.05 sec | |||||
create total | 27.75 sec | 27.88 sec | 28.07 sec | 28.06 sec | 27.90 sec | 28.05 sec | |
ls -R | 7.75 sec | 6.58 sec | 7.22 sec | 10.47 sec | 11.21 sec | 10.16 sec | |
rm -rf | 7.93 sec | 8.42 sec | 9.93 sec | 12.66 sec | 12.98 sec | 11.69 sec |
個人的結論
試験結果を見る限り、大きな有意差はないと考えられる。 但し、System時間とUser時間を取れていないので、書き込みの転送速度がBottle Neckになっている可能性は否定できない。
まぁ、この程度の試験では有為差がでなかったので、CentOSで使うFSとしては「defaultの」xfsでいいんじゃないか?
以下細かいTips
- CentOSで、古いカーネルを削除したい場合。
今動いているカーネルと1世代前のカーネルは残ります。(デフォルト設定)# package-cleanup --oldkernels
- 現在のkernelと同じバージョンのkernel-develをインストールするには、次のようにする。
# yum install kernel-devel-`uname -r`
os/linux/centos/techmemo.txt · 最終更新: 2017/05/25 18:52 by 127.0.0.1