☰

중간 트래픽으로 인해 WordPress 서버에 하드 재부팅이 필요함

tag-icon • tag-icon apache-2.4 wordpress centos7 mariadb rackspace
중간 트래픽으로 인해 WordPress 서버에 하드 재부팅이 필요함

이메일 전송 후 중간 트래픽으로 인해 랙스페이스 WordPress 서버가 다운되는 데 문제가 있습니다.

서버 사양은 다음과 같습니다.

CPU            2 vCPUs
RAM            2 GB
System Disk   80 GB
Network      240 Mb / s
Disk I/O    Good

달리기:

Centos       7.0
Wordpress  4.3.1
Httpd      2.4.6
PHP       5.4.11
MariaDB   5.5.41

내가 알 수 있는 한 설치는 모두 매우 표준적이며 데이터베이스는 매우 표준적이고 색인화되어 있으며 상당히 작습니다. 우리는 또한 WordPress 개체 캐싱을 수행하고 있습니다.

뉴렐릭(New Relic)에 따르면; 정상적인 트래픽 동안 사이트는 PHP에서 약 80%의 시간을 소비하고, 웹 외부에서 15%의 시간을 소비하며, 데이터베이스에서는 적은 비율만 소비합니다. 평균 표준 페이지 앱 시간은 약 800ms인데, 제가 보기에는 느린 것 같습니다.

1분 안에 250개의 연결에 대한 로드 테스트를 실행하면 연결이 점점 더 길어지고 약 30개 이후에 시간 초과가 시작되며 서버가 응답하지 않게 됩니다(트래픽이 다시 중단되는 경우에도). 다시 활성화하려면 하드 재부팅이 필요합니다.

퍼티를 사용하여 연결할 수 없으며 홈 페이지가 시간 초과와 '데이터베이스 연결 설정 중 오류 발생'을 반환하는 사이에서 진동합니다.

가장 최근 테스트에서 랙 공간 모니터링 에이전트를 사용하면 CPU가 죽기 직전에 최대 100%에 도달한 것으로 나타났으며, 사용된 메모리는 약 1.6GB로 최고치에 이르렀으며 약 100MB까지 여유롭게 떨어졌습니다. 스왑 메모리도 2GB 정도(총 4GB) 정도 사용되고 있는 것 같습니다. 표준 사용량은 약 15% CPU, 800MB 메모리, 400MB 스왑인 것으로 보입니다.

우리의 Apache 구성은 다음 중 어떤 것도 설정하지 않습니다( /etc실행할 파일 없음). 시간 초과, KeepAlive, MaxKeepAliveRequests, KeepAliveTimeout; 그래서 기본값을 사용하고 있는 것 같아요.

mariadb 설정을 살펴보았습니다.

innodb_buffer_pool_size = 1400M
max_user_connections = 0

원인은 아닌 것 같습니다.

Performance_schema도 켰지만, 내가 무엇을 찾고 있는지 잘 모르겠습니다. DB가 문제인지도 모르겠습니다.

인스턴스를 업그레이드하고 싶은 마음이 들지만 단순히 속도를 늦추는 것보다 병목 현상이 발생한 위치와 서버가 중단되는 원인을 더 명확하게 파악하고 싶습니다.

어디서부터 시작해야 할지에 대한 아이디어가 있나요? 거기에는 가능한 많은 조정이 가능하고 많은 정보가 있는 것 같습니다.

답변1

모든 종류의 이벤트가 진행되는 동안 면밀한 모니터링이 중요합니다. 보시다시피 진실이 밝혀졌습니다.

가장 최근 테스트에서 랙 공간 모니터링 에이전트를 사용하면 CPU가 죽기 직전에 최대 100%에 도달한 것으로 나타났으며, 사용된 메모리는 약 1.6GB로 최고치에 이르렀으며 약 100MB까지 여유롭게 떨어졌습니다. 스왑 메모리도 2GB 정도(총 4GB) 정도 사용되고 있는 것 같습니다. 표준 사용량은 약 15% CPU, 800MB 메모리, 400MB 스왑인 것으로 보입니다.

PHP는 CPU를 많이 사용하는 것으로 잘 알려져 있습니다. 사용 가능한 CPU와 사용 가능한 RAM을 거의 모두 사용했습니다.

먼저 이를 처리하기 위한 opcode 캐싱(예: Zend OPcache) 및 파일 캐싱(예: W3 Total Cache WordPress 플러그인)과 같은 조치를 취해야 합니다. 그것들이 도움이 되지 않는다면충분한, 이제 인스턴스를 업그레이드할 차례입니다.

답변2

한 번에 너무 많은 프로세스를 실행하고 메모리가 부족하며 스왑이 발생하는 것일 수 있습니다. 다른 것이 잠겨 있을 수도 있지만 먼저 이 문제를 처리한 다음 현재 위치를 확인하세요.

mod_php를 사용하는지 아니면 php-fpm과 같은 것을 사용하는지 우리에게 알려주지 않았습니다. 후자는 로드를 더 잘 처리하지만 두 경우 모두 필요한 메모리보다 더 많은 PHP 프로세스를 실행하지 않도록 해야 합니다. 아마도 5개 또는 10개 이상의 프로세스를 실행해도 성능상의 이점을 얻지 못할 것입니다. 그러나 특히 mod_php의 기본 실행은 메모리에 있는 것보다 훨씬 더 많이 실행됩니다. 또한 30개 정도의 요청마다 프로세스를 재활용합니다. 데이터베이스와 OS에 1GB를 제공하면 나머지 GB는 아마도 10개의 WordPress 프로세스를 처리하지 못할 것입니다. 그들이 얼마나 많은 메모리를 사용하는지 살펴보고 약간의 여유를 두고 계산해 보세요. 정상적인 과정에서 스왑을 사용해서는 안됩니다.

연결 유지 설정을 확인하세요. Apache를 사용하면 끄거나 1초로 설정하는 것이 가장 좋습니다. Nginx는 연결 유지를 훨씬 더 잘 처리합니다. 실제로 이것은 nginx가 WordPress와 같은 PHP 애플리케이션에서 더 나은 성능을 발휘할 가능성이 있는 유일한 중요한 이유입니다(비록 덜 쾌적한 구성의 대가를 치르더라도). 이는 테스트에서는 중요한 요소가 아닐 가능성이 높지만 실제 브라우저에서는 중요합니다.

100% CPU는 정말 놀랍습니다. 무엇이 그것을 사용하고 있는지 보려면 top을 사용하십시오. 100%는 종종 하나의 코어의 100%를 의미한다는 점도 기억하세요. WordPress에서는 일반적으로 "cron"이 아니라 웹 요청을 처리하는 동안 추가로 작업이 실행되는 하나의 cron 작업이 시작되는 것을 볼 수 있습니다. Opcode 캐싱 부족으로 인해 CPU 사용량이 높아질 수도 있습니다.

관련 정보