Задача Ubuntu по сборке мусора для сеансов PHP занимает 25 минут, почему?

Ubuntu имеет задание cron, которое ищет и удаляет старые сессии PHP:

# Look for and purge old sessions every 30 minutes
09,39 *     * * *     root   [ -x /usr/lib/php5/maxlifetime ] \
   && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 \
   -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir \
   fuser -s {} 2> /dev/null \; -delete

Моя проблема в том, что этот процесс занимает очень много времени для запуска, с большим количеством дискового ввода-вывода. Вот мой график использования процессора:

График использования процессора

Работа по очистке представлена ​​пиками тианов. В начале периода задания по очистке PHP были запланированы по умолчанию по умолчанию 09 и 39 минут. В 15:00 я удалил 39-минутное время из cron, поэтому работа по очистке вдвое больше, чем обычно, (вы можете видеть, что пики получают вдвое больше ширины и вдвое чаще).

Вот соответствующие графики для времени ввода-вывода:

IO time

И операции с дисками:

Операции с дисками

На пике, где было около 14 000 сеансов, можно увидеть, что очистка работает в течение 25 минут, по-видимому, используя 100% одного ядра процессора и, по-видимому, 100% от дискового ввода-вывода для весь период. Почему он так ресурсоемкий? Код ls каталога сеанса /var/lib/php5 принимает всего на долю секунды. Итак, почему для завершения старых сеансов требуется полные 25 минут? Есть ли что-нибудь, что я могу сделать, чтобы ускорить это?

Файловая система для этого устройства в настоящее время ext4 работает на Ubuntu Precise 12.04 64-bit.

EDIT: Я подозреваю, что нагрузка связана с необычным процессом «фьюзер» (поскольку я ожидаю, что простой rm будет проклятый взгляд быстрее, чем производительность, которую я вижу). Я собираюсь удалить использование фьюзера и посмотреть, что произойдет.

12 голосов | спросил thenickdude 30 AM00000060000003931 2012, 06:51:39

5 ответов


8

Удаление fuser должно помочь. В этом задании выполняется fuser (проверьте, открыт ли файл) для каждого найденного файла сеанса , который может занять несколько минут в занятой системе с сеансами 14k. Этот был ошибкой Debian (Ubuntu основан на Debian).

Вместо memcached вы также можете попытаться использовать tmpfs (файловую систему в памяти) для файлов сеанса. Как memcached, это приведет к недействительности сеансов при перезагрузке (это можно обойти, создав резервную копию этого каталога где-нибудь в сценарии завершения работы и восстановив сценарий запуска), но будет намного проще настроить. Но это не поможет с проблемой fuser.

ответил Tometzky 30 PM00000010000001531 2012, 13:03:15
9

Поздравляем вас с тем, что у вас есть популярный веб-сайт и вы все время поддерживаете его работу на виртуальной машине.

Если вы действительно занимаете два миллиона просмотров страниц в день, тогда вы собираете множество PHP-сессий в файловой системе, и они собираются потратить много времени на удаление, независимо от того, используете ли вы fuser или rm или пылесос.

В этот момент я рекомендую вам изучить альтернативные способы хранения ваших сеансов:

  • Один из вариантов: хранить сеансы в memcached . Это молниеносно, но если сервер выходит из строя или перезапускается, все ваши сеансы теряются, и все выходят из системы.
  • Вы также можете хранить сеансы в базе данных. Это будет немного медленнее, чем memcached, но база данных будет постоянной, и вы можете очистить старые сеансы с помощью простого SQL-запроса. Чтобы реализовать это, вы должны написать собственный обработчик сеанса .
ответил Michael Hampton 30 AM00000070000000631 2012, 07:12:06
4

Итак, опции хранения памяти Memcached и базы данных, предлагаемые пользователями здесь, являются хорошим выбором для повышения производительности, каждый из которых имеет свои преимущества и недостатки.

Но при тестировании производительности я обнаружил, что огромная стоимость этого сеанса почти полностью сводится к вызову fuser в работа cron. Вот графики производительности после возврата к заданию Natty /Oneiric cron, которое использует rm вместо fuser, чтобы обрезать старые сеансы, переход происходит в 2:30.

Использование ЦП

Истекшее время ввода-вывода

Операции с дисками

Вы можете видеть, что периодическая деградация производительности, вызванная очисткой сеанса PHP Ubuntu, почти полностью удалена. Шипы, показанные на графике операций с дисками, теперь намного меньше по величине и примерно такие же тощие, как этот график, возможно, могут измеряться, показывая небольшое короткое нарушение, когда ранее производительность сервера значительно ухудшалась в течение 25 минут. Дополнительное использование ЦП полностью устранено, теперь это работа, связанная с IO.

(несвязанное задание ввода-вывода работает в 05:00, а задание ЦП работает в 7:40, которое вызывает их собственные всплески на этих графиках)

Модифицированное задание cron, которое я выполняю сейчас:

09 *     * * *     root   [ -x /usr/lib/php5/maxlifetime ] && \
   [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 \
   -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 \
   | xargs -n 200 -r -0 rm
ответил thenickdude 30 PM00000020000005431 2012, 14:19:54
0

С таким видом трафика вы не должны ставить сеансы на диске. Вы должны использовать что-то вроде memcache. Все, что вам нужно сделать, это настроить php и не потребуется никакого изменения кода. См. Например

http: //www. dotdeb.org/2008/08/25/storing-your-php-sessions-using-memcached/

Причина, по которой это происходит, объясняется огромным количеством файлов, которые он должен сортировать, чтобы узнать, какие из них можно удалить. Memcache может автоматически истечь с учетом вашей длины сеанса, установленной в коде.

ответил Mike 30 AM00000070000004231 2012, 07:11:42
0

Я столкнулся с этим сообщением, проводя некоторые исследования по сеансам. Хотя принятый ответ очень хорош (и вызов фьюзера был удален из сценария gc в течение некоторого времени), я думаю, что стоит отметить несколько других соображений, если кто-то еще столкнется с подобной проблемой.

В описанном сценарии OP использовал ext4. Каталоги в ext4 хранят данные файла в формате базы данных htree - это означает, что незначительное влияние на то, чтобы хранить много файлов в одном каталоге по сравнению с распределением их по нескольким каталогам. Это не относится ко всем файловым системам. Обработчик по умолчанию в PHP позволяет вам использовать несколько подкаталогов для файлов сеанса (но обратите внимание, что вы должны проверить, что процесс управления рекурсивно переводится в эти каталоги - задание cron выше).

Большая часть затрат на операцию (после удаления вызова на фьюзер) возникает из-за просмотра файлов, которые еще не устарели. Используя (например) один уровень поддиректорий и 16 заданий cron, ищущих в каждом подкаталоге (0 /, 1 /, ... d /, e /, f /), будут сглаживать возникающие нагрузки.

Использование специального обработчика сеанса с более быстрым субстратом поможет - но есть много вариантов (memcache, redis, mysql handler socket ...), оставляя в стороне диапазон качества опубликованных в Интернете, который вы выбираете, зависит от о точных требованиях к вашей заявке, инфраструктуре и навыках, а не забывать, что часто возникают различия в обработке семантики (особенно блокировки) по сравнению с обработчиком по умолчанию.

ответил symcbean 3 Mayam18 2018, 01:29:44

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132