PHP Opcache 캐 시 리 셋,코드 리 셋 으로 코드 를 업데이트 할 수 없 는 문제 해결

문제 배경
Opcache 의 캐 시 최 적 화 를 사용 하여 PHP 코드 를 Opcode 캐 시 로 미리 컴 파일 하여 공유 메모리 에 프로 세 스 를 반복 적 으로 호출 하여 디스크 에서 PHP 코드 를 분석 하 는 시간 소 모 를 줄 이 고 PHP 성능 을 현저히 향상 시 키 며 업무 성능 을 향상 시 켰 습 니 다.그러나 일부 문 제 는 우리 가 매번 해당 하 는 PHP 코드 를 업데이트 한 후에웹 서버 는 업 데 이 트 된 코드 에 즉시 불 러 올 수 없습니다.
해결 방안
(1),Opcache 스 크 립 트 검증 시간 설정
Opcache 아래 두 설정 옵션 을 변경 하여 코드 재 부팅 시간 을 조정 할 수 있 습 니 다.
opcache.revalidate_freq=0 스 크 립 트 타임 스탬프 에 업데이트 주기 가 있 는 지 확인 합 니 다.초 단위 입 니 다.(0 으로 설정 하면 모든 요청 에 대해 OPcache 에서 스 크 립 트 업 데 이 트 를 검사 합 니 다)
opcache.validate_timestamps=0 을 사용 하면 opcache.revalidatefreq 가 설정 한 초 수 는 스 크 립 트 가 업데이트 되 었 는 지 확인 합 니 다.
PS:실제 생산 환경 에서 가능 한 한 최상의 성능 을 위해 파일 업데이트 검증 을 열지 않 습 니 다.검증 할 때마다 공유 메모리 에 PHP 코드 를 다시 미리 컴 파일 하기 때 문 입 니 다.
(2),다시 시작|php-fpm 프로 세 스 다시 불 러 오기
php-fpm 프로 세 스 를 다시 시작 하거나 다시 시작 할 때마다 PHP 스 크 립 트 파일 을 다시 처리 하지만 fpm 프로 세 스 를 다시 시작 하면 요청 이 중단 되 어 더러 운 데 이 터 를 쓰 거나 트 랜 잭 션 스크롤 백 등 일련의 이상 을 초래 할 수 있 습 니 다.
재 부팅 에 비해 순 조 롭 고 사용자 의 요청 이 직접 중단 되 지 않 으 며 상대 적 으로 위험 이 낮 습 니 다.그러나 phop-fpm 는 reload 신 호 를 받 으 면 모든 하위 프로 세 스에 SIGGUIT 신 호 를 보 내 고 타 이 머 를 등록 합 니 다.정 해진 시간 내 에 하위 프로 세 스 가 종료 되 지 않 았 습 니 다.이 어 SIGTERM 신 호 를 보 내 하위 프로 세 스 를 끝 냅 니 다.1 초 안에 하위 프로 세 스 가 끝나 지 않 으 면 SIGKILL 을 보 내 강제로 죽 입 니 다.
php-fpm 다시 시작

service php-fpm restart

php-fpm 다시 불 러 오기

services php-fpm reload

  kill -USR2 `cat /usr/local/php/var/run/php-fpm.pid`

(3)캐 시 수 동 청소
위의 두 가지 방식 을 제외 하고 좀 더 안정 적 인 캐 시 청 소 를 할 수 있 습 니 다.우 리 는 opcache 를 통 해reset()와 opcacheinvalidate()함수 로 Opcache 캐 시 를 새로 고 칩 니 다.opcache_reset() -전체 Opcode 캐 시 를 리 셋 하면 모든 PHP 스 크 립 트 가 다시 해석 되 고 Opcode 로 사전 컴 파일 됩 니 다.opcache_invalidate()-지 정 된 스 크 립 트 캐 시 를 지우 면 두 개의 인 자 를 전달 할 수 있 습 니 다.하 나 는 파일 경 로 를 새로 고 치 는 것 이 고 하 나 는 force 필드 입 니 다.force 가 FALSE 를 설정 하지 않 거나 들 어 오 면 스 크 립 트 의 수정 시간 이 Opcode 에 대응 하 는 시간 보다 업 데 이 트 될 때 만 스 크 립 트 의 캐 시가 효력 을 잃 습 니 다.
주의해 야 할 것 은 PHP 가 PHP-FPM 으로 실 행 될 때 opcache 의 캐 시 는 phop 명령 을 통 해 지 울 수 없습니다.http 또는 cgi 에서 phop-fpm 프로 세 스 로 만 캐 시 를 지 울 수 있 습 니 다.우 리 는 대외 인 터 페 이 스 를 만들어 캐 시 를 지 울 수 있 습 니 다.
관련 실현 은 다음 과 같다(프레임 워 크:laravel).

Route::any('cache-reset', function () {
  //    Opcode  
  dd(opcache_reset());
});

Route::any('cache-update', function () {
  //              
  exec('git diff --name-only HEAD~ HEAD', $output);
  foreach ($output as $file) {
    $path = base_path($file);
    opcache_invalidate($path, true);
  }
  dd('    ');
});

총결산
위의 세 가지 정책 을 통 해 Opcache 캐 시 업데이트 의 목적 을 실현 할 수 있 습 니 다.그러나 트 래 픽 절정 기 나 대 트 래 픽 서버 에 서 는 캐 시 를 업데이트 할 때마다 자원 이 매우 손실 되 는 일 입 니 다.Opcache 는 캐 시 를 재 구축 할 때 다른 프로 세 스 의 읽 기 를 금지 하지 않 습 니 다.이 로 인해 반복 적 으로 새 캐 시 를 만 들 수 있 기 때문에 가장 좋 은 성능 을 얻 으 려 고 합 니 다.
4.567917.절정 기 에 캐 시 를 정리 하지 않 는 것 이 좋 습 니 다.4.567918.

절정 기 에 코드 를 자주 업데이트 하지 말고 캐 시 를 정리 하면 새 캐 시 를 반복 할 수 있 습 니 다

4.567917.업데이트 가 필요 하 다 면 서버 의 가중치 를 약화 시 키 고 하나하나 업데이트 하 는 목적 을 실현 하려 고 시도 할 수 있다4.567917.강제 업데이트 가 필요 하 다 면 캐 시 를 수 동 으로 제거 하 는 방식 을 선택 하여 Opcache 캐 시 를 재 구축 하여 대 가 를 최소 화 합 니 다이상 은 PHP Opcache 캐 시 리 셋,코드 리 셋 으로 코드 를 업데이트 할 수 없 는 문 제 를 해결 하 는 상세 한 내용 입 니 다.더 많은 PHP Opcache 캐 시 리 셋,코드 리 셋 에 관 한 자 료 는 저희 의 다른 관련 글 을 주목 하 십시오!