3 주 전에 Drupal 7.14에서 7.15로 전환했기 때문에 매우 복잡한 메모리 제한 오류가 발생했습니다 . 이러한 오류는 성능 캐시를 지우거나 업데이트 스크립트를 실행하려고 할 때마다 발생합니다.

내 호스팅 회사는 php.ini의 메모리 제한을 126M, 256M, 512M, 심지어 1024M까지 늘 렸습니다. 그러나 오류는 여전히 발생합니다. 사이트를 공유에서 VPS로 마이그레이션했지만 오류가 여전히 발생합니다. 나는 앞으로 나아갈 방법이없고 모른다.

오류는 다음과 같습니다.

• 치명적인 오류 : 416 행의 /home/example/public_html/sites/all/modules/views/views.module에서 536870912 바이트의 허용 된 메모리 크기 (30 바이트 할당 시도)

• 치명적인 오류 : 2736 행의 /home/example/public_html/includes/menu.inc에서 536870912 바이트의 허용 된 메모리 크기 (108 바이트 할당 시도)

• 치명적인 오류 : 59 행의 /home/example/public_html/sites/all/modules/chain_menu_access/chain_menu_access.module에서 허용 된 메모리 크기 536870912 바이트 (71 바이트 할당 시도)

• 93 줄의 /home/example/public_html/sites/all/modules/views/includes/base.inc에 64 바이트 할당)

Drupal 메모리 문제와 함께 마지막으로 벽에 머리를 두들 겼습니다. 다음은 주제에 대한 수집 된 지식입니다.

1. 뷰는 많은 메모리를 사용할 수 있습니다

나는 일부보기 (및 패널과 CTools와 merlinofchaos가 그의 강력한 손가락으로 만지는 모든 것을 좋아한다)하지만 많은 메모리를 사용하는 여러 관계로 구성을 만들 수 있습니다. 보기를 사용 중지하고 메모리 문제가 사라지면 잘못 구성된보기가 문제의 원인 일 수 있습니다.

View 인 경우 어떻게해야합니까, 실제로 해당 View가 작동하려면 어떻게해야합니까? 시작하려면 코드에 코드를 넣으십시오 (대량 내보내기 또는 기능을 참조하십시오. 아래를 참조하십시오. 성능이 거의 향상되지 않도록보기와 유사한 기능을 직접 코딩했습니다). 또 다른 생각은 View를 다른 방법으로 다시 실행하는 것입니다. 궁극적으로 얻는 것이 분류법 용어 인 경우 View를 작성할 때보기 유형이 분류법보기인지 확인하십시오. 분류법 용어를 얻기 위해 관계를 사용하는 컨텐츠 뷰를 작성하지 마십시오.

또한 패널에서 많은 메모리를 사용한다고 가정 할 수도 있습니다. 실제로 벤치마킹하지 않았으므로 확인할 수 없습니다.

2. 데이터베이스에서 코드로 물건을 옮기는 것은 좋은 습관입니다

Drupal 사이트에서이를 실현하는 데는 몇 가지 시간이 걸렸지 만 데이터베이스에서 UI를 통해 생성 된 모든 항목 (특히 뷰 및 패널 구성)을 유지하는 것은 Drupal 최악의 사례입니다. 왜? 데이터베이스에 대한로드가 증가하고 버전 제어가 불가능합니다. 첫 번째 요점은 메모리 사용 측면에서 특히 문제가됩니다. 데이터베이스에서 View의 콘텐츠를로드하는 대신 사이트에서 뷰 구성 요소 자체를로드해야합니다. 이것은 Drupal이 테이블을 사용하는 방식에 의해 악화됩니다. Drupal 기능의 각 비트는 새로운 테이블을 사용하여 일부 요청이 bajillion 테이블을 결합하는 결과를 가져옵니다. 이것은 컴퓨터 과학 사람들에게 탈장 (캐비티 : 링크는 어리 석음)을 제공하지만 Drupal처럼 모듈 식 및 사용자 친화적 인 소프트웨어를 사용하면 피할 수 없습니다.

해결책? 대량 내보내기 (CTools에 포함) 또는 기능 을 사용하여 현재 데이터베이스에 상주 하는 코드 비트를 모듈 코드로 패키지하십시오.

3. 테마는 또한 기억을 먹을 수 있습니다

테마에 많은 템플릿 파일 (예 : themename / templates /의 파일)이 있습니까? 그렇다면 해당 파일 중 하나가로드 될 때마다 메모리가 사용됩니다. Drupal 비트가 표시되지 않도록하기 위해 특별히 템플릿을 작성하는 경우 다음 중 하나를 시도하십시오.

1. 특정 비 관리 사용자 역할에 대해 비트가 표시되지 않도록 권한을 변경합니다.
2. CSS를 사용하여 요소 숨기기

첫 번째 선택은 분명히 보안에 영향을주는 것들을 위해하고 싶은 것입니다. CSS를 사용하여 특정 사용자에 대한 "편집"버튼을 숨기고 Firebug 등을 통해 숨기려는 경우 만 있습니다.

4. contrib 모듈을 오버 보드하지 마십시오

때때로 사이트에는 많은 contrib 모듈이 필요하지만, 배 밖으로 가지 마십시오. 각 활성화 (참고 : 활성화. 비활성화 된 모듈은 메모리를 사용하지 않음) 모듈은 메모리를 사용합니다. 이것은 약간 명백하지만, 상관없이 주목할 가치가 있습니다.

5. VPS는 (때로는) 거짓말입니다

필자의 경험에 따르면 일부 부도덕 한 호스팅 회사 는 Drupal 사이트를 VPS 서버로 푸시하는 것을 좋아합니다. 더 비싸고 더 많은 WordPress 웹 사이트를위한 공유 호스팅 공간을 확보합니다. 웹 호스트가 공유 호스팅에 대한 메모리 상한을 광고하지 않는 경우가 많기 때문에 상황이 악화됩니다.

아아, 종종 사이트에 트래픽이 많지 않고 여전히 충돌하는 경우 문제는 Drupal의 구성과 관련이있을 수 있습니다. 사용자를 VPS로 푸시하면 물을 흐릿하게 처리하고 처리 할 변수를 더 추가 할 수 있습니다 (웹 서버 구성, PHP 구성, VPS 게스트 구성, VPS 호스트 구성 등).

6. 다른 모든 것이 실패하면 localhost에 복제하고 막대기로 치십시오

이것이 사람들이 버전 제어와 함께 dev-staging-production 방법론을 사용하는 큰 이유입니다. 다른 모든 것이 실패하면 DB 덤프를 수행하고 사이트를 로컬 테스트 서버에 git clone 한 다음 사이트를 왕실로 엉망으로 만들 수 있습니다 프로덕션 서버에서 실제로 무언가를 망칠 염려없이 테스트 서버.

메모리 문제의 경우 이는 일반적으로 문제를 일으키는 모듈이 노출 될 때까지 모듈을 하나씩 비활성화하는 것을 의미합니다. 또한 웹 호스트 관련 문제를 지적 할 수 있습니다. 메모리가 128MB와 같이 합리적인 메모리로 설정된 로컬 설치에서 사이트가 완벽하게 실행되면 웹 호스트에 문제가 있음을 알 수 있습니다.

tl; dr

내 직감은 chain_menu_access가 문제를 일으키는 것입니다. 이를 비활성화하고 캐시를 지우십시오. 작동하는지 확인하십시오.

나는 시도 할 다른 것들을 생각할 때이 답변에 추가 할 것입니다 ...

XHProf 또는 Xdebug의 내장 프로파일 러와 같은 PHP 프로파일 러를 넣어 요청에서 발생하는 상황을 검사 할 수 있습니다.

뷰는 메모리 호그입니다. Drupal의 캐싱이 도움이 될 수 있습니다. Drupal은 테이블을 만들거나 매달릴 수있는 다른 객체가있는 경우에만 활성 모듈을로드합니다. 제거 만하면 대부분의 아티팩트가 제거됩니다. 우리는 drupal의 승인 / 권한을 사용하고 자체 모듈을 작성합니다. 최고는 아니지만 성능이 훨씬 좋고 조정하기 쉽습니다. 우리는 WP에 대해서도 마찬가지입니다.

필자의 경우 메모리 제한 문제는 캐시 시스템 (부스트 및 부스트 만료 모듈)에 의해 생성되었습니다. 이것은 모듈 또는 뷰를 업데이트하는 문제를 제공합니다. 비활성화 된 Boost 모듈은 모두 정상적으로 작동합니다.