data-id="1190000004975909" data-licence="">
어젯밤에 온라인 장애가 발생했습니다. 응급 처리 후 재해 복구로 전환한 후 장애를 해결한 후 공식으로 다시 전환하면 장애가 완화되었습니다. 재해 복구 서비스에서 PHP 파일 업데이트가 유효하지 않은 것으로 확인되어 FPM 후에만 적용됩니다. 검토 및 조사 과정은 다음과 같습니다.
PHP 파일 업데이트가 적용되지 않아서 바로 opcache를 의심했습니다. 온라인에서 php.ini를 살펴보니 실제로 opcache가 사용되고 감지 간격이 60초로 설정되어 있었습니다. 어젯밤의 로그를 보면 업데이트가 적용되지 않는 기간이 60초보다 훨씬 길기 때문에 이 감지 간격 문제는 통과할 수 있으며 계속 진행됩니다.
온라인 환경에서 업데이트된 파일과 로그의 시간을 확인해보니 갑자기 PHP 파일 시간과 로그의 시간이 일치하지 않는 것을 발견하여 즉시 OP에게 확인을 요청했습니다. OP는 이 파일이 mv에서 롤백되었기 때문에 파일 시간이 예상한 것과 일치하지 않는다고 설명했습니다. stat 명령을 사용하여 확인한 결과 수정 시간이 액세스 시간보다 약간 빠른 것으로 나타났습니다. 이 단서를 바탕으로 opcache는 PHP 파일의 수정 시간을 파일 감지 조건으로 사용하는 것으로 추측됩니다. 수정될 수 있습니다. 문제가 오프라인으로 재현되어 성공적으로 피트가 채워졌습니다!
다음은 피트 채우기 과정에서 확인한 몇 가지 관련 지식 사항을 요약한 것입니다.
opcache 로드
php.ini에 opcache를 추가할 때 확장 대신 zend_extension을 사용해야 합니다. 그렇지 않으면 다음 경고가 표시됩니다.
<code>PHP Warning: PHP Startup: Invalid library (appears to be a Zend Extension, try loading using zend_extension=opcache.so from php.ini) in Unknown on line 0</code>
opcache 구성
더 나은 성능을 얻으려면 다음 권장 설정을 사용하십시오.
<code>opcache.memory_c opcache.interned_strings_buffer=8 opcache.max_accelerated_files=4000 opcache.revalidate_freq=60 opcache.fast_shutdown=1 opcache.enable_cli=1</code>
이번에는 두 가지가 관련됩니다. 매개변수
revalidate_freq, 기본값 2
스크립트 타임스탬프가 업데이트되었는지 확인하는 기간(초)입니다. 0으로 설정하면 OPcache가 각 요청에 대해
validate_timestamps를 확인하게 됩니다. 기본값은 1
입니다. 활성화되면 OPcache는 opcache.revalidate_freq에 설정된 매 초마다 스크립트가 업데이트되는지 확인합니다. 이 옵션이 비활성화된 경우 opcache_reset() 또는 opcache_invalidate() 함수를 사용하여 OPcache를 수동으로 재설정하거나 파일 시스템 변경 사항을 적용하려면 웹 서버를 다시 시작해야 합니다.
시스템 명령 및 기능 stat
액세스 시간은 파일에 마지막으로 액세스한 시간을 나타냅니다.
수정 시간은 파일을 마지막으로 수정한 시간을 나타냅니다.
변경 시간은 파일을 마지막으로 수정한 시간을 나타냅니다. 파일에 액세스한 시간 권한, 크기, 속성 등을 포함한 파일 속성이 변경되는 시간입니다.
C/C에서는 stat 메소드를 사용하여 파일의 세 가지 시간 속성을 쿼리할 수도 있습니다. 일반적으로 애플리케이션입니다. 수정 시간을 사용하여 파일이 업데이트되었는지 확인합니다. 이 함정이 발생하는 이유는 파일이 mv에 의해 작동되고 수정 시간이 업데이트되지 않아 opcache가 업데이트되지 않기 때문입니다.
위에서는 캐시 측면을 포함하여 opcache의 파일 업데이트 감지에 대한 작은 함정을 소개했습니다. PHP 튜토리얼에 관심이 있는 친구들에게 도움이 되기를 바랍니다.