shoorick

Каталистовое приложение жрёт достаточно много памяти

Конечно, это можно пытаться обойти, перезапуская дочерние процессы сервера после обработки определённого количества запросов, но это как-то не со совсем правильно: уже после пары десятков запросов каждый процесс съедает до 150 метров, а когда процессы жиди подольше и запускались через mod_perl, апачные процессы раздувались ещё сильнее.

С другой стороны, более правильным методом было бы устранение утечек, а не отстрел процессов. Для этого есть куча методов: например, на xpoint.ru лежит список модулей, помогающих обнаружить утечки памяти. Попробовал запустить сервер, используя Devel::LeakTrace::Fast — всё затормозилось: только запуск ждать пришлось минут десять, если не больше, а отрисовка страницы занимала от одной до трёх минут. В результате в STDERR вывалился здоровенный список дырявых мест, причём бóльшая их часть — не в нашем приложении, а во внешних модулях.

Что делать — непонятно. Для начала, думаю, надо посмотреть и разобраться, что же мы сами-то написали.

Ускоряем каталистовый сайт, переписываем слишком медленные запросы с DBIx::Class на обычный DBI. Попутно допилил напильником каталистовую модель, чтобы она поддерживала UTF-8 в MySQL, о чём и написал в ru_catalyst. Кому надо — пользуйтесь.

За давностию лет уж позабыл, каково ставить каталист. Пришлось вспомнить. Часть модулей в портах отсутствует (включая Lingua::RU::Inflect, чью версию 0.03 всё никак не доделаю).

Попутно обнаружил странное: некоторые мелкие модули с первого раза не ставятся. Из-за этого не ставятся большие. Попутно у системы срывает крышу: pkg_version считает, что модуль не установлен, но portinstall его ставить отказывается, ссылаясь на то, что он якобы уже есть. Приходится, стуча в бубен и матерясь, идти в /usr/ports/portname и собирать командой make. А иногда помогал и просто повторный запуск portinstall. Почему так — не знаю.

На прошлой неделе начал ставить перломодули, необходимые нашему каталистовому мегаизделию — сегодня закончил:

# grep p5- 100521-all.txt | wc -l
       1
# grep p5- 100525-all.txt | wc -l
     241

Оно запустилось. Правда, пишет бред. Но это уже другой вопрос.

upd/22:50: Надо всё-таки почитать документацию по правильным методам развёртывания перловых приложений, чтобы не устраивать подобных бубнений в будущем.

Это я такое написал? Проще уж на обычном SQL писать...

$c->stash->{'checkpoints'} = [
    $c->model($MODEL)->search(
        {
            'stgroup_id.id'           => $student->stgroup_id->id,
            'checkresults.student_id' => [ $student->id, undef ],
        },
        {
            'select'   => [ \'me.name cpname', qw/me.id me.date max_ball/ ],
            'join'      => [
                'checkresults', {
                    'tss_id' => [
                        qw/stgroup_id subject_id/,
                        { 'teacher_id' => 'user_id' }
                    ],
                }
            ],
            '+columns'  => [
                qw/subject_id.name checkresults.ball/,
                qw/user_id.fname user_id.sname user_id.lname/,
            ],
#             '+as'       => [ qw/subject_name ball/ ],
            'order_by'  => [ qw/date/ ],
        },
    )
];

Предыдущие замеры производительности каталистовых серверов были не вполне чисты: на некоторых серверах использовалась тестовая версия БД, на некоторых — боевая. Хоть обе базы живут на одной машине и управляются одни SQL-сервером, их содержимое не совпадает. Понятно, что различие в содержимом может оказывать влияние на скорость — надо было сразу взять напильник в руки и настроить все серверы на использование одной и той же версии базы.

Сегодня протестировал с одинаковой базой — выяснил, что скорости апача и nginx + Catalyst::Engine::HTTP::Prefork совпадают. Более того, апач иногда проигрывает несколько процентов. Получается, что выбор не той базы давал апачу незаслуженное преимущество, достигавшее нескольких десятков процентов.

В итоге данные заметно поменялись: ( И теперь график выглядит так: )

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

proxy_set_header   Host             $host;
proxy_set_header   X-Real-IP        $remote_addr;
proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
proxy_set_header   X-Forwarded-Host $http_host;
proxy_set_header   X-Forwarded-Port $http_port;

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

Если не сделать такой настройки, то каталистовая функция uri_for будет возвращать ссылки на адреса бэкенда, который посетителю показывать совсем не надо.

Теперь осталось убедиться в корректной работе получившейся связки, проверить способность нгинкса к старту при загрузке системы — и можно будет запускать весь этот комбайн в космос боевую эксплуатацию.

Удалось запустить подопытный сайт через nginx+FastCGI. Предварительно пришлось поставить p5-FastCGI-ProcManager, который почему-то не был автоматически поставлен при установке каталиста и обновить libtool, без которого FastCGI::ProcManager не желал ставиться.

Наблюдается интересная картина: производительность, судя по результатам работы ab, в 2–2,5 раза хуже, чем при использовании Apache+mod_perl (но во столько же лучше, чем у каталистового тестового сервера), однако расход памяти заметно ниже: апач на каждый процесс сразу отъедал около 60 метров памяти, процессы размножались и раздувались (до 200 метров на процесс — легко!), потребляя в сумме несколько гигабайт (стремясь сожрать всю доступную память: и физическую, и виртуальную); при использовании FastCGI всё не так: запускается всего 2 процесса со сходными аппетитами на память, один из них ничего не делает, зато другой делает, видимо, всё остальное:

$ top

  PID USERNAME THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
72718 as         1 125    0 57400K 49068K RUN    1   0:55 74.72% perl
72715 as         1   8    0 56896K 44720K wait   0   0:03  0.00% perl

Статичные файлы, как можно догадаться, раздаются непосредственно nginx'ом. Лёгкие файлы (например, иконка весом менее килобайта) выдаются раза в 2 быстрее, чем апачем, тяжёлые (например, prototype.js — больше 100 кБ) — примерно с одинаковой скоростью.

Поглядев на терзание сервера баз данных нашей поделкой, решил попробовать другой метод: DBIx::Class, вроде бы, позволяет выполнять произвольный SQL-запрос. Запрос-то я написал и протестировал, да вот подсунуть его каталисту пока не получается...

Пойду-ка домой, ужинать и читать мануалы.

niskam написал в ru_perl: Кэширование подшаблонов в Template Toolkit. В посте есть ссылка на статью Рэндела Шварца «Profiling in Template Toolkit via overriding», где описан способ оценки производительности отдельных шаблонов на сайте, работающем с использованием Template::Toolkit. Я попробовал применить метод на каталистовом сайте — работает, измеряет.

Зная номер порта, на котором работает каталистовый отладочный сервер, все его экземпляры легко можно загасить без использования мыши и ручного набора PIDов:

ps -ax | grep p\ номер_порта | grep -v grep | cut -f1 -d' ' | xargs kill -сигнал