☰

EC2 インスタンスが自動的に使用不可になる - 504 ゲートウェイ タイムアウト

tag-icon • tag-icon amazon-web-services amazon-ec2
EC2 インスタンスが自動的に使用不可になる - 504 ゲートウェイ タイムアウト

私はt3a.マイクロトラフィックがかなり少ない WordPress を実行しているインスタンス。このインスタンスは自動的に使用不可になり、504 ゲートウェイ タイムアウト エラーが発生します。その時点では、ssh を使用して EC2 に接続することもできません。これは、1 日中いつでも発生し、毎日発生することもあれば、1 週間まったく発生しないこともあります。ダウンしてもトラフィックの急増はありません。AWS サポートにもこの質問をしましたが、次の回答が返ってきました。

私の側で確認したところ、過去24時間以内にインスタンスがインスタンスステータスチェック[1]に数回失敗しており、インスタンスにOSレベルの問題があることがわかりました。コンソールログをさらに確認すると、次のメモリ不足エラーが表示されました。

[ 5626.002561] メモリ不足: プロセス 2050 (apache2) を強制終了しました total-vm:552924kB、anon-rss:54868kB、file-rss:0kB、shmem-rss:32076kB、UID:33 pgtables:848kB oom_score_adj:0

[ 5674.174673] メモリ不足: プロセス 1788 (apache2) を強制終了しました total-vm:624936kB、anon-rss:51952kB、file-rss:0kB、shmem-rss:34184kB、UID:33 pgtables:856kB oom_score_adj:0

[ 5763.820732] メモリ不足: プロセス 1815 (apache2) を強制終了しました total-vm:550384kB、anon-rss:51604kB、file-rss:0kB、shmem-rss:34532kB、UID:33 pgtables:836kB oom_score_adj:0

[ 5773.275938] メモリ不足: プロセス 1973 (apache2) を強制終了しました total-vm:624744kB、anon-rss:52260kB、file-rss:0kB、shmem-rss:32136kB、UID:33 pgtables:856kB oom_score_adj:0

[ 5959.347157] メモリ不足: プロセス 2014 (apache2) を強制終了しました total-vm:552440kB、anon-rss:54020kB、file-rss:0kB、shmem-rss:28856kB、UID:33 pgtables:844kB oom_score_adj:0

[ 6438.787255] メモリ不足: プロセス 2165 (apache2) を強制終了しました total-vm:624756kB、anon-rss:51948kB、file-rss:0kB、shmem-rss:29836kB、UID:33 pgtables:856kB oom_score_adj:0

OOM (メモリ不足) キラーについて少し説明します。プロセスによってメモリが使い尽くされ、システムの安定性が脅かされる程度になると、OOM キラーが作動します。カーネルが実行しようとしているプロセスの残りの部分がスムーズに機能するのに十分なメモリが解放されるまで、プロセスを強制終了し続けるのが OOM キラーの役割です。出力から判断すると、インスタンスがメモリを使い果たした可能性があり、そのため Linux カーネルによって OOM キラーが呼び出されているようです。

彼らは、各プロセスによるメモリ使用量を監視し、そのプロセスを強制終了または修正して、メモリをあまり使用しないようにすることを提案しました。これは、WordPress を実行しているときにはあまり実用的なアプローチとは思えません。数分間メモリを大量に使用していても、変更することはできないからです。

別の例がありますt3.小beanstalk が提供する amazon linux AMI 上で、nginx/tomcat 環境を備えた Java Web アプリケーションをホストする elastic beanstalk を使用しています。このインスタンスでも同じ問題が発生し、自動的にダウンし、504 ゲートウェイ タイムアウトが表示されます。

質問：- 現在のトラフィック量ではインスタンスは完全に正常に動作しているので、インスタンスをアップグレードしたくありません。アップグレードやプロセスの継続的な監視を行わずにこれらの問題に対処するソリューションはありますか?

答え1

主なオプションは次のとおりです。

  • RAM を使用しているものを特定し、RAM の使用量を減らすように設定します (最適なオプション)
  • より多くの RAM を搭載したインスタンスを使用する (問題が完全に解決されない可能性があります)
  • RAM を増やす安価な方法としてスワップ ファイルを使用します - 私は、OOM 状況を防ぐためにスペアがあることを確認するためにスワップ ファイルを使用しているので、問題は解決しませんが、良いアイデアです。

私は、t3a.nano (512MB RAM) と 512MB スワップで、比較的低容量の 5 つの Wordpress ウェブサイト、MySQL、およびその他のツールをいくつか実行しています。

以下に、一般的な Wordpress システムのメモリ使用量を削減する方法をいくつか示します (思いつく限り):

  • PHP スレッド/ワーカーの数を制限します。おそらく 2 ～ 3 個のスレッドを許可します。スレッドが 1 つも利用できない場合は、Web サーバーはスレッドが利用できるようになるまで待機しますが、通常はそれほど長くはかかりません。PHP/Wordpress は大量のメモリを消費するため、これは重要です。
  • 各 PHP スレッドで使用できる最大メモリを制限します。
  • MySQLパフォーマンススキーマをオフにする
  • MySQL パラメータを調整してメモリ使用量を減らします。基本的にはドキュメントを読むだけですが、現在の設定を以下にコピーします。これは私の Windows PC のものですが、Linux でも同様です。
  • Web サーバーのメモリ使用量を確認してください。Apache でメモリ使用量が多い場合は、高速で小さい Nginx を検討してください。

「LAMP（またはLEMP）WordPressのメモリ使用量削減」も検索してください。

私が使用している MySQL 構成は次のとおりです。これは MySQL 8.x 用の新しい構成で、テストは行われていませんが、MySQL5 の構成と非常に似ているため、問題ないはずです。これは、高パフォーマンスではなく、低メモリ使用量に最適化されており、私は MySQL の専門家ではないため、おそらくあまり良くありません。

[mysqld]
# set basedir to your installation path
basedir=(insert here)
# set datadir to the location of your data directory
datadir=(insert here)

# Turn off performance schema
performance_schema=OFF

# Turn off binary log
skip-log-bin
log_bin = OFF

# Disable monitoring
innodb_monitor_disable=all

# RAM optimisation settings overall
innodb_buffer_pool_size=50M
innodb_buffer_pool_instances=1
innodb_flush_method=unbuffered
innodb_log_buffer_size=1048576
innodb_log_file_size=4194304
innodb_max_undo_log_size=10485760
innodb_sort_buffer_size=64K
innodb_ft_cache_size=1600000
innodb_max_undo_log_size=10485760
max_connections=20
key_buffer_size=1M

# Reduce RAM: per thread or per operation settings
thread_stack=140K
thread_cache_size = 2
read_buffer_size=8200
read_rnd_buffer_size=8200
max_heap_table_size=16K
tmp_table_size=128K
temptable_max_ram=2097152
bulk_insert_buffer_size=0
join_buffer_size=128
net_buffer_length=1K

# Slow query log
slow_query_log=OFF
#long_query_time=5
#log_slow_rate_limit=1
#log_slow_rate_type=query
#log_slow_verbosity=full
#log_slow_admin_statements=ON
#log_slow_slave_statements=ON
#slow_query_log_always_write_time=1
#slow_query_log_use_global_control=all

# Logs
log_error = (wherever)
general_log = ON
general_log_file  = (wherever)

関連情報