Apache 2.4 이벤트 MPM + php-fpm + php-opcache에서 "피어에 의한 연결 재설정" 오류가 발생함

Apache 2.4 이벤트 MPM + php-fpm + php-opcache에서 "피어에 의한 연결 재설정" 오류가 발생함

Event MPM 및 php-fpm 버전 5.6.10(REMI 저장소에서)을 사용하여 Apache 2.4.6을 실행하는 CentOS 7 서버가 있습니다. 다음은 가상 호스트 내에서 php-fpm에 요청을 보내는 관련 Apache 구성입니다(이 서버의 유일한 사이트입니다).

<FilesMatch \.php$>
    SetHandler "proxy:unix:/var/run/php-fpm/www.sock|fcgi://localhost"
</FilesMatch>

관련 php-fpm 풀 conf는 다음과 같습니다.

listen = /var/run/php-fpm/www.sock
listen.owner = apache
listen.group = apache
pm = static
pm.max_children = 50
pm.max_requests = 0

다음은 php-opcache 구성(기본 설치 구성)입니다:

zend_extension=opcache.so
opcache.enable=1
opcache.memory_consumption=128
opcache.max_accelerated_files=4000
opcache.blacklist_filename=/etc/php.d/opcache*.blacklist

내 문제:php-opcache를 설치하고 활성화할 때마다 오류 로그에 다음 오류가 나타나기 시작합니다.

[Thu Jun 18 08:10:58.499871 2015] [mpm_event:debug] [pid 16546:tid 139798115227392] event.c(986): (104)Connection reset by peer: [client 157.55.39.233:15962] AH00470: network write failure in core output filter
[Thu Jun 18 08:10:58.527424 2015] [mpm_event:debug] [pid 16546:tid 139797922195200] event.c(986): (103)Software caused connection abort: [client 157.55.39.233:15990] AH00470: network write failure in core output filter

php-opcache를 제거하면 오류가 중단됩니다. 이 문제가 발생할 때마다 사용자는 프런트엔드에서 502 서비스를 사용할 수 없음 오류를 보고합니다.

나는 말 그대로 Google을 검색하고 해결책을 찾으려고 최소 6시간을 보냈습니다. 누군가 opcache fastshutdown옵션이 문제라고 했지만 기본 구성에서는 비활성화되어 있습니다. php-fpm 프로세스 관리 방법을 재활용 없이 정적으로 변경했지만(max_requests=0) 아무것도 변경되지 않았습니다. 또한 Apache에서 (소켓 대신) TCP 프록시 방법을 사용해 보았지만 아무런 영향을 미치지 않았습니다.

이것이 관련이 있는지 없는지 확실하지 않지만 php-opcache가 설치되어 있는지 여부에 관계없이 오류 로그에 다음과 같은 오류가 보고됩니다(그러나 훨씬 작은 빈도로 전체 트래픽의 0.5% 미만으로 발생합니다. 별도의 문제임):

[Thu Jun 18 08:32:37.223430 2015] [proxy_fcgi:error] [pid 19187:tid 140598765840128] [client 37.46.115.238:55624] AH01068: Got bogus version 10, referer: ...
[Thu Jun 18 08:32:37.223462 2015] [proxy_fcgi:error] [pid 19187:tid 140598765840128] (22)Invalid argument: [client 37.46.115.238:55624] AH01075: Error dispatching request to :, referer: ...

이 문제는 다음과 매우 유사합니다.이 하나, 비록 그 사람이 TCP 방식으로 ProxyPassMatch를 사용하고 있지만 저는 그렇지 않습니다(이(가) .htaccess를 우회하기 때문입니다).

내가 아직 언급하지 않은 아이디어가 있는 사람이 있나요?

답변1

우리 환경에서 비슷한 문제를 본 적이 있는데, 이는 OpCache(기본적으로)가 공유 호스팅 환경의 모든 사용자에게 단일 캐시를 공유하는 방식 때문인 것 같습니다. ㅏ버그가 제출되었습니다(또한 이것이 귀하의 사용 사례에 얼마나 중요한지 유지관리자에게 알리기 위해 투표를 할 수 있고 해야 합니다.) 그러나 수정 사항 제공에 대한 약속은 이루어지지 않았습니다.

핵심요약: 기본적으로 OpCache가 활성화되면 컴파일된 바이트 코드를 저장하는 데 사용되는 캐시가 모든 사용자에게 공유됩니다. 여러 사이트/사용자 간에 호스팅을 공유하는 환경에서,이로 인해 사이트가 다른 사이트에서 캐시된 PHP 스크립트 출력을 가져오거나 특정 보안 설정이 활성화된 경우 오류가 발생할 수도 있습니다..

PHP 5.5+에 내장된 opcache와 함께 PHP-FPM을 사용할 계획이라면 실제로 사용하기 전에 아래 블로그 게시물을 읽어보세요. opcode 캐시는 서버의 모든 사용자가 읽을 수 있는 것으로 나타났습니다. 즉, 자체 가상 호스트와 디렉터리가 있는 10명의 개별 사용자가 있고 사용자당 하나의 PHP-FPM 풀을 구성하는 경우 각 사용자는 여전히 캐시된 스크립트와 해당 위치를 볼 수 있습니다. 캐시에 대한 읽기 액세스 권한이 있으므로 잠재적으로 이 모든 데이터를 볼 수 있습니다.

이는 분명히 엄청난 보안 문제이며, 아무도 이를 악용하지 않더라도 페이지를 생성할 때 잘못된 사용자가 스크립트를 읽을 가능성이 여전히 있으므로 여러 인덱스가 있는 경우 웹사이트에서 잘못된 데이터/정보를 표시할 수 있습니다. 캐시의 .php 스크립트.

공식적으로 수정 사항이 출시되지는 않았지만 cPanel을 사용하는 경우이 위키에는 사용자별로 생성되고 보호되도록 php-fpm 풀을 구성하는 문서화된 방법이 있습니다.아래 지침과중요 사항이 답변의 맨 아래에서 오류 없이 원하는 기능을 얻을 수 있어야 합니다.

해당 게시물에는 사이트별/사용자별로 직접 구성하는 방법도 설명되어 있습니다(많은 사이트를 호스팅하는 경우 지루해질 수 있다고 장담합니다). cPanel을 사용하지 않는 경우 cPanel의 구성 엔진에서 사용되는 변수 대신 개별 경로와 사용자 이름을 지정하도록 스크립트를 수정해야 할 수도 있습니다.


중요 사항

테스트 및 추가 조사 중에 나는몇 가지 설명을 제공하는 이 기사귀하의 특정 상황과 관련이 있을 수 있는 사항:

  1. 애플리케이션의 OpCache 구성을 위해 opcache.use_cwd매개변수가 로 설정되어 있는지 확인해야 합니다. 이 매개변수 는 기본적으로 로 설정되어 있으며 기본값으로 설정된 상태로 두면 시스템에서 둘 이상의 PHP 애플리케이션을 호스팅하는 경우 충돌이 발생할 수 있습니다.truefalse

우선, 아마도 각 일반 프로젝트에서 opcache.use_cwd 옵션이 true로 설정되어 있는지 확인해야 할 것입니다. 이 설정을 활성화하면 OpCache 엔진이 전체 파일 경로를 확인하여 동일한 이름을 가진 파일을 구별하게 됩니다. false로 설정하면 동일한 기본 이름을 가진 파일 간에 충돌이 발생합니다.

  1. opcache.load_commentsZend Framework 또는 주석을 사용하는 다른 유사한 프레임워크로 구동되는 애플리케이션을 실행하는 경우 및 opcache.save_comments지시어가 로 설정되어 있는지도 확인해야 합니다 true. 이제 대부분의 시스템에서 OpCache를 적절하게 사용하도록 설정하는 방법에 대한 특정 지침으로 문서를 업데이트했으므로 애플리케이션/프레임워크 문서에서 이 제안을 다시 확인해야 합니다.

주석을 활용하는 도구와 프레임워크에도 중요한 설정이 있습니다. Doctrine, Zend Framework 2 또는 PHP Unit을 사용하는 경우 opcache.load_comments 및 opcache.save_comments 설정을 true로 설정해야 합니다. 결과적으로 파일의 문서 주석도 OpCache에서 생성된 사전 컴파일된 코드에 포함됩니다. 이 설정을 사용하면 중단 없이 주석 작업을 할 수 있습니다.

프로젝트가 특정 프레임워크나 웹 애플리케이션을 기반으로 하는 경우 항상 OpCache 구성과 관련된 지침이 있는지 문서를 확인하는 것이 좋습니다.

중요 사항


이것이 도움이 되었기를 바랍니다. cPanel을 사용하는 경우 구성의 해당 부분을 어떻게 처리했는지 댓글로 알려주세요! 이 질문 및 관련 의견도 참조하십시오..

관련 정보