`drush cc all` 명령이 너무 오래 걸리는데 어떻게해야합니까?

내 사이트 drush cc all에서 실행하는 데 4 분 이상이 걸립니다. 사이트 db는 몇 GB입니다. 그러나 왜 그렇게 오래 걸리는지에 대한 명확한 이유를 알 수 없습니다. 병목을 찾으려면 어떻게해야합니까?

캐시 자체를 지우는 것은 캐시 테이블을 자르기 때문에 오래 걸리지 않습니다. 그 후 시간이 가장 많이 걸리는 것은 캐시 레지스트리를 다시 작성하는 것입니다. 일반적으로 테마 파일은 모든 새 후크 및 모든 Drupal 폴더에서 새 템플릿 파일을 검색하고, 새 모듈 및 클래스 파일 용 파일을 검색하는 시스템 등을 검색합니다.

drush cc theme-registry또는 다른 것을 지정하여 언제든지 특정 캐시를 지울 수 있습니다 .

처리 속도를 높이려면 PHP 캐싱 메커니즘 (예 : OPCache, XCache 등)을 사용하는 것이 좋습니다. 또한 SQL 테이블 (예 : memcached 또는 redis)의 사용량이 많은 메모리 기반 캐시이므로 캐시를 비우는 것만으로도 캐시를 지우는 데 시간이 걸리지 않습니다 (예 : echo flush_all > /dev/tcp/127.0.0.1/11211Bash).

또는 다음과 같이 항상 캐시를 수동으로 지울 수 있습니다 .

echo "SHOW TABLES LIKE 'cache%'" | $(drush sql-connect) | tail -n +2 | xargs -L1 -I% echo "DELETE FROM %;" | $(drush sql-connect) -v

디버깅

가장 시간이 오래 걸리는 것을 확인하려면 디버깅 / 프로파일해야합니다 (예 : XDebug, XHProf, phpdbg, dtrace).

OS X / Unix에서 dtrace(실행 후 drush) 다음을 수행 할 수 있습니다 .

sudo dtrace -qn 'php*:::function-entry { printf("%Y: PHP function-entry:\t%s%s%s() in %s:%d\n", walltimestamp, copyinstr(arg3), copyinstr(arg4), copyinstr(arg0), basename(copyinstr(arg1)), (int)arg2); }'

리눅스에서 strace, 예를 들어

strace -e trace=sendto,recvfrom -s1000 -p $(pgrep php)

특정 사항을 찾으려면 eg :를 추가하십시오 strace ... 2>&1 | grep -C5 UPDATE.

매우 큰 데이터베이스가 있고 캐시 지우기를 수행하지 않을 때 시스템이 제대로 실행중인 경우 설정을 완전히 지원하기에 메모리가 부족할 수 있습니다.

사이트가 Linux 상자에서 실행중인 경우, 쉘에서 'top'을 실행하고 shift-M을 눌러 사용 된 메모리별로 프로세스 목록을 정렬하십시오. 그런 다음 다른 터미널에서 캐시 지우기 작업을 실행하십시오. mysql과 apache가 목록의 맨 위로 올라가는 것을 볼 수 있습니다. 이러한 각 프로세스에서 사용중인 총 메모리의 백분율과 사용 가능한 RAM의 양을 확인할 수 있습니다. 많은 양의 가상 공간이 있지만 모든 실제 RAM이 소진 된 경우이 작업으로 인해 VM 메모리가 스 래시되어 실행 시간이 평소보다 적은 부분으로 줄어들 수 있습니다.

한 번, 나는 트래픽이 많은 Drupal 사이트를 설치하기에 충분한 메모리가있는 상자에서 실행했습니다. 관련이 적은 트래픽이 많은 사이트에서 캐시 지우기를 실행했을 때 캐시를 다시 작성하면 시스템이 한계를 넘어서고 모든 것이 잠겼습니다. 따라서 전체 시스템 동작이 중요합니다. 이것이 바로 'top'과 같은 간단한 도구를 시작하기에 편리한 이유입니다.

@ greg_1_anderson에 동의하지 않을 것입니다.

에서 시스템이 완전히 충돌 cc all하지 않으면 일반적인 메모리 문제가 있다고 생각하지 않습니다. LAMP 서버의 메모리가 부족하면 스왑이 발생합니다. 활성 서버 스왑을 사용하면 악의가 발생할 수 있습니다. httpd 프로세스는 시스템 속도 저하로 인해 쌓이기 시작합니다 (스왑으로 인해 시스템이 매우 느리게 작동 함). 그러면 더 많은 스왑이 사용됩니다. 그리고 활발한 httpd 프로세스들.

시스템이 결국 돌아 오면 제대로 조정되지 않은 것 같습니다. drush cc all많은 데이터베이스 액세스가 발생하므로 문제가 더 많이 발생한다고 생각합니다. 내 제안은 사이트 에서 mysqltuner 를 실행 하는 것입니다. 당신은 멀티 기가 바이트의 데이터베이스가있는 경우, 내 생각 엔 당신의 것입니다 innodb_buffer_pool_size심지어 원격으로 크기가 올바르지 않습니다, 그리고 MySQL의 인스턴스는 탈곡이다. 또한 데이터베이스 풋 프린트를 더 작게 유지하기 위해 대체 캐시 백엔드를 조사 할 것입니다.

웹 호스팅 환경 일 수 있습니다. 로컬 설정 또는 공유 호스팅 또는 VPS / 서버에서 호스팅되는 것을 참조하고 있습니까?

• 호스팅 환경 -공유 웹 호스팅을 사용하는 경우 Drupal / drush에서 사용할 수있는 메모리 양이 제한됩니다. https://drupal.org/node/207036
• 최대 실행 시간 -증가해야 함

이 솔루션은 완벽한 솔루션이 아니며 지연의 원인을 식별하는 데 도움이되는 도구가 하나 더 있습니다.

top프로세스를 모니터링 하는 데 사용 하는 것 외에도 mytop유익한 결과가 나올 수 있습니다 . (위의 다른 답변은 MySQL을 가정하지만 다른 DB 백엔드를 사용하는 경우 mytop을 동등한 도구로 교체해야합니다.)

mytop단순히 SHOW FULL PROCESSLIST루프에서 MySQL 을 실행 하고 어떤 쿼리가 실행되고 있는지 보여 주므로 시간이 많이 걸립니다. 캐시 지우기가이 테이블 또는 해당 테이블을 정리하는 데 시간이 오래 걸리는 경우 여기에 무엇이 들어 있는지 정확히 알 수 있습니다. 설치 권한이 없다면 mytop쉘에서 조잡한 버전을 수행하십시오-

while true; do mysql -e 'SHOW FULL PROCESSLIST' && sleep 5 && clear ; done

지연이 MySQL 쿼리에서 비롯되지 않은 경우이 도구는 최소한이를 확인합니다.

Drupal 7에서 Speed ​​Up Cache Clearing 이라는 블로그 게시물 이 캐시 지우기 프로세스에서 속도를 늦추는 부분을 정확히 좁히는 데 매우 유용한 것으로 나타났습니다. 기능 모듈 및 엔티티 API 모듈 에서 지적한 문제 는 내 사이트에 영향을 미쳤지 만 게시물에 자세히 설명 된 프로세스를 통해 Drupal 코어 및 중단 점 모듈 에서 발생한 문제를 추적 할 수있었습니다 .

프로세스를 완료하는 데 약간의 시간이 걸리지 만 캐시 지우기를 몇 분에서 1 분 미만으로 줄이는 데 도움이되었습니다.