スワップ領域を設定している理由
現在、我が家でサーバーとして稼働している Raspberry Pi は、3B と 3B+。実メモリーは、どちらも 1GB。これをワークステーションとして使う場合には、スワップ領域の設定によって快適度が大きく変わるということで、そのスワップ領域を設けるためにハードディスクを使うのもお勧めなんですが、サーバーとして使っている場合は、通常だとスワップが発生するような多量のメモリーを必要とするケースは少ないし、そもそもスワップが発生しているようだと効率が悪いので、本来なら、設定しなくても運用可能なんです。
じゃ、何で設定しているかといえば、1 つは、通常運用中にスワップ領域を使うことはなくても、セットアップ作業中、特に、将来的にパッケージをソースからビルドするような状況が発生するような状況になると、使われる可能性があるということ。もう 1 つは、今回のケースなんですが、スワップの発生を検知することによって、システム設定やハードウェア構成の見直しの切っ掛けになるということからです。
なので、ハードディスクを接続しているサーバーはもちろんなんですが、SD カードしか使っていないサーバーでも、その SD カード上にスワップ領域を設定しています。通常は使われることがないという前提であって、使わる状況が続くと SD カードの寿命の方が心配になるので、原因を突き止めて対策をとる必要があります。
原因は、バックアップスクリプトだった。
冷静に考えればそうでした。ただ、結構、悩みました。
- 再起動すると、使われているスワップ領域は 0 になる。
- そのまま相当の時間、放置しても、使われている領域は 0 のまま。
- ある時、チェックすると、複数のサーバーで一斉にスワップが発生している。
みたいな感じですね。
ま、原因がバックアップスクリプトっぽかったので、検証テストです。テストマシン（Raspberry Pi 3B+）に、Raspbian Buster（2019/07/10 版を使用）を入れ、同様のバックアップスクリプトをセットして、テストしました。
テスト結果
バックアップスクリプト実行前
pi@raspberrypi-test:/etc/utility$ free -w -b
total used free shared buffers cache available
Mem: 971063296 47943680 852860928 6447104 10981376 59277312 864923648
Swap: 8589930496 0 8589930496
バックアップスクリプト 1 回終了後
pi@raspberrypi-test:/etc/utility$ free -w -b
total used free shared buffers cache available
Mem: 971063296 51228672 336654336 3670016 538349568 44830720 862654464
Swap: 8589930496 3932160 8585998336
バックアップスクリプト 2 回終了後
pi@raspberrypi-test:/etc/utility$ free -w -b
total used free shared buffers cache available
Mem: 971063296 50921472 336588800 2146304 545124352 38428672 864448512
Swap: 8589930496 5505024 8584425472
バックアップスクリプト 3 回終了後
pi@raspberrypi-test:/etc/utility$ free -w -b
total used free shared buffers cache available
Mem: 971063296 48869376 338690048 1466368 547876864 35627008 867176448
Swap: 8589930496 6029312 8583901184
バックアップスクリプト 4 回終了後
pi@raspberrypi-test:/etc/utility$ free -w -b
total used free shared buffers cache available
Mem: 971063296 49745920 336617472 1220608 550473728 34226176 866549760
Swap: 8589930496 6815744 8583114752
バックアップスクリプト 5 回終了後
pi@raspberrypi-test:/etc/utility$ free -w -b
total used free shared buffers cache available
Mem: 971063296 49590272 338382848 958464 549117952 33972224 866934784
Swap: 8589930496 7077888 8582852608
バックアップスクリプト 10 回終了後
pi@raspberrypi-test:/etc/utility$ free -w -b
total used free shared buffers cache available
Mem: 971063296 48918528 336146432 966656 552386560 33611776 867581952
Swap: 8589930496 8912896 8581017600
もしかして、スワップが発生するのは、システム起動時などに使って、その後、アクセスのないメモリー領域が実メモリー上に残っている間のみ、って可能性もあるので、試しに 10 回やってみたのですが、結果、回を重ねても、スワップ使用量は少しずつ増えていく感じですね。
見てわかる通りなんですが、実メモリーに数百 MB という単位で余りがある状態であっても、数 MB って単位でスワップさせてます。このあたりが、システムが持つ最適化ロジックなんでしょうけど、これはどう考えても、ハードディスクなどの書き換えに特に制限が必要ないデバイスを前提にしているとしか、思えないですよね。このまま使っていくと、バックアップを取る度に、SD カードを劣化させていくということになりかねない状態です。
対策
システム的には、swappiness なんていうパラメータもあるのですが、いろいろ調べると、何か違うんですよね。根本的に、スワップさせるかどうかの判断が、アクセス速度の最適化を基準にしているので、書き込みに伴って発生するコスト（SD カードの劣化）を反映していないところにあるのではないかと思えます。
ここで調べたのは、テスト用のマシーンなので、実際のサーバーでは、もう少しメモリー使用量が多いとはいうものの、数 MB をスワップして空きを確保しなければならないほど差し迫った状態には遠く及ばず。いっそのこと、通常運用時は、スワップ領域の使用をやめてしまうのも、手かな … と。まぁ、代償として、メモリーが足らなくなったら、即、システムフリーズですが。… 十分な安定稼働を確認してからですね。特に、バックアップスクリプト以外に、メモリースワップの原因になるものが存在しないのかどうかは、まだ、確認が取れていない状態ですから。
バックアップスクリプトの内容
こんなこと書いていて、「そもそも、バックアップスクリプトで何やってんだよ」みたいなツッコミがありますよね。nfs でマウントしたディレクトリに、tar と dump でバックアップしているだけなんですが。こういった古典的なコマンドであっても、カーネルは現在のシステムに搭載されているリソースを見て、最適化を試みるってことなんですね。
#!/bin/bash
readonly SOURCE_TAR='/boot'
readonly SOURCE_DUMP='/dev/mmcblk0p3'
readonly TARGET_DIR=archive.protected.fitfat.open.ad.jp:share/backups/$(hostname)
readonly MOUNT_DIR=/mnt
readonly DATE_TIME=$(date -u '+%Y-%m-%d-%H-%M-%S-%N')
readonly ORIGINAL_UMASK=$(umask)
if ! mount -t nfs $TARGET_DIR $MOUNT_DIR
then
exit
fi
umask 0077
for _source in $SOURCE_TAR
do
tar -vcpzf $MOUNT_DIR/$DATE_TIME.${_source//'/'/_}.tar.gz $_source
done
for _source in $SOURCE_DUMP
do
dump -vf $MOUNT_DIR/$DATE_TIME.${_source//'/'/_}.dump $_source
done
umask $ORIGINAL_UMASK
umount $MOUNT_DIR
コメント
コメントを投稿