前回のエントリを読みながらチューニングを施した。全然違う部分で改善ができたのでそのレポート。例によってAS-ISです。
やってみて、chinachuサーバ+NASのPCが割とボトルネックになっていたということに驚いた。RAIDのチューニングはかなり重要という良い気付きになった。
rasPIのチューニング
ウチのrasPIはarch上にkodi(xbmc)を構築している。自分が導入した当時のバージョンではhavegedが動作していてメモリを10MB程度食っていた。乱数ソースに hwrng が使えるので haveged は停止できる。
RNGD_OPTS="-o /dev/random -r /dev/hwrng" # urandom から hwrng に変更
list: /etc/conf.d/rngd
参考: Raspberry Pi – ArchWiki section 11
/var/logをtmpfsにする。
# # /etc/fstab: static file system information # # /dev/mmcblk0p1 /boot vfat defaults 0 0 tmpfs /var/log tmpfs defaults 0 0 mynas.local:/ /mnt/nas nfs nfsvers=3,nolock,proto=udp,intr,noatime,async,noauto,x-systemd.automount 0 0
list: /etc/fstab
参考: Maximizing performance – ArchWiki section 5
RAID チューニング
先読みブロックをデカくする。再生開始直後の再生ストップがなくなった感がある。以下例の65536では 512バイトセクタの数なので32MBの先読みが実行される。
# blockdev --setra 65536 /dev/md0
shell command rc.localに書くのも良いかもしれない。
参考: blockdev(8) – Linux manual page
RAIDの書き込み時のパフォーマンスを改善するため、stripe_cache_sizeを大きくする。起動時に自動反映させる場合はrc.localに以下スニペットを貼る。今日だけ欲しいならスニペットを実行すればその直後から反映される。ウチのホストはメモリを4GB積んでいるので支障無かったが、メモリの搭載が小さいホストにおいては注意が必要。メモリ使用見込は 4(kernelページサイズ|KB) * (物理ディスク本数) * (stripe_cache_size|KB) の式で計算できる。
2番目の参考リンクではRAID再構築を行う場合のチューニング方法が紹介されている。speed_limit_min,maxの設定を広くしておくと(例えば500から1000000など)、m2tsを再生しながらでも効率よくリビルドができる。ウチの環境ではminを2000などにしていると転送が間に合わなかった。なおデフォルトではmaxが小さいためリビルドの転送速度がキャップされてしまう。必ずmaxの数値は上げておく。たまたま今日2TB*3のraidに1本追加(grow)したのでmdstatを監視していると、チューニングをしない場合にはリビルドの完了まで見込40時間程度だったが、15時間になった。queue_depthを1にするチューニングについては体感できる改善はなかった。故障からのリビルドにおいてはbitmapオプションも使うこと。
for a in /sys/block/md?; do echo 8192 > $a/md/stripe_cache_size done
list: /etc/rc.local
# sysctl -w dev.raid.speed_limit_max=1000000 # sysctl -w dev.raid.speed_limit_min=500
shell command (もしくは /etc/sysctl.d/ に同様の設定を書く → sysctl -a | grep speed_limit > /etc/sysctl.d/99_myraid_tuning.conf)
参考: Linux RAID mdraid “stripe_cache_size” vs. transfer rate, 5 Tips To Speed Up Linux Software Raid Rebuilding And Re-syncing
コメントを残す