田舎に住みたいエンジニアの日記

AWSのEC2を利用し、t1.microのインスタンスでMySQLを入れて運用してみたら、よくMySQLが落ちる現象がありました。

以下のようなログが出ます。

2015-06-25 14:00:05 5113 [Note] InnoDB: 5.6.24 started; log sequence number 5058109
2015-06-25 14:00:05 5113 [Note] Server hostname (bind-address): '*'; port: 3306
2015-06-25 14:00:05 5113 [Note] IPv6 is available.
2015-06-25 14:00:05 5113 [Note]   - '::' resolves to '::';
2015-06-25 14:00:05 5113 [Note] Server socket created on IP: '::'.
2015-06-25 14:00:06 5113 [Note] Event Scheduler: Loaded 0 events
2015-06-25 14:00:06 5113 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.6.24'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MySQL Community Server (GPL)
150625 14:22:52 mysqld_safe Number of processes running now: 0
150625 14:22:52 mysqld_safe mysqld restarted
2015-06-25 14:23:01 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documen
tation for more details).
2015-06-25 14:23:01 0 [Note] /usr/sbin/mysqld (mysqld 5.6.24) starting as process 5290 ...
2015-06-25 14:23:01 5290 [Note] Plugin 'FEDERATED' is disabled.
2015-06-25 14:23:02 5290 [Note] InnoDB: Using atomics to ref count buffer pool pages
2015-06-25 14:23:02 5290 [Note] InnoDB: The InnoDB memory heap is disabled
2015-06-25 14:23:02 5290 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2015-06-25 14:23:02 5290 [Note] InnoDB: Memory barrier is not used
2015-06-25 14:23:02 5290 [Note] InnoDB: Compressed tables use zlib 1.2.3
2015-06-25 14:23:02 5290 [Note] InnoDB: Using Linux native AIO

スタートするも、何もログには吐かれずに再起動がされてしまっている模様。

# sar -S

11時20分01秒 kbswpfree kbswpused  %swpused  kbswpcad   %swpcad
11時30分02秒       456   1048116     99.96     49228      4.70
11時40分02秒         0   1048572    100.00     52908      5.05
11時50分02秒         0   1048572    100.00     56332      5.37
12時00分02秒     12724   1035848     98.79     24596      2.37
12時10分01秒      8516   1040056     99.19     25596      2.46
12時20分01秒       808   1047764     99.92     24332      2.32
12時30分03秒         0   1048572    100.00     43504      4.15
12時40分03秒      7772   1040800     99.26     20948      2.01
12時50分02秒     17396   1031176     98.34     25756      2.50
13時00分01秒     17540   1031032     98.33     25752      2.50
13時10分02秒         0   1048572    100.00     46824      4.47
13時20分02秒      3328   1045244     99.68     34904      3.34
13時30分02秒         0   1048572    100.00     46428      4.43
13時40分02秒         0   1048572    100.00     39088      3.73
13時50分02秒     32712   1015860     96.88      6916      0.68
14時00分06秒     31996   1016576     96.95      9180      0.90
14時10分02秒      3672   1044900     99.65      5652      0.54
14時20分02秒         0   1048572    100.00     33520      3.20

スワップが何と100%使い切られる事多し。
というわけで、メモリもスワップも枯渇したからOMM kilerが発動したわけだ。色々みていると以下の記事を発見。

CPUを使うサービスでt1.microは使っちゃダメ？AWSのEC2 t1.microインスタンスのCPU特性 – smallとのパフォーマンス比較

なるほど、確かにパフォーマンス高く使うにはコスパが悪いですね。
自分も一番小さいということで手軽に使っていたt1.microですが、コストパフォーマンスをしっかりと考えていきたいと思います。

田舎に住みたいエンジニアの日記

日々の雑記帳です。有用情報をどんどん更新していきます。

「OMM killer」タグアーカイブ

AWS EC2のt1.microインスタンスを利用していたら、MySQLが OMM killer で殺された！？

こんな記事も読まれています