Trzy tygodnie temu przeszedłem z Drupala 7.14 na 7.15 i dlatego napotykam serię bardzo wyrafinowanych (jak dla mnie) błędów limitu pamięci . Te błędy występują za każdym razem, gdy próbuję wyczyścić pamięć podręczną wydajności lub uruchomić skrypty aktualizacji.

Moja firma hostingowa zwiększyła limit pamięci w php.ini do 126 M, 256 M, 512 M, a nawet 1024 M. Ale błędy nadal występują. Przeprowadziłem migrację mojej witryny z udostępnionej do VPS, ale błąd nadal występuje niewiarygodnie. Nie mam sposobu i nie mam pojęcia, jak iść naprzód.

Oto błędy:

• Błąd krytyczny: dozwolony rozmiar pamięci 536870912 bajtów wyczerpany (próba przydzielenia 30 bajtów) w /home/example/public_html/sites/all/modules/views/views.module on line 416

• Błąd krytyczny: Dozwolony rozmiar pamięci 536870912 bajtów wyczerpany (próbowano przydzielić 108 bajtów) w /home/example/public_html/includes/menu.inc w linii 2736

• Błąd krytyczny: Dozwolony rozmiar pamięci 536870912 bajtów wyczerpany (próba przydzielenia 71 bajtów) w /home/example/public_html/sites/all/modules/chain_menu_access/chain_menu_access.module w linii 59

• przydziel 64 bajty) w /home/example/public_html/sites/all/modules/views/include/base.inc w linii 93

Ostatnio waliłem głową o ścianę z powodu problemów z pamięcią Drupala. Oto moja zebrana wiedza na ten temat:

1. Widoki (mogą) zużywać dużo pamięci

Uwielbiam niektóre widoki (i panele, narzędzia CTools i wszystko, czego merlinofchaos dotyka swoimi potężnymi, potężnymi palcami), ale możliwe jest tworzenie konfiguracji z wieloma relacjami, które wykorzystują dużo pamięci. Jeśli wyłączysz swoje Widoki, a problem z pamięcią zniknie, prawdopodobnie przyczyną problemu jest źle skonstruowany Widok.

Co zrobić, jeśli jest to widok, a naprawdę potrzebujesz go do działania? Spróbuj umieścić go w kodzie (za pośrednictwem eksportera zbiorczego lub funkcji; patrz poniżej. Ręcznie kodowałem funkcjonalność podobną do widoku, aby poprawić wydajność z niewielkim powodzeniem) na początek. Inną myślą jest powtórzenie widoku w inny sposób - jeśli ostatecznie otrzymujesz warunki taksonomiczne, upewnij się, że typem widoku jest widok taksonomiczny podczas jego tworzenia; nie twórz Widoku treści, który wykorzystuje relacje do uzyskania warunków taksonomicznych.

Warto również wspomnieć o tym, że Panele podobno używają dużo pamięci - tak naprawdę nie przeprowadziłem testów, więc nie mogę tego potwierdzić.

2. Przenoszenie rzeczy z bazy danych do kodu jest bardzo dobrą praktyką

Zrozumienie tego zajęło mi kilka witryn Drupal, ale trzymanie wszystkiego, co zostało utworzone za pomocą interfejsu użytkownika w bazie danych (szczególnie konfiguracje widoków i paneli) jest najgorszą praktyką Drupala. Dlaczego? Zwiększa obciążenie bazy danych i nie można kontrolować wersji. Pierwszy punkt jest szczególnie problematyczny pod względem wykorzystania pamięci - zamiast po prostu ładować zawartość z widoku z bazy danych, witryna musi również ładować same komponenty widoku. Sytuację pogarsza sposób, w jaki Drupal korzysta z tabel: poprzez abstrakcję wszystkiego do n-tego stopnia, każda część funkcjonalności Drupala wykorzystuje nową tabelę, co powoduje, że niektóre żądania łączą tabele bajillionów. Daje to ludziom przepuklinę informatyki (zastrzeżenie: link jest głupi), ale tak naprawdę nie można go uniknąć za pomocą oprogramowania tak modułowego i przyjaznego dla użytkownika, jak Drupal.

Rozwiązanie? Użyj programu Bulk Exporter (dołączony do CTools) lub funkcji, aby spakować fragmenty kodu aktualnie znajdującego się w bazie danych jako kod modułu.

3. Tematy mogą także jeść pamięć

Czy Twój motyw ma wiele plików szablonów (tj. Pliki w temacie nazwa / szablony /)? Jeśli tak, pamięć jest zużywana przy każdym załadowaniu jednego z tych plików. Jeśli tworzysz szablony specjalnie w celu ukrycia wyświetlania fragmentów Drupala, spróbuj:

1. Zmiana uprawnień, aby bit nie pojawiał się dla określonych ról użytkowników niebędących administratorami.
2. Używanie CSS do ukrywania elementów.

Pierwszym wyborem jest oczywiście to, co chcesz zrobić dla rzeczy wpływających na bezpieczeństwo - nie chcesz używać CSS, aby ukryć przycisk „edytuj” dla niektórych użytkowników, tylko po to, aby je potem odkryli za pomocą Firebug lub cokolwiek innego.

4. Nie przesadzaj z modułami contrib

Chociaż czasami strona potrzebuje wielu modułów contrib, nie przesadzaj. Każdy włączony (uwaga: włączony. Wyłączone moduły nie używają pamięci) moduł wykorzystuje pamięć. Jest to nieco oczywiste, ale warte odnotowania niezależnie.

5. VPS jest (czasem) kłamstwem

Z mojego doświadczenia wynika , że niektóre pozbawione skrupułów firmy hostingowe uwielbiają próbować pchać witryny Drupal na serwery VPS - są one droższe i zwalniają współdzieloną przestrzeń hostingową dla coraz większej liczby stron WordPress. Sytuację pogarsza fakt, że hosty często nie reklamują się (a nawet chętnie powiedzą, jeśli zostaniesz zapytany), jaki jest górny limit pamięci dla hostingu współdzielonego.

Niestety, często jeśli witryna nie jest obciążona dużym ruchem i nadal ulega awarii, problem prawdopodobnie ma coś więcej wspólnego z konfiguracją Drupala niż cokolwiek innego. Popychanie użytkownika do VPS po prostu moczy wody i dodaje więcej zmiennych, z którymi trzeba sobie poradzić (czy to konfiguracja serwera WWW? Konfiguracja PHP? Konfiguracja gościa VPS? Konfiguracja hosta VPS, nawet?).

6. Kiedy wszystko inne zawiedzie, sklonuj do localhost i pobij go kijem

Jest to duży powód, dla którego ludzie używają metodologii tworzenia etapów tworzenia i kontroli wersji - gdy wszystko inne zawiedzie, możesz zrobić zrzut bazy danych, sklonować witrynę na lokalnym serwerze testowym, a następnie po królewsku zepsuć witrynę na testowanie serwera bez obawy, że faktycznie coś zepsujesz na serwerze produkcyjnym.

W przypadku problemów z pamięcią oznacza to ogólnie wyłączenie modułów jeden po drugim, dopóki nie zostanie ujawniony ten, który spowodował problem. Może również wskazywać na problemy związane z hostingiem - jeśli strona działa idealnie w lokalnej instalacji z pamięcią ustawioną na coś rozsądnego, na przykład 128 MB, to wiesz, że twój webhost jest zepsuty.

tl; dr

Mam przeczucie, że przyczyną problemu jest chain_menu_access. Spróbuj to wyłączyć i wyczyścić pamięć podręczną, sprawdź, czy to działa.

Dodam również do tej odpowiedzi, gdy myślę o innych rzeczach do wypróbowania ...

Możesz spróbować umieścić profiler PHP taki jak XHProf lub wbudowany profiler Xdebug, aby sprawdzić, co dzieje się w żądaniu.

Widoki to świnia pamięci. Buforowanie Drupala może pomóc. Drupal ładuje moduły aktywne tylko wtedy, gdy tworzą tabele lub mają inne obiekty, które mogą się zawiesić. Tylko odinstalowanie usunie większość artefaktów. Korzystamy z autoryzacji / uprawnień drupala i piszemy w nim własne moduły. Nie najlepsze, ale wydajność jest znacznie lepsza i łatwiejsza do dostrojenia. To samo robimy dla WP.

W moim przypadku problem z limitem pamięci został wygenerowany przez system pamięci podręcznej (moduły Boost i Boost Expire). Daje mi to problem z aktualizacją modułu lub widoków. Po wyłączeniu modułów Boost wszystkie działają dobrze.