어떻게 Drupal 6이 모든 메모리와 충돌을 일으키는 지 확인하는 방법은 무엇입니까?

Question

우리는 Drupal 6을 실행하는 사이트와 Views, CCK 등과 같은 꽤 표준적인 모듈 세트를 가지고 있습니다. 프로덕션 사이트는 잘 돌아가고 있지만 프로덕션 서버의 SQL 덤프를 작성하고 로컬 샌드 박스에 데이터를 가져온 후에 작업이 중단되었습니다.

더 정확하게 말하면, 프론트 페이지를로드하는 것과 같이 샌드 박스의 Drupal 인스턴스에 단일 요청을 한 후, 10-20 개의 httpd 프로세스가 갑자기 시스템의 모든 CPU 및 메모리를 사용하기 시작합니다. 몇 초 안에 모든 mysql 핸들이 모두 사용되었고 사이트는 오프라인 상태가되었습니다. 프로세스는 아파치 전체 아파치를 종료 할 때까지 그들이하고있는 일을 계속할 것이다.

서버에서 출력을 얻을 수 없기 때문에 디버깅 할 수있는 방법을 생각할 수 없습니다. 데이터베이스에 무한 루프를 일으키는 쓰레기가있을 수 있습니까?

여기에 top의 출력 스 니펫이 있습니다. 이는 모두 단일 페이지로드의 결과입니다.

PID USER  PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 
7690 apache 16 0 337m 52m 13m S 27.4 1.4 0:04.42 httpd 
7715 apache 15 0 337m 52m 13m S 24.1 1.5 0:08.69 httpd 
7777 apache 15 0 337m 52m 13m R 20.8 1.4 0:09.94 httpd 
7883 apache 16 0 337m 52m 13m S 19.5 1.5 0:12.39 httpd 
7574 apache 16 0 337m 52m 13m R 17.2 1.4 0:06.30 httpd 
7678 apache 15 0 337m 52m 13m S 16.2 1.4 0:02.26 httpd 
7695 apache 15 0 337m 52m 13m S 15.5 1.4 0:10.29 httpd 
7774 apache 15 0 337m 52m 13m S 15.5 1.4 0:04.62 httpd 
    748 mysql  15 0 364m 67m 5408 S 15.2 1.9 15:37.77 mysqld 
7847 apache 15 0 337m 52m 13m S 14.9 1.4 0:07.10 httpd 
7839 apache 16 0 337m 52m 13m S 14.2 1.4 0:02.85 httpd 
7879 apache 15 0 337m 52m 13m S 13.9 1.5 0:12.65 httpd 
7851 apache 16 0 337m 52m 13m R 12.5 1.4 0:06.77 httpd 
7724 apache 16 0 337m 52m 13m S 12.2 1.4 0:06.62 httpd 
7882 apache 16 0 337m 52m 13m S 11.6 1.5 0:09.04 httpd 
8273 apache 16 0 337m 52m 13m S 9.2 1.4 0:07.30 httpd 
7712 apache 15 0 337m 52m 13m R 8.9 1.4 0:08.13 httpd 
7742 apache 16 0 337m 52m 13m S 8.9 1.4 0:06.74 httpd 
7754 apache 15 0 337m 52m 13m S 8.6 1.4 0:04.16 httpd 
7739 apache 16 0 337m 52m 13m S 8.3 1.4 0:04.51 httpd 
7787 apache 15 0 337m 52m 13m S 8.3 1.4 0:07.44 httpd 
7819 apache 16 0 337m 52m 13m S 7.6 1.4 0:02.03 httpd 
7755 apache 16 0 337m 52m 13m S 7.3 1.4 0:05.89 httpd 
7766 apache 16 0 337m 52m 13m R 7.3 1.4 0:01.12 httpd 
7894 apache 16 0 337m 52m 13m S 7.3 1.4 0:09.49 httpd 
7814 apache 15 0 337m 52m 13m S 5.9 1.4 0:03.88 httpd 
7576 apache 15 0 337m 52m 13m S 5.6 1.4 0:03.63 httpd 
7829 apache 15 0 337m 52m 13m S 5.3 1.4 0:04.17 httpd 
7579 apache 15 0 337m 52m 13m S 5.0 1.4 0:04.43 httpd 
7817 apache 15 0 337m 52m 13m S 4.0 1.4 0:04.60 httpd 
7789 apache 15 0 337m 52m 13m S 2.0 1.4 0:04.41 httpd 
7820 apache 15 0 337m 52m 13m S 1.0 1.4 0:01.57 httpd 

Answer 1

먼저 모든 캐시 테이블을 비워야합니다 (아직 완료되지 않은 경우). 그런 다음 자바 스크립트를 사용하지 않고 웹 사이트에 문의하십시오 (이 경우 ajax 호출을 방지 할 수 있습니다). lynx (브라우저)로 액세스하려고 할 수도 있습니다.

아파치 프로세스 생성이 자바 스크립트가 아니라 내부에서 오는 경우 ... 음, 이는 하나의 PHP scipt가 아파치 프로세스를 스폰하고 있으며 이는 PHP 스크립트의 매우 나쁜 행동 일 수 있으므로 그게 아니라고 생각합니다. .

this one과 같이 Drupal에서 프로파일 링 모듈을 사용해 볼 수 있습니다. 충돌이 발생한 후에는 적어도 보고서 페이지를 쿼리 할 수 ​​있으며 모든 프로파일 링 데이터는 데이터베이스에 저장되고 흥미로운 데이터 (스크린 샷 참조)를보고 할 수 있습니다. 분석 된 데이터가 포함 된 MySQL 테이블을 검사 할 수 있습니다. 모듈 페이지에 액세스 할 수 없습니다.

그렇지 않으면 XDebug를 사용하고 쿼리에서 kcachegrind 파일을 내보낼 수 있지만이 작업은 Drupal 요청으로 읽기가 어려울 수 있습니다.

당신이 요청 된 페이지 (은 자바 스크립트 아니라면 빈 이미지가 예를 들어 SRC 어쩌면 때문에)에서 모든 요청을하지 않는 불을 지르고 확인 할뿐만 아니라 시도 EDIT. 그리고 아파치 로그와 MySQL 로그를 확인하십시오 - 당신은 요청 로깅을 활성화 할 수 있습니다.