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:
- Zmiana uprawnień, aby bit nie pojawiał się dla określonych ról użytkowników niebędących administratorami.
- 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 ...