Oszczędzające pamięć strategie czyszczenia pamięci podręcznej dla dużych witryn?

Jedna z moich witryn Drupal 7 ma tysiące pól, kilka rodzajów treści, ponad 25 wyświetleń i setki (wkrótce tysiące) typów profili. Z tego powodu używam poprawki podstawowej, która lepiej buforuje informacje o polu encji (http://drupal.org/node/1040790), oraz wersji -dev widoków, która lepiej buforuje widoki poprzez wyświetlanie (zamiast posiadania OGROMNEGO wiersz pamięci podręcznej wyświetleń zawierający wszystkie dane wyświetleń).

Pomogło to załadować większość stron w witrynie przy użyciu 20-30 MB pamięci RAM zamiast 160 MB + (zamiast wyciągania wierszy tabeli cache_ * dla pól i widoków o wielkości 10 MB +, łatki pomagają utrzymać dane cache_ * znacznie bardziej wydajne).

Powoduje to jednak problem polegający na tym, że przebudowywanie pamięci podręcznej zajmuje naprawdę dużo czasu . Zwykle dłużej niż minutę lub dwie. W tym czasie Drupal po prostu nie ładuje żadnych stron (ponieważ pamięci podręczne, z których próbuje odczytać, nie zostały jeszcze zbudowane, inne żądania muszą czekać).

W cyklach o małym natężeniu ruchu nie jest to wielka sprawa; około stu użytkowników będzie musiało poczekać minutę, zanim strona się załaduje. Ale podczas cykli dużego ruchu serwer Apache zaczyna szaleć, z obciążeniem procesora większym niż 40, a pamięć szybko się zapełnia, ponieważ wszystkie wątki robocze czekają i maksymalnie obciążają pamięć, powodując zamianę. To rodzaj spirali śmierci. Ponowne uruchomienie httpd wyczyści wszystko, ale powrót do normalnego stanu zajmuje 5-10 minut.

Moim celem jest, aby czyszczenie pamięci podręcznej nie powodowało upadku witryny na kolana. Po pierwsze, jeśli korzystam z indywidualnych funkcji czyszczenia pamięci podręcznej admin_menu (takich jak „CSS i JS”, ​​następnie „Menu”, a następnie „Rejestr motywów” itp.), Wszystko pójdzie gładko, dopóki nie kliknę opcji „Strona i jeszcze”. To wtedy pamięć podręczna widoków jest resetowana (operacja bardzo intensywna pod względem procesora i bazy danych z liczbą widoków, które muszą być buforowane), a pamięć podręczna informacji o polu jest resetowana (która również wymaga dużej mocy obliczeniowej procesora i bazy danych w tej witrynie).

Więc ... moje pytania / pomysły:

• Czy za pomocą drush i / lub innego skryptu powłoki mogę wyczyścić pamięć podręczną w bardziej inteligentny sposób niż „wysadzić wszystkie pamięci podręczne naraz i mieć nadzieję na czystą przebudowę”?
• Czy mogę blokować żądania HTTP podczas czyszczenia pamięci podręcznej, aby apache nie był blokowany przez kilka żądań znaczników pamięci podręcznej?
• Jeśli mogę wyczyścić pamięć podręczną poza żądaniem Drupal / normal httpd, prawdopodobnie mógłbym ustawić wyższy limit pamięci PHP dla operacji czyszczenia pamięci podręcznej i wycofać mój uniwersalny limit pamięci (teraz ustawiony na 256 MB, na wypadek, gdyby każdy wątek httpd musiał wyczyścić pamięć podręczną ...)

Zasadniczo: Czy istnieje jakiś inteligentny i pełen wdzięku sposób na wyczyszczenie wszystkich pamięci podręcznych za pomocą Drupala, oprócz zwykłego kliknięcia przycisku w interfejsie użytkownika lub użycia drush cc all?

[ Edytuj w celu wyjaśnienia : Głównym problemem, jaki mam, jest przebudowa pamięci podręcznej , która (a) zajmuje trochę czasu i (b) blokuje wszystkie pozostałe żądania do czasu zakończenia przebudowy. Chciałbym znaleźć sposób, aby to zrobić, aby odbudowy nie były tak zabójcze w czasach dużego natężenia ruchu.]

Czy istnieje jakiś inteligentny i pełen wdzięku sposób na wyczyszczenie wszystkich skrzynek za pomocą Drupala, oprócz zwykłego kliknięcia przycisku w interfejsie użytkownika lub użycia drush cc all?

Działania cache moduł robi. To zależy od reguły. Na przykład możesz ustawić regułę, aby wyczyścić określony widok, gdy węzeł typu „x” został dodany lub zaktualizowany. Zapoznaj się z dokumentami, aby uzyskać więcej informacji.

Spójrz także na moduł wdzięku pamięci podręcznej - jeszcze go nie wypróbowałem, ale wygląda interesująco.

Głównym problemem jest to, że używasz MySQL do przechowywania danych w pamięci podręcznej - w przypadku witryn o wysokim obciążeniu jest to bardzo nieskuteczne rozwiązanie.

Radzę zamiast tego użyć Memcache . Zwiększy to znacznie wydajność systemu pamięci podręcznej i zapewni dwie wspaniałe korzyści:

1. Pamięć podręczna jest znacznie szybsza dla operacji odczytu i zapisu, że MySQL - wszystkie operacje pamięci podręcznej (i pełna odbudowa pamięci podręcznej) będą działały szybciej.
2. Ponieważ dane pamięci podręcznej nie są już przechowywane w DB - wyczyszczenie pamięci podręcznej nie zablokuje żadnych innych zapytań MySQL.

Oto przykład konfiguracji Memcache dla Drupala 7.

Czy za pomocą drush i / lub innego skryptu powłoki mogę wyczyścić pamięć podręczną w bardziej inteligentny sposób niż „wysadzić wszystkie pamięci podręczne naraz i mieć nadzieję na czystą przebudowę”?

Jeśli nie chcesz wysadzić wszystkich skrzynek, użyj:, drush cc type_of_cacheaby wyczyścić konkretny lub zdefiniować własny.

Alternatywnie wyczyść ręcznie wszystkie tabele podobne do pamięci podręcznej, np

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

Jeśli używasz memcached (składnia Bash), spróbuj:

pgrep memcached && echo flush_all > /dev/tcp/127.0.0.1/11211

Czy mogę blokować żądania HTTP podczas czyszczenia pamięci podręcznej, aby apache nie był blokowany przez kilka żądań znaczników pamięci podręcznej?

Włącz tryb konserwacji ( drush -y vset maintenance_mode 1), aby uniemożliwić osobom dostęp do witryny. Lub skonfiguruj interfejs, aby przekierowywał gdzie indziej (np. W Varnish, przekierowywanie w Apache lub zmiana .htaccess).

Jeśli mogę wyczyścić pamięć podręczną poza żądaniem Drupal / normal httpd, prawdopodobnie mógłbym ustawić wyższy PHP memory_limitdla operacji czyszczenia pamięci podręcznej i wycofać mój uniwersalny memory_limit(teraz ustawiony na 256 MB, na wypadek, gdyby każdy wątek httpd musiał wyczyścić pamięć podręczną .. .).

Czyszczenie pamięci podręcznej nie zajmuje więcej pamięci, ale odbudowanie pamięci podręcznej po wyczyszczeniu zajmie więcej. Zawsze możesz rozgrzać pamięć podręczną, uruchamiając crona lub otwierając dowolną stronę, np

time php -n -d memory_limit=-1 time $(which drush) cc registry
PHP_OPTIONS='-d memory_limit="2G"' drush cron
php -d memory_limit=1G ./scripts/drupal.sh http://localhost/

^{Określ, -naby ignorować php.iniprzetwarzanie, które może dodatkowo przyspieszyć proces czyszczenia pamięci podręcznej.}

Może to pociągać za sobą koszty pieniężne, ale możesz użyć konfiguracji serwera buforującego, takiego jak Varnish. Plusem jest to, że Varnish będzie obsługiwał twoją stronę, podczas gdy pamięć podręczna jest czyszczona na serwerze produkcyjnym, bez mądrzejszego użytkownika.

Wada: w zależności od liczby sekund / minut przestoju serwera produkcyjnego w porównaniu z ustawieniami limitu czasu VCL, Varnish może się zaktualizować w tym czasie i zobaczysz ekran błędu Varnish 503.

Ale to podejście wraz z Redis lub Memcache może pomóc.