나는t3a.마이크로트래픽이 매우 적은 WordPress를 실행하는 인스턴스입니다. 이 인스턴스는 자동으로 사용할 수 없게 되어 504 게이트웨이 시간 초과 오류가 발생합니다. 그 순간 SSH를 사용하여 EC2에도 연결하지 못했습니다. 하루 중 언제든지 발생하고 때로는 매일 발생하며 때로는 일주일 내내 전혀 발생하지 않습니다. 다운되어도 트래픽 급증이 없습니다. AWS Support에도 이 질문을 했고 다음과 같은 답변을 받았습니다.
직접 확인해보니 지난 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(Out of memory) 킬러에 대해 조금 설명하자면, 프로세스에서 메모리를 너무 많이 사용하여 시스템의 안정성을 위협할 수 있는 경우 OOM 킬러가 시작됩니다. 계속해서 킬을 하는 것이 OOM Killer의 임무입니다. 커널이 실행하려는 나머지 프로세스가 원활하게 작동할 수 있도록 충분한 메모리가 확보될 때까지 처리합니다. 출력에 따르면 인스턴스가 메모리를 모두 소진했을 수 있으므로 Linux 커널이 OOM 킬러를 호출하는 것 같습니다.
그들은 각 프로세스의 메모리 사용량을 모니터링하고 해당 프로세스를 종료하거나 수정하여 많은 메모리를 사용하지 않도록 제안했습니다. 이는 WordPress를 실행할 때 몇 분 동안 너무 많은 메모리를 사용하더라도 수정할 수 없는 매우 실용적인 접근 방식처럼 보이지 않습니다.
다른 사례가 있습니다t3.소형beanstalk에서 제공하는 Amazon Linux AMI에서 nginx/tomcat 환경으로 Java 웹 애플리케이션을 호스팅하는 Elastic beanstalk를 사용합니다. 이 인스턴스에서도 동일한 문제가 발생하고 자동으로 다운되고 504 게이트웨이 시간 초과가 표시됩니다.
질문:- 현재 트래픽 양으로 완벽하게 실행되고 있기 때문에 인스턴스를 업그레이드하고 싶지 않습니다. 업그레이드나 지속적인 프로세스 모니터링 없이 이러한 문제를 처리할 수 있는 솔루션이 있습니까?
답변1
주요 옵션은 다음과 같습니다.
- RAM을 사용하는 것이 무엇인지 파악하고 더 적은 RAM을 사용하도록 구성합니다(최상의 옵션)
- RAM이 더 많은 인스턴스를 사용하세요(문제가 완전히 해결되지 않을 수 있음).
- RAM을 늘리는 저렴한 방법으로 스왑 파일을 사용합니다. OOM 상황을 방지하기 위해 여유 공간이 있는지 확인하기 위해 스왑 파일을 사용하므로 문제가 해결되지는 않지만 좋은 아이디어입니다.
나는 t3a.nano(512MB RAM) 및 512MB 스왑에서 상당히 적은 양의 Wordpress 웹 사이트 5개, MySQL 및 기타 몇 가지 도구를 실행합니다.
다음은 일반적인 Wordpress 시스템의 메모리 사용량을 줄이는 몇 가지 방법입니다.
- PHP 스레드/작업자 수를 제한합니다. 나는 아마도 2-3개의 스레드를 허용한다고 생각합니다. 하나가 사용 가능하지 않으면 웹 서버는 하나가 가능할 때까지 기다릴 것입니다. 일반적으로 그리 오래 걸리지 않습니다. PHP/Wordpress는 엄청난 메모리를 잡아먹기 때문에 이것이 핵심입니다.
- 각 PHP 스레드에 사용 가능한 최대 메모리를 제한합니다.
- MySQL 성능 스키마 끄기
- MySQL 매개변수를 설정하여 메모리 사용량을 줄이세요. 기본적으로 문서를 읽어야 하지만 아래의 현재 구성을 복사하겠습니다. 이것은 내 Windows PC에서 가져온 것이지만 Linux도 비슷할 것입니다.
- 웹 서버 메모리 사용량을 확인하세요. 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)