Команда `drush cc all` займає занадто багато часу, що я можу зробити?

На мінному майданчику працює drush cc allбільше 4 хвилин. ДБ сайту - кілька ГБ. Однак я не бачу чіткої причини, чому це забирає занадто багато часу. Що я можу зробити, щоб знайти шийку пляшки?

Самостійне очищення кешу не займе багато часу, оскільки це просто обрізка таблиць кешу. Найбільше потребує часу - це відновлення кеш-реєстру після цього. Зазвичай це реєстр тем, який сканує всі нові гачки та всі ваші папки Drupal на нові файли шаблонів, система, яка сканує файли для нових модулів та файлів класів тощо.

Ви завжди можете очистити певний кеш, вказавши drush cc theme-registryабо будь-який інший.

Настійно рекомендується використовувати механізм кешування PHP (наприклад, OPCache, XCache тощо) для пришвидшення обробки. І кеш на основі пам'яті, щоб замінити велике використання таблиць SQL (наприклад, memcached або redis), тому очищення кешу не займе часу, просто промивши кеш (наприклад, echo flush_all > /dev/tcp/127.0.0.1/11211у Bash).

Крім того, ви завжди можете очистити кеш вручну , наприклад:

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

Налагодження

Щоб перевірити, що конкретно займає найбільше часу, вам потрібно налагодити / профілювати це (наприклад, XDebug, XHProf, phpdbg, dtrace).

Для OS X / Unix цього можна досягти за допомогою dtrace(після запуску 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); }'

У Linux використовуйте strace, наприклад,

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

Щоб шукати якісь конкретні речі, спробуйте додати напр .: strace ... 2>&1 | grep -C5 UPDATE.

Якщо у вас дійсно велика база даних, і ваша система працює нормально, коли ви не робите кеш-пам'ять, ймовірно, у вас недостатньо пам'яті, щоб повністю підтримувати налаштування.

Якщо ваш веб-сайт працює у вікні Linux, запустіть 'top' (з оболонки) та натисніть shift-M, щоб сортувати список процесів за використаною пам'яттю. Потім запустіть операцію очищення кеш-пам'яті з іншого терміналу. Ви повинні побачити, що mysql і apache піднімаються на вершину списку. Ви зможете побачити, який відсоток загальної пам’яті використовує кожен із цих процесів та скільки вільної оперативної пам’яті. Якщо у вас є велика кількість віртуального простору, але вся фізична оперативна пам’ять вичерпана, ця операція може спричинити треш пам'яті VM, що може зменшити час вашого виконання до невеликої частини того, що це нормально.

Одного разу я запускав веб-сайт Drupal серед трафіку на коробці без достатньої кількості пам'яті для підтримки налаштування. Коли я запустив очищення кешу на незв’язаний сайт з низьким трафіком, відновлення кешу підштовхнуло систему до її межі, і все, крім заблокованого. Отже, тут важлива загальна поведінка системи; саме тому прості інструменти, такі як "верх", - це зручне місце для початку.

Я не погоджуся (дещо) з @ greg_1_anderson тут.

Якщо система не повністю виходить з ладу під час cc all, я не думаю, що у вас загальна проблема з пам'яттю. Коли на сервері LAMP не вистачає пам’яті, він натисне своп. Активний сервер, що вдаряє свопом, спричинить помилку. Процеси httpd почнуть складатись через уповільнення роботи системи (своп робить роботу системи дуже повільною), що призведе до використання більше свопів тощо. На сайтах, де я бачив це, я побачив би завантаження процесу 100, і багато активних процесів httpd.

Якщо ваша система врешті повернеться, то, я думаю, ви погано налаштовані. drush cc allце призведе до великої кількості доступів до бази даних, тому я думаю, що це більше показує проблему. Моєю пропозицією було б запустити mysqltuner на сайті. Якщо у вас є база даних з декількома ГБ, я гадаю , що ваш innodb_buffer_pool_sizeрозмір навіть не віддалений належним чином, а ваш екземпляр MySQL обмолот. Я також досліджував би альтернативний кешбек, щоб спробувати зменшити слід бази даних.

Це може бути ваше середовище веб-хостингу. Ви маєте на увазі локальне налаштування або щось хостинг на спільному хостингу або VPS / сервер?

• середовище хостингу - якщо ви перебуваєте на спільному веб-хостингу, обсяг пам’яті, яку можуть використовувати Drupal / drush, буде обмежений див. https://drupal.org/node/207036
• Максимальний час виконання - потрібно збільшити

Це не повне рішення, лише ще один інструмент, який допоможе визначити джерело затримок.

Окрім використання topдля моніторингу процесів, ви можете знайти mytopінформаційний результат. (Інші відповіді вище припускають MySQL, але якщо ви використовуєте інший бекенд БД, вам потрібно буде поміняти mytop на еквівалентний інструмент.)

mytopпросто виконує MySQL SHOW FULL PROCESSLISTв циклі і показує, які запити виконуються (так що забирають багато часу). Якщо очищення кешу потребує тривалого очищення тієї чи іншої таблиці, ви побачите, що саме тут тримає речі. Якщо у вас немає доступу до встановлення mytop, просто зробіть грубу версію в оболонці -

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

Якщо затримка не випливає з запитів MySQL, то цей інструмент може принаймні підтвердити це для вас.

Я виявив, що повідомлення в блозі під назвою « Швидке очищення кешу» на Drupal 7 дуже корисне для того, щоб точно зменшити, яка частина процесу очищення кешу сповільнювала роботу. Проблеми, які він визначає в модулі функцій та модулі api сутності , впливали на мій сайт, але процес, детально описаний у публікації, також допоміг мені відслідковувати проблеми, з якими ми стикалися в ядрі Drupal та модулі зупинок .

Щоб пропрацювати процес, потрібен певний час, але це допомогло мені зменшити кількість кеш-пам’яті з декількох хвилин до менше хвилини.