끊임없이 PHP-FPM을 다시로드해야합니다

nginx와 PHP-FPM을 실행하는 상당히 많은 서버가 있습니다. 이 서버에는 6 개의 웹 사이트가 있으며 PHP-FPM 및 nginx를 실행합니다. 소프트웨어는 모두 vBulletin 3.8 및 WordPress입니다. 데이터베이스는 별도의 서버에 있습니다.

이제는 이들이 인기있는 웹 사이트이기 때문에 일반적으로 한 번에 7-8,000 명의 방문자가 온라인에 있고 각 페이지가 대부분 데이터베이스에 도달합니다. 이것이 문제의 원인이라고 생각합니다.

MySQL 서버에 대용량 데이터베이스가 많고 쿼리가 소프트웨어에서 훨씬 더 나을 수 있기 때문에 MySQL은 때때로 적시에 결과를 PHP에 반환하지 못해 결국에는 계단식 효과가 발생한다고 생각합니다 PHP-FPM을 다시로드 할 때까지 모든 것이 멈추게합니다. 우리가 그 후에 일이 다시 잘 작동하기 시작합니다.

이 문제를 해결하는 데 문제가있는 이유는 실제로 로그에서 아무것도 식별 할 수 없기 때문입니다. MySQL 느린 쿼리 로그에서 가동 중지 시간이 발생하면 관심이 없습니다. nginx 로그에서 읽기 요청 시간이 초과되었거나 연결 시간이 초과되었다고 말하는 수천 개의 항목이 표시됩니다 (To PHP-FPM). 그리고 PHP-FPM 로그에서 "실행 시간이 초과되었습니다 (31 초)라는 문구가 많이 표시됩니다.

따라서이 시점에서 나는 어디에서 문제를 찾아야할지 완전히 모른다. 분명히,이 스크립트는 때때로 충분히 빨리 실행되지 않기 때문에 무슨 일이 일어나고 있는지 (일반적으로 1 초 안에로드되지만로드 시간이 급격히 증가하는 일이 발생합니다). 이것은 하루에 여러 번 발생하며 우리에게는 상당히 문제가되었습니다.

지금은 10 분마다 php5-fpm reload를 서비스하는 crontab을 가지고 있으며, 이는 충돌 문제를 해결합니다. 물론, PHP가 다시로드 될 때 nginx는 502 게이트웨이 오류를 발생 시키므로 그다지 해결책이 아닙니다.

중요한 경우 PHP는 APC 캐시를 실행합니다. 나는 APC가 특정 상황에서 교수형을 일으킬 수있는 몇 가지 지점을 읽었습니다.

모든 조언이 도움이 될 것입니다. 나는 항상이 기계에 대해 걱정할 필요가 없습니다.

더 많은 정보는 물론 제공 될 수 있습니다. 필요한 것을 알려주세요.

업데이트 : 방금 apc.php를 웹 루트에 복사하고 통계를 확인하기 위해 액세스했습니다. 상황이 좋아 보였다. 그런 다음 링크를 클릭하여 사용자 통계로 이동 한 다음 서버가 즉시 중단되었습니다. php-fpm을 다시로드 한 다음 사용자 통계 페이지를 다시로드하면 정상적으로 진행되었습니다. 잠시 기다렸다가 다시로드하면 서버가 다시 중단됩니다.

따라서 이것은 분명히 APC와 관련된 것 같습니다. 문제는-어떻게 고치나요?

APC 구성 :

[apc]
apc.enabled="1"
apc.stat = "1"
apc.max_file_size = "2M"
apc.localcache = "1"
apc.localcache.size = "256"
apc.shm_segments = "1"
apc.ttl = "3600"
apc.user_ttl = "7200"
apc.gc_ttl = "3600"
apc.cache_by_default = "1"
apc.filters = ""
apc.write_lock = "1"
apc.num_files_hint= "10000"
apc.user_entries_hint="10000"
apc.shm_size = "1G"
apc.mmap_file_mask=/tmp/apc.XXXXXX
apc.include_once_override = "0"
apc.file_update_protection="2"
apc.canonicalize = "1"
apc.report_autofilter="0"
apc.stat_ctime="0"

업데이트 2 : 우리는 여기에 약간의 발전을 이루었습니다. WordPress 캐싱 플러그인 (W3 Total Cache)이 충돌의 원인이었습니다. 우리는 여전히 이유를 알지 못하지만, 비활성화 된 상태에서 이제 거의 4 시간 동안 PHP를 다시로드하지 않고 속도를 늦추거나 충돌없이 실행했습니다. 우리는 vBulletin 포럼에서 여전히 APC를 사용하고 있으며 전혀 문제가 없습니다. APC가 충돌 하는 이유 를 확인할 수있는 방법 이 있습니까? WordPress 설치에서 사용하고 싶지만 깨지기 쉬운 시스템 비용은 아닙니다.

php-fpm을 사용하고 있으므로 php-fpm의 자녀가 얼마나 오래 살 수 있는지에 대해 더 적극적으로 제안하는 것이 좋습니다. 수명이 짧은 실 / 아이들과 안정성 사이에 적절한 지점을 찾아야합니다. php-fpm 기본값은 모든 프로덕션 시스템, IMHO에 관대합니다.

프로덕션 풀의 pm.max_requests 수를 줄 였습니다. 기본값은 200이라고 생각합니다. 50에서 시작하여 어디로 가는지 봅니다.

이것에 실패하거나 보완 적 인 경우 다음과 같은 전역 옵션을 시도 할 수도 있습니다 (AFAIK는 기본적으로 모두 비활성화되어 있습니다).

emergency_restart_threshold=3
emergency_restart_interval=1m
process_control_timeout=5s

이것은 무엇을 의미 하는가? 1 분 내에 3 개의 PHP-FPM 자식 프로세스가 SIGSEGV 또는 SIGBUS (예 : 크래시)로 종료되면 PHP-FPM이 자동으로 다시 시작됩니다. 자식 프로세스는 마스터의 신호에 대한 반응을 5 초 동안 기다립니다.

이렇게하면 PHP 작업자 스레드 풀을 신선하고 깨끗하게 유지할 수 있습니다. 근로자가 요청을 더 많이 제공할수록 더 불안정합니다. 또한 메모리 누수 위험이 높습니다.

여기에 언급 한 모든 구성 옵션과 다른 옵션에 대한 좋은 개요가 있습니다 : http://myjeeva.com/php-fpm-configuration-101.html

이 팁이 도움이 되길 바랍니다. 불행히도이 모든 것에 대한 경험의 규칙이없는 것처럼 보이고, PHP의 행동과 안정성에 영향을 미치는 변수가 너무 많습니다.