EC2 t2.micro でメモリーが不足した場合の挙動について調べてみた
はじめに
こんにちは植木和樹です。前回のブログでstressツールを使ってサーバーを高負荷にする方法をご紹介しました。
今回はstressツールを使って、メモリー搭載量の少ないt2.microインスタンスでメモリーを消費し続けた場合にどういう挙動になるのか調べてみました。
実験準備
t2.microはメモリー1GBですが、単純にメモリーを1GB（-m でワーカー4つ）割り当てようとするとメモリーが不足してstressツールが失敗してしまいます。
$ stress -m 4 stress: info: [22591] dispatching hogs: 0 cpu, 0 io, 4 vm, 0 hdd stress: FAIL: [22595] (494) hogvm malloc failed: Cannot allocate memory stress: FAIL: [22591] (394) <-- worker 22595 returned error 1 stress: WARN: [22591] (396) now reaping child worker processes stress: FAIL: [22591] (451) failed run completed in 6s
そこでまずはスワップファイルを作成し、仮想メモリーを追加しておきましょう。
$ sudo -s
# fallocate -l 1024m /tmp/swap.img
# mkswap /tmp/swap.img
# chmod 600 /tmp/swap.img
# swapon /tmp/swap.img
$ free
total used free shared buffers cached
Mem: 1020140 61540 958600 0 2600 13452
-/+ buffers/cache: 45488 974652
Swap: 1048572 0 1048572
メモリー消費実験
スワップ発生
改めてメモリーの割り当て／解放を実施させた状態でvmstatをみてみました。
$ stress -m 4
stressを動かしてすぐは、メモリが足りなくなるためスワップが発生します。
procs -----------memory---------- ----swap---- -----io----- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 4 0 0 133480 2632 13668 0 0 0 0 129 100 5 36 0 0 59 0 5 155972 54432 204 3900 900 221564 900 221600 2170 3281 0 6 0 89 5 0 5 250928 65504 52 1156 85500 29576 85500 29576 3070 5698 0 1 0 93 6 0 5 289572 70088 52 1148 33904 38644 33904 38644 1393 2231 0 0 0 96 4
スワップが発生している状態だと、vmstatでみた場合に次のような傾向があるようです。
- 空きメモリが減少し、スワップが発生している（memory の freeとswpd）
- SwapIn(si), SwapOut(so)が発生している
- プロセスのブロックが発生している（procs b）
- CPU Wait I/Oが発生している（cpu wa）
しばらくすると、スワップが落ち着きます（memory freeは変化しているが、それ以外は安定）。その後10分周期くらいでスワップ発生→落ち着くという挙動を繰り返します。
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 5 0 14876 636880 1712 14944 0 0 0 0 263 278 8 92 0 0 0 4 0 14872 269892 1712 14948 0 0 0 0 264 281 11 89 0 0 0 4 0 14872 194248 1712 14944 0 0 0 0 265 282 7 93 0 0 0 4 0 14872 705100 1712 14944 0 0 0 0 261 283 10 90 0 0 0 4 0 14872 346064 1712 14944 0 0 0 0 262 280 10 90 0 0 0
stressツールを動かしてから30分程経過するとCPU Credit Balanceを使い切ってしまいます。
そのためスワップに必要なCPUがStolenになってしまい、スワップが発生しにくくなります。下に掲載したvmstatのグラフで水色のsystemが段階的に減少し、グレーのstolenが増えているのが分かりますね。
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ ---timestamp--- r b swpd free buff cache si so bi bo in cs us sy id wa st 5 0 17536 430848 448 3360 0 0 0 0 54 45 2 17 0 0 81 2014-12-29 06:09:57 UTC 4 0 17536 166156 448 3360 0 0 0 0 55 44 1 16 0 0 83 2014-12-29 06:09:58 UTC 2 7 73564 49524 448 3380 16 56028 16 56032 167 284 2 9 0 32 57 2014-12-29 06:09:59 UTC 0 8 147132 52316 448 3784 68 73592 520 73592 610 436 0 7 0 69 24 2014-12-29 06:10:01 UTC ： ： 0 5 565608 81912 44 1600 37328 40320 37328 40320 1610 2640 0 5 0 85 10 2014-12-29 06:10:32 UTC 5 4 524284 73880 44 1488 49424 10668 49424 10668 1863 3463 1 9 0 62 28 2014-12-29 06:10:33 UTC 5 4 524284 69316 44 1484 64708 16 64708 16 1977 4088 0 5 0 49 46 2014-12-29 06:10:34 UTC 5 3 398652 231404 44 1488 50968 284 50968 284 1592 3257 0 8 0 41 51 2014-12-29 06:10:35 UTC 6 0 50500 721144 44 1496 2584 0 2584 0 136 218 1 17 0 0 82 2014-12-29 06:10:36 UTC 5 0 18520 552772 44 1484 36 0 36 0 60 66 1 17 0 0 82 2014-12-29 06:10:37 UTC
6:10頃に一時的に大量のスワップが発生していますが、vmstatのprocsがb→rに戻るまでに通常の2〜3倍（30〜40秒）近くかかっています。もう少しプログラムレベルでみてみないと分かりませんが、もしかしたらmalloc処理で異常に時間がかかっているかもしれません。
まとめ
今回はstressツールを使って、大量スワッピング（スラッシング）を強制的に発生させてみました。
- スワップが発生するとCPU Waitが発生し、procsのb(Block)の数値があがる。
- メモリースワップにもCPU（System）を使用する。
- t2ファミリーなどCPU Credit Balance枯渇によってCPU性能が大きく低下する場合、アプリケーション処理＋メモリ確保それぞれで著しい性能低下が発生する。
新しインスタンスタイプを本番環境に投入する前には、負荷試験だけでなく耐久試験（エイジングテストと呼んだりもします）を行うのが良いかと思います。
