Apache 2 под наблюдением

Вступление

Уже написано немало постов на просторах интернета, о мониторинге веб-сервера Apache. При вводе такой фразы, как «мониторинг нагрузки apache» в строке поиска Google, результаты поиска указывают на полезнейший модуль mod_status. А также о еще большей полезности этого модуля в сочетании с perl-расширениями. А если еще и немного пропатчить эти perl-расширения — то вообще супер система получается. Но настроив такую систему — системный администратор на этом, как правило, не останавливается, ему уже необходимо история нагрузки по серверу в целом, потом по каждому хосту, а далее и с точностью до скрипта. И чтоб потом сравнить можно было, а как раньше было, а как теперь нагрузка распределяется.
И вот здесь на помощь может прийти модуль для веб-сервера Apache — mod_performance.

Вступление

Продолжу цикл статей на тему «Apache 2.x под наблюдением. Мониторинг загрузки системы веб-сервером». Опять же под рассмотрением остается известный ранее[2] модуль Apache — mod_performance. На время написания этой статьи на сайте модуля[1] была выложена для доступа новая версия модуля — 0.2. Дальнейшее повествование в статье будет по принципу «Вопрос-Ответ».

Очень часто господа системные администраторы сталкиваются с проблемой просмотра загрузки операционной системы, и если большинству в общем то знакомы системы мониторинга на стандартных операционных системах, то в системе Solaris — это часто вызывает много вопросов и сомнений, особенно в выводах команд пугающих своими цифрами. Сегодня попробуем немного в этом разобраться.

Парадигма MVC во многом позволяет упростить поддержку кода за счет разделения логики и создания абстракций, однако часто, следуя принципу Thick Model & Thin Controller (он же Fat Model & Skinny Controller), разработчикам приходится упираться в краеугольный камень использования любого объекта-модели, а именно — в потребление памяти. Что особенно актуально при работе с моделями, которые реализуют ORM (или ActiveRecord паттерн).
В данной статье хочу вкратце продемонстрировать стандартные подходы к решению данной проблемы.

Нет, здесь не будет ничего из серии «Аааа, я сделал malloc (new), и забыл сделать free (delete)!»
Здесь будет нечто изощренное: мы будем отрезать кусочки памяти по чуть-чуть, прятать их в укромное место… А когда операционная система заплатит выкуп скажет «Хватит!», мы попробуем вернуть все обратно. Казалось бы, простейшая операция выделения и освобождения памяти — ничего не предвещает беды.
Тем кому интересно как уничтожить забить память — прошу под хабракат

Недавно мне довелось разобраться и устранить несколько утечек памяти в популярном фреймворке Торнадо. Не беда, если вы никогда его не использовали, потому что описанное будет мало связано с ним. Рассказать я хочу о методах, которые я использовал для поиска и устранения утечек.

Все сказанное будет по большей части справедливо только для самой популярной реализации Питона — CPython. Как известно, в нем есть два механизма освобождения памяти. Первый из них — подсчет ссылок. Каждый раз, когда вы явно или не явно создаете новый объект, его счетчик ссылок равен единице. Если вы присваиваете этот объект новой переменной или передаете в качестве аргумента, его счетчик ссылок увеличивается. При выходе из функции количество ссылок на объекты, которые были в локальных переменных и аргументах, уменьшается. Если для какого-то объекта количество ссылок становится равным нулю, он немедленно уничтожается.

Это схема отлично работает до тех пор, пока не появляются объекты, ссылающиеся друг на друга. Самый простой пример — узлы какого-то дерева, хранящие ссылки на свои дочерние и родительский узлы. Узлы продолжат ссылаться друг на друга, даже когда не останется других внешних ссылок ни на один из них. Самое неприятное, что такие узлы могут ссылаться на какие-то другие данные и не давать их освободить. Чтобы устранить такие циклические ссылки, в Питоне существует второй механизм освобождения памяти — сборщик мусора. Он запускается время от времени, ставя выполнение остального кода на паузу, и анализирует все неосвобожденные объекты.

Формально, циклические ссылки нельзя назвать утечками: сборка мусора рано или поздно уничтожит такие объекты. Беда только в том, что Питон не может сам определить, когда еще рано, а когда уже поздно. В моем случае система просто прибивала процесс с Питоном, если сборка мусора не начиналась вовремя.

Существует полезный и нужный инструмент для мониторинга PHP под названием pinba. Он позволяет собирать статистику по выполнению PHP-скриптов вашего проекта. Мы реализовали небольшую систему, которая дополняет Pinba, и назвали ее Pinboard (Pinba board).

Суть работы

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

Возможность сделать снимок (или дамп) памяти виртуальной машины Java — это инструмент, ценность которого сложно переоценить. Файл дампа содержит копии всех Java объектов, находившихся в памяти в момент снимка. Формат файла хорошо известен, и существует множество инструментов, которые умеют с ним работать.