はじめに
バージョン管理システムをAWSのEC2（Amazon Linux 2023）で運用しています。
3回ほどサーバがハングアップしてしまったときの話です。
サーバ構成
メモリはあまり使わないはずなので、（安いやつで運用しようと思って）
以下で運用していました。
- OS：Amazon Linux 2023
- インスタンスタイプ：t2.micro（1vCPU、メモリ1GB）
タイムライン
インスタンスの増強
安くてスペックが上がることに気付いて、
インスタンスタイプ：t3a.micro（2vCPU、メモリ1GB）
に変更しました。
１回目のハングアップ
インスタンスタイプ変更後、2週間ほどは問題なかったですが、
バージョン管理システムが動作していないという報告を突然受けて確認すると以下のような状況でした。
- バージョン管理システムは「408 Request Timeout」
- CPUの使用率50％（EC2のコンソール画面での確認）
- サーバにSSHで接続できず
どうにもならないので、EC2のコンソール画面で停止→起動を行い、ひとまず復旧しました。
２回目のハングアップ
数日後、2回目のハングアップが発生しました。
原因調査のために、 以下のスクリプトを10分おきで実行するようにしました。
※psコマンドでCPU使用率、メモリ使用率が高いプロセスをテキストファイルに出力させる
#!/bin/sh
LOGDIR=/home/ec2-user/ps/`date +%Y%m%d`/
CPULOG=${LOGDIR}`date +%Y%m%d%H%M%S`_cpu.log
MEMLOG=${LOGDIR}`date +%Y%m%d%H%M%S`_mem.log
[ ! -e ${LOGDIR} ] && mkdir -p ${LOGDIR}
date >> ${CPULOG}
ps --no-header -e aux | sort -r -k 3 | head -n 30 >> ${CPULOG}
echo "\n" >> ${CPULOG}
date >> ${MEMLOG}
ps --no-header -e aux | sort -r -k 4 | head -n 30 >> ${MEMLOG}
echo "\n" >> ${MEMLOG}
３回目のハングアップ
3回目が起きたときは休日で何もせずに1時間ぐらいで復旧したようでした。
原因調査と対策
2回目のハングアップ後に仕込んだテキストファイルを確認したところ
以下のような状況でした。
- ハングアップ中はテキストファイルへの出力もできてなかった
- ハングアップからの復旧直後、CPU使用率リストで「kswapd0」に出ていた
kswapd0は Linuxカーネルがメモリ管理とスワップの処理を行うためのバックグラウンドプロセスということで、
スワップ領域を確認すると、そもそもないことに気付きました。。
EC2のT2、T3インスタンスタイプは
デフォルトでスワップ領域は設定されていないようです。
これが原因だったかと思い、
2GBのスワップ領域を設定することにしました。
まず、 スワップファイルを以下のコマンドで作成します。
dd if=/dev/zero of=/swapfile bs=64M count=32
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
その後、 /etc/fstab に以下を追記します。
/swapfile swap swap defaults 0 0
さらに、スワップ処理を行う頻度を変更します。
デフォルトでは60になっているので10にしました（数字が大きいとスワップする頻度が高まるようです）。
/etc/sysctl.conf に以下を追記します。
vm.swappiness = 10
追記後、設定を反映させるために以下のコマンドを実行します。
sysctl -p
こちらの設定を入れてからは、止まることなく稼働しています。
考察
t2.micro（1vCPU、メモリ1GB）
で運用していたときのメモリ量は問題なかったですが、
t3a.micro（2vCPU、メモリ1GB）
にしてからCPU数が増えて処理はできるようになったけど、メモリが不足するようになったと思われます。
まとめ
- CPU スペックのみを増強することによってハングアップすることがある
- AWS の EC2 の一部のインスタンスは、スワップ領域がデフォルトではない → 必要なら要設定