Komenda `drush cc all` zajmuje zbyt dużo czasu, co mogę zrobić?

12

drush cc allUruchomienie w moim miejscu zajmuje ponad 4 minuty. Db witryny to kilka GB. Nie widzę jednak wyraźnego powodu, dla którego to trwa zbyt długo. Co mogę zrobić, aby zlokalizować szyjkę butelki?

awm
źródło
Sprawdź pierwszy dziennik kwerendy MySQL: drupal.stackexchange.com/questions/75629/…
AgA
Czy masz uruchomionego crona?
mpdonadio
Tak, mam uruchomionego crona. Strona jest ogólnie wolna. Tyle starszego kodu, że nie warto ponownie faktorować.
awm
Zgadzam się z @MPD tutaj, nie sądzę, że jest to związane z pamięcią. MySQL jest także tylko jednym z możliwych powodów. Jest tylko jeden sposób, aby się dowiedzieć i jest to profilowanie. Najłatwiej to zrobić, używając rozszerzenia xhprof i devel, które działa również z drush (użyj -d, aby zobaczyć link do raportu). Domyślam się, że istnieje wiele problemów. Typowym problemem, jeśli strona jest powolna dla wszystkich żądań, brakuje modułów, patrz drupal.stackexchange.com/questions/724/why-is-drupal-7-so-slow . Widoki mają również poważne problemy z wydajnością pamięci podręcznych, patrz drupal.org/node/1944674 .
Berdir
Dziękuję, pomyślałem, że muszę przeprowadzić profilowanie, ale w przypadku bazy kodu drupal zawsze trudno jest zidentyfikować wąskie gardło. Chociaż powiedziałem, że strona jest powolna, nie jest zbyt wolna i nie ma nic przeciwko, jest nieproporcjonalnie wolniejsza.
awm

Odpowiedzi:

6

Samo czyszczenie pamięci podręcznej nie zajmuje dużo czasu, ponieważ po prostu obcina tabele pamięci podręcznej. Najwięcej czasu zajmuje odbudowanie rejestru pamięci podręcznej. Zwykle jest to rejestr motywów, który skanuje wszystkie nowe zaczepy i wszystkie foldery Drupal w poszukiwaniu nowych plików szablonów, system skanujący pliki w poszukiwaniu nowych modułów i plików klas i tym podobne.

Zawsze możesz wyczyścić określoną pamięć podręczną, podając ją drush cc theme-registrylub dowolną inną.

Zaleca się użycie mechanizmu buforowania PHP (np. OPCache, XCache itp.), Aby przyspieszyć przetwarzanie. Pamięć podręczna oparta na pamięci, aby zastąpić duże obciążenie tabel SQL (np. Memcached lub redis), więc wyczyszczenie pamięci podręcznej nie zajmie czasu, tylko przez opróżnienie pamięci podręcznej (np. echo flush_all > /dev/tcp/127.0.0.1/11211W Bash).

Alternatywnie możesz zawsze wyczyścić pamięć podręczną ręcznie , np .:

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

Debugowanie

Aby sprawdzić, co zajmuje najwięcej czasu, musisz go debugować / profilować (np. XDebug, XHProf, phpdbg, dtrace).

W systemie OS X / Unix można to osiągnąć dtrace(po uruchomieniu drush):

sudo dtrace -qn 'php*:::function-entry { printf("%Y: PHP function-entry:\t%s%s%s() in %s:%d\n", walltimestamp, copyinstr(arg3), copyinstr(arg4), copyinstr(arg0), basename(copyinstr(arg1)), (int)arg2); }'

W systemie Linux użyj stracenp

strace -e trace=sendto,recvfrom -s1000 -p $(pgrep php)

Aby wyszukać określone rzeczy, spróbuj dodać np strace ... 2>&1 | grep -C5 UPDATE. :

kenorb
źródło
5

Jeśli masz naprawdę dużą bazę danych, a system działa poprawnie, gdy nie wykonujesz czyszczenia pamięci podręcznej, prawdopodobnie nie masz wystarczającej ilości pamięci, aby w pełni obsługiwać konfigurację.

Jeśli twoja strona działa na Linux-ie, uruchom „top” (ze swojej powłoki) i naciśnij Shift-M, aby posortować listę procesów według używanej pamięci. Następnie uruchom operację czyszczenia pamięci podręcznej z innego terminala. Powinieneś zobaczyć mysql i apache wznoszące się na górę listy. Zobaczysz, jaki procent całkowitej pamięci używa każdy z tych procesów i ile wolnej pamięci RAM jest używane. Jeśli masz dużo przestrzeni wirtualnej, ale cała fizyczna pamięć RAM jest wyczerpana, ta operacja może spowodować przeładowanie pamięci VM, co może skrócić czas wykonywania do niewielkiej części tego, co zwykle.

Kiedyś prowadziłem witrynę Drupal o średnim natężeniu ruchu na komputerze z / poza wystarczającą ilością pamięci do obsługi instalacji. Kiedy uruchomiłem czyszczenie pamięci podręcznej w niepowiązanej witrynie o niskim natężeniu ruchu, odbudowanie pamięci podręcznej spowodowało, że system przekroczył swój limit i wszystko zostało zablokowane. Dlatego ważne jest tutaj całkowite zachowanie systemu; dlatego proste narzędzia, takie jak „top”, są przydatne na początek.

greg_1_anderson
źródło
Dzięki, myślę, że podstawową przyczyną jest to, że strona była już od jakiegoś czasu, db jest trochę duży i kod strasznie potrzebuje faktoringu. Na przykład operacja usunięcia węzła zajmuje około 3 sekund. Myślę, że dawanie zbyt dużej ilości pamięci może być zbędne, zgadzasz się?
awm
Mam go na swoim komputerze i jest również powolny. Podwoiłem pamięć, do 1 GB, i zsynchronizowałem ją z czasem „drush cc all”. Niewiele lepiej ma tylko 4s szybciej.
awm
1
Tak, jeśli cała strona jest wolna przez cały czas, nawet z dużą ilością pamięci, to CC nie stanowi problemu; będziesz musiał zrobić bardziej ogólne profilowanie.
greg_1_anderson
Ponadto, jeśli witryna jest naprawdę stara i wymaga odświeżenia, rozważ przebudowę od nowa za pomocą świeżych modułów i użyj migracji drupal-to-drupal ( drupal.org/project/migrate_d2d ), aby przenieść zawartość.
greg_1_anderson
2

Nie zgadzam się (nieco) z @ greg_1_anderson tutaj.

Jeśli system nie zawiesza się całkowicie podczas cc all, nie sądzę, że masz ogólny problem z pamięcią. Kiedy na serwerze LAMP zabraknie pamięci, nastąpi zamiana. Aktywna zamiana trafień serwera spowoduje awarię. Procesy httpd zaczną się nakładać ze względu na spowolnienie systemu (swap powoduje, że system działa bardzo wolno), co spowoduje użycie większej liczby zamian itp. W witrynach, w których to widziałem, obciążenie procesu wynosi 100, i mnóstwo aktywnych procesów httpd.

Jeśli twój system w końcu wróci, myślę, że jesteś źle dostrojony. drush cc allspowoduje dużo dostępu do bazy danych, więc myślę, że to pokazuje problem bardziej. Moją sugestią byłoby uruchomienie mysqltuner na stronie. Jeśli masz bazę danych o pojemności wielu GB, domyślam się, że nie masz innodb_buffer_pool_sizenawet odpowiedniego rozmiaru, a instancja MySQL jest niesamowita. Zbadałbym również alternatywne zaplecze pamięci podręcznej, aby spróbować zmniejszyć rozmiar bazy danych.

mpdonadio
źródło
Dzięki, drupal jest używany tylko do użytku z edytorami, które mają warstwę servie, która ma lakier. Użytkownicy przechodzą teraz do drupal. Chcę tylko zbadać, co się dzieje, ponieważ uważam, że istnieje wąskie gardło. Myślę, że moim najlepszym rozwiązaniem jest włączenie powolnego dziennika mysql i monitorowanie db. A potem zrobić kilka profili z XDebug
AWM
POKAŻ PEŁNĄ LISTĘ PROCESÓW powie ci, co się dzieje bez potrzeby korzystania z wolnego dziennika zapytań (a więc bez restartu serwera). Zobacz także inną odpowiedź dla mytop.
Chris Burgess,
1

Może to być twoje środowisko hostingowe. Masz na myśli lokalną konfigurację, czy coś hostującego na hostingu współdzielonym lub VPS / serwerze?

  • środowisko hostingowe - jeśli korzystasz z hostingu współdzielonego, ilość pamięci, którą Drupal / drush może użyć, będzie ograniczona patrz: https://drupal.org/node/207036
  • maksymalny czas wykonania - należy zwiększyć
geekgirlweb
źródło
drush zwykle nie jest ograniczony przez max_execution_time. Możesz jednak zrobić drush php-eval "print ini_get('max_execution_time');"to dwukrotnie.
mpdonadio
1

To nie jest kompletne rozwiązanie, tylko jedno narzędzie, które pomoże zidentyfikować źródło twoich opóźnień.

Oprócz używania topdo monitorowania procesów możesz znaleźć mytopinformacje. (Inne powyższe odpowiedzi zakładają, że MySQL, ale jeśli używasz innego zaplecza DB, musisz zamienić mytop na równoważne narzędzie).

mytoppo prostu wykonuje MySQL SHOW FULL PROCESSLISTw pętli i pokazuje, które zapytania są wykonywane (co zajmuje dużo czasu). Jeśli czyszczenie pamięci podręcznej zajmuje dużo czasu, aby wyczyścić ten lub inny stół, zobaczysz dokładnie, co tu trzyma. Jeśli nie masz dostępu do instalacji mytop, po prostu zrób surową wersję w swojej powłoce -

while true; do mysql -e 'SHOW FULL PROCESSLIST' && sleep 5 && clear ; done

Jeśli opóźnienie nie wynika z zapytań MySQL, to narzędzie może to dla ciebie przynajmniej potwierdzić.

Chris Burgess
źródło
1

Znalazłem wpis na blogu zatytułowany Przyspieszenie czyszczenia pamięci podręcznej na Drupal 7, który był bardzo pomocny w zawężeniu tego, która część procesu czyszczenia pamięci podręcznej spowalniała proces. Problemy, które wskazuje w module funkcji i module interfejsu API encji, miały wpływ na moją witrynę, ale proces opisany w poście pomógł mi również wyśledzić problemy, które napotkaliśmy w module rdzenia Drupala i punktów przerwania .

Cały proces zajmuje trochę czasu, ale pomogło mi zredukować czyszczenie pamięci podręcznej z wielu minut do mniej niż minuty.

Matt V.
źródło