PHP 세션에 대한 Ubuntu의 가비지 수집 크론 ​​작업을 실행하는 데 25 분이 걸립니다. 왜 그렇습니까?

우분투에는 오래된 PHP 세션을 찾고 삭제하는 크론 작업이 있습니다.

# Look for and purge old sessions every 30 minutes
09,39 *     * * *     root   [ -x /usr/lib/php5/maxlifetime ] \
   && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 \
   -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir \
   fuser -s {} 2> /dev/null \; -delete

내 문제는이 프로세스가 많은 디스크 IO와 함께 실행하는 데 오랜 시간이 걸린다는 것입니다. 내 CPU 사용량 그래프는 다음과 같습니다.

정리 실행은 청록색 스파이크로 표시됩니다. 이 기간이 시작될 때 PHP 정리 작업은 기본 09 분과 39 분에 예약되었습니다. 15:00에 나는 cron에서 39 분 시간을 제거 했으므로 크기의 두 배인 정리 작업은 절반으로 자주 실행됩니다 (피크는 두 배 넓고 절반은 빈번하게 나타납니다).

IO 시간에 해당하는 그래프는 다음과 같습니다.

디스크 작업 :

약 14,000 개의 세션이 활성화 된 정점에서 정리는 CPU의 한 코어의 100 %와 전체 기간 동안 디스크 IO의 100 % 인 것으로 보이는 25 분 전체에 걸쳐 실행되는 것으로 볼 수 있습니다. 왜 자원 집약적입니까? ls세션 디렉토리는 /var/lib/php5두 번째의 일부에 불과 걸립니다. 그렇다면 왜 오래된 세션을 다듬는 데 25 분이 걸립니까? 이 속도를 높이기 위해 할 수있는 일이 있습니까?

이 장치의 파일 시스템은 현재 Ubuntu Precise 12.04 64 비트에서 실행중인 ext4입니다.

편집 : 나는로드가 비정상적인 프로세스 "퓨저"때문이라고 생각합니다 (단순히 rm내가보고있는 성능보다 빠른 광경을 기대하기 때문에 ). 퓨저 사용을 제거하고 어떻게되는지 보겠습니다.

제거 fuser하면 도움이됩니다. 이 작업은 fuser찾은 모든 세션 파일에 대해 명령 (파일이 현재 열려 있는지 확인)을 실행 합니다.이 세션은 14k 세션이있는 바쁜 시스템에서 몇 분이 걸릴 수 있습니다. 이것은 데비안 버그였습니다 (우분투는 데비안 기반입니다).

memcached 대신 세션 파일에 tmpfs (메모리의 파일 시스템)를 사용하려고 할 수도 있습니다. memcached와 마찬가지로 재부팅시 세션이 무효화됩니다 (이 스크립트는 종료 스크립트의 어딘가에이 디렉토리를 백업하고 시작 스크립트에서 복원하여 해결할 수 있음). 그러나 fuser문제에 도움이되지 않습니다 .

인기있는 웹 사이트를 보유하고이 사이트를 항상 가상 머신에서 계속 실행하도록 축하합니다.

당신이 정말로 하루에 이백 만 페이지 뷰 당기는 경우에, 당신은 파일 시스템에서 PHP 세션을 많이 쌓아거야, 그들은 전혀 사용 여부를 문제 삭제하는 데 시간이 오래 걸릴 겁니다 fuser하거나 rm또는를 진공 청소기.

이 시점에서 세션을 저장하는 다른 방법을 살펴 보는 것이 좋습니다.

• 한 가지 옵션은에 세션memcached 을 저장하는 것입니다 . 매우 빠르지 만 서버가 충돌하거나 다시 시작하면 모든 세션이 손실되고 모든 사람이 로그 아웃됩니다.
• 세션을 데이터베이스에 저장할 수도 있습니다. 이것은 memcached보다 약간 느리지 만 데이터베이스는 영구적이며 간단한 SQL 쿼리로 오래된 세션을 지울 수 있습니다. 그러나이를 구현하려면 사용자 정의 세션 핸들러 를 작성 해야 합니다 .

따라서 여기서 사용자가 제안한 Memcached 및 데이터베이스 세션 스토리지 옵션은 각각 고유 한 이점과 단점이있는 성능을 향상시키기위한 좋은 선택입니다.

그러나 성능 테스트를 통해이 세션 유지 관리에 드는 막대한 성능 비용이 fuser크론 작업 의 요구에 거의 달랐다는 것을 알았 습니다. 여기에 사용하는 단정 한 / Oneiric 크론 작업에 복귀 한 후 성능 그래프의 rm대신 fuser트림 된 세션의 전환은 2시 30 분 발생합니다.

우분투의 PHP 세션 청소로 인한 주기적 성능 저하가 거의 완전히 제거되었음을 알 수 있습니다. 디스크 작업 그래프에 표시된 스파이크의 크기는 이제 훨씬 작아졌으며이 그래프가 측정 할 수있을 정도로 얇아서 이전의 서버 성능이 25 분 동안 크게 저하 된 작은 중단을 보여줍니다. 추가 CPU 사용량이 완전히 제거되었으며 이제는 IO 바인딩 작업입니다.

(관련되지 않은 IO 작업은 05:00에 실행되고 CPU 작업은 7:40에 실행되며이 두 그래프에서 자체 스파이크가 발생 함)

현재 실행중인 수정 된 cron 작업은 다음과 같습니다.

09 *     * * *     root   [ -x /usr/lib/php5/maxlifetime ] && \
   [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 \
   -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 \
   | xargs -n 200 -r -0 rm

세션에 대한 조사를 할 때이 게시물을 보았습니다. 수락 된 답변은 매우 훌륭하지만 (퓨저 호출은 gc 스크립트에서 얼마 동안 제거되었습니다.) 다른 사람이 비슷한 문제를 겪어야하는 경우 몇 가지 다른 고려 사항에 주목할 가치가 있다고 생각합니다.

설명 된 시나리오에서 OP는 ext4를 사용하고있었습니다. ext4의 디렉토리는 파일 데이터를 htree 데이터베이스 형식으로 저장합니다. 즉, 여러 디렉토리에 파일을 분배하는 것과 비교하여 단일 디렉토리에 많은 파일을 보유하는 경우 무시할만한 영향이 있습니다. 모든 파일 시스템에 적용되는 것은 아닙니다. PHP의 기본 핸들러를 사용하면 세션 파일에 여러 개의 하위 디렉토리를 사용할 수 있습니다 (그러나 제어 프로세스가 해당 디렉토리로 반복되는지 확인해야합니다. 위의 cron 작업은 그렇지 않습니다).

퓨저 호출을 제거한 후 작업 비용이 많이 발생하면 아직 오래되지 않은 파일을 볼 때 발생합니다. 예를 들어 단일 레벨의 서브 디렉토리 및 각 서브 디렉토리 (0 /, 1 /, ... d /, e /, f /)를보고있는 16 개의 크론 작업을 사용하면 발생하는로드 범프가 완만 해집니다.

더 빠른 인쇄물과 함께 사용자 정의 세션 처리기를 사용하면 도움이되지만 인터넷에 게시 된 품질의 범위를 제외하고 선택할 수있는 많은 옵션 (memcache, redis, mysql handler socket ...)이 있습니다. 응용 프로그램, 인프라 및 기술과 관련된 요구 사항은 기본 처리기와 비교하여 의미 처리 (특히 잠금) 처리에 자주 차이가 있다는 것을 잊지 마십시오.

이런 종류의 트래픽을 사용하면 세션에 세션을 배치해서는 안됩니다. memcache와 같은 것을 사용해야합니다. PHP를 설정하기 만하면 코드를 변경할 필요가 없습니다. 예를 들어보십시오

http://www.dotdeb.org/2008/08/25/storing-your-php-sessions-using-memcached/

시간이 오래 걸리는 이유는 삭제할 수있는 파일을보기 위해 정렬해야하는 파일의 양이 많기 때문입니다. Memcache는 코드에서 설정 한 세션 길이에 따라 자동으로 만료됩니다.