Приветствую!

Есть ли выработанный подход к оптимизации веб-сервера? У меня
следующая ситуация: есть сайт с приличной посещаемостью (около 20к
посетителей в сутки, 200-300к просмотров). Основная нагрузка в рабочее
время. По статистике в среднем php скрипт отрабатывает от 0.1с до
0.3с.

Сервер DELL PE1950, 2 x Quad Core Xeon L5320, 4GB RAM, 4x 73GB SAS
(2xRAID1

Работает на связке php-fpm+nginx+mysql5.1. Переехал на нее с апача,
т.к. нагрузка на сервер была уже пиковой.

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

Здесь - статистика мунина img508 . imageshack . us / img508 /
9740/62882059 . jpg. mysql в какой то момент обнулился, т.к. отключили
в скриптах в принципе обращение к БД.

Как на ваш взгляд? Что вызывает подозрение? С чего начинать копать?
Порекомендуйте методику для оптимизации сервера.

а почему запросов к MySQL нету, но он продолжает колбасить кучу тредов?

2010/1/13 Dmitry Prostoy <dmitry.prostoy@gmail.com>

> Приветствую!
>
> Есть ли выработанный подход к оптимизации веб-сервера? У меня
> следующая ситуация: есть сайт с приличной посещаемостью (около 20к
> посетителей в сутки, 200-300к просмотров). Основная нагрузка в рабочее
> время. По статистике в среднем php скрипт отрабатывает от 0.1с до
> 0.3с.
>
> Сервер DELL PE1950, 2 x Quad Core Xeon L5320, 4GB RAM, 4x 73GB SAS
> (2xRAID1
>
> Работает на связке php-fpm+nginx+mysql5.1. Переехал на нее с апача,
> т.к. нагрузка на сервер была уже пиковой.
>
> После переезда очень порадовала стабилизация загрузки памяти - на
> уровне 1.3гб, и процессора (в пике - 25%). Сервер стал работать в
> целом также гораздо стабильнее, но не так хорошо как хотелось бы. Т.к.
> по природе своей я перфекционист - очень хотелось бы оттюнить сервер
> до близкого к идеалу состояния - уверен что сделать это можно. Прошу
> вашей экспертной помощи в этом.
>
> Здесь - статистика мунина img508 . imageshack . us / img508 /
> 9740/62882059 . jpg. mysql в какой то момент обнулился, т.к. отключили
> в скриптах в принципе обращение к БД.
>
> Как на ваш взгляд? Что вызывает подозрение? С чего начинать копать?
> Порекомендуйте методику для оптимизации сервера.

Запросы я отключил во всех скриптах. сейчас сайт полностью работает,
но не пишет и не читает БД - благо функционал позволяет это сделать в
тестовых целях
А почему треды колбасит - сам удивляюсь. Возможно phpfpm по дефолту
создает на всякий пожарный? :)

On 14 янв, 01:26, Dima Golovchenko <dimago...@gmail.com> wrote:
> а почему запросов к MySQL нету, но он продолжает колбасить кучу тредов?
>
> 2010/1/13 Dmitry Prostoy <dmitry.pros...@gmail.com>
>
> > Приветствую!
>
> > Есть ли выработанный подход к оптимизации веб-сервера? У меня
> > следующая ситуация: есть сайт с приличной посещаемостью (около 20к
> > посетителей в сутки, 200-300к просмотров). Основная нагрузка в рабочее
> > время. По статистике в среднем php скрипт отрабатывает от 0.1с до
> > 0.3с.
>
> > Сервер DELL PE1950, 2 x Quad Core Xeon L5320, 4GB RAM, 4x 73GB SAS
> > (2xRAID1
>
> > Работает на связке php-fpm+nginx+mysql5.1. Переехал на нее с апача,
> > т.к. нагрузка на сервер была уже пиковой.
>
> > После переезда очень порадовала стабилизация загрузки памяти - на
> > уровне 1.3гб, и процессора (в пике - 25%). Сервер стал работать в
> > целом также гораздо стабильнее, но не так хорошо как хотелось бы. Т.к.
> > по природе своей я перфекционист - очень хотелось бы оттюнить сервер
> > до близкого к идеалу состояния - уверен что сделать это можно. Прошу
> > вашей экспертной помощи в этом.
>
> > Здесь - статистика мунина img508 . imageshack . us / img508 /
> > 9740/62882059 . jpg. mysql в какой то момент обнулился, т.к. отключили
> > в скриптах в принципе обращение к БД.
>
> > Как на ваш взгляд? Что вызывает подозрение? С чего начинать копать?
> > Порекомендуйте методику для оптимизации сервера.
>
>

Кстати, а почему так много форков? коррелируют с количеством запросов
в секунду на nginx.
может у fpm что-то вроде?
<value name="max_children">250</value>
<value name="apache_like">
<value name="StartServers">3</value>
<value name="MinSpareServers">3</value>
<value name="MaxSpareServers">3</value>
</value>
такое количество тредов на mysql говорит о накоплении запросов. скачки
в vmstat это причина, вызвавшая накопление проходит и все 200
процессов начинают исполняться.

Вы недавно никаких систем "контекстной" рекламы не вводили?
Очень похоже что накопление происходит по сетевой причине (удалённый
web сервис недостаточно быстр, или проблема в сетевой файловой системе
типа nfs

Попробую ответить в меру своих возможностей:

1. Сейчас стоит <value name="max_children">256</value>. Мы постепенно
увеличивали этот параметр, пока mysql threads не перестал складываться
в полочку. Т.к. предполагали, что складывает его в полочку именно
недостаток одновременно работающих процессов. Возможно - предположение
и подход не верны. Хотелось бы услышать комментарии профи.
2. Как могут накапливаться запросы на mysql, если мы в принципе
отключили все select & update? Посмотрите на график количества SQL
запросов. Тем не менее, как видно, колбасня тредов не пропала после
этого.
3. Подскажите, какой физический смысл у графика VMStat? О накоплении
чего идет речь?
4. Вы прямо телепат :). Действительно вводилась система парсинга
ответа от удаленного веб-сервиса. Кстати ее отключения - ряд
показателей упал раза в два. Но запросы к веб-сервису не убрали.
5. Кроме того, в системе сейчас есть концептуальный недостаток,
который планируем исправить в ближайшее время. Хотелось бы услышать
экспертное мнение на этот счет. Сервис кеширует ответы от веб-сервиса
в файловой системе. На текущий момент в папке накопилось 200к файлов.
Может ли это быть причиной схода с ума операционки и процессов? Решить
планируем следующим образом: сделать внутренние папки и раскладывать
файлики в них по хешам. Получится примерно 1000 папок по 2-3к файлов в
каждой.

Дмитрий

On 14 янв, 03:39, Ihalainen Nickolay <ihan...@gmail.com> wrote:
> Кстати, а почему так много форков? коррелируют с количеством запросов
> в секунду на nginx.
> может у fpm что-то вроде?
>                         <value name="max_children">250</value>
>                                 <value name="apache_like">
>                                         <value name="StartServers">3</value>
>                                         <value name="MinSpareServers">3</value>
>                                         <value name="MaxSpareServers">3</value>
>                                 </value>
> такое количество тредов на mysql говорит о накоплении запросов. скачки
> в vmstat это причина, вызвавшая накопление проходит и все 200
> процессов начинают исполняться.
>
> Вы недавно никаких систем "контекстной" рекламы не вводили?
> Очень похоже что накопление происходит по сетевой причине (удалённый
> web сервис недостаточно быстр, или проблема в сетевой файловой системе
> типа nfs

Thursday, January 14, 2010, 11:21:22 AM, Dmitry wrote:

> Попробую ответить в меру своих возможностей:

> 1. Сейчас стоит <value name="max_children">256</value>. Мы постепенно
> увеличивали этот параметр, пока mysql threads не перестал складываться
> в полочку. Т.к. предполагали, что складывает его в полочку именно
> недостаток одновременно работающих процессов. Возможно - предположение
> и подход не верны. Хотелось бы услышать комментарии профи.
> 2. Как могут накапливаться запросы на mysql, если мы в принципе
> отключили все select & update? Посмотрите на график количества SQL
> запросов. Тем не менее, как видно, колбасня тредов не пропала после
> этого.


Тюнинг БД делали? Настройки не дефолтные как для сервера с 64М памяти?
Графиков не получил.


> 3. Подскажите, какой физический смысл у графика VMStat? О накоплении
> чего идет речь?
> 4. Вы прямо телепат :). Действительно вводилась система парсинга
> ответа от удаленного веб-сервиса. Кстати ее отключения - ряд
> показателей упал раза в два.. Но запросы к веб-сервису не убрали.
> 5. Кроме того, в системе сейчас есть концептуальный недостаток,
> который планируем исправить в ближайшее время. Хотелось бы услышать
> экспертное мнение на этот счет. Сервис кеширует ответы от веб-сервиса
> в файловой системе. На текущий момент в папке накопилось 200к файлов.
> Может ли это быть причиной схода с ума операционки и процессов? Решить
> планируем следующим образом: сделать внутренние папки и раскладывать
> файлики в них по хешам. Получится примерно 1000 папок по 2-3к файлов в
> каждой.

Это доллжно помочь, но тюнинг ФС/ОС на предмет буферов и числа инодов
наверно тоже не помешал бы.


> Дмитрий

> On 14 янв, 03:39, Ihalainen Nickolay <ihan...@gmail.com> wrote:
>> Кстати, а почему так много форков? коррелируют с количеством запросов
>> в секунду на nginx.
>> может у fpm что-то вроде?
>>                         <value name="max_children">250</value>
>>                                 <value name="apache_like">
>>                                         <value name="StartServers">3</value>
>>                                         <value name="MinSpareServers">3</value>
>>                                         <value name="MaxSpareServers">3</value>
>>                                 </value>
>> такое количество тредов на mysql говорит о накоплении запросов. скачки
>> в vmstat это причина, вызвавшая накопление проходит и все 200
>> процессов начинают исполняться.
>>
>> Вы недавно никаких систем "контекстной" рекламы не вводили?
>> Очень похоже что накопление происходит по сетевой причине (удалённый
>> web сервис недостаточно быстр, или проблема в сетевой файловой системе
>> типа nfs



--
Sergey

> 1. Сейчас стоит <value name="max_children">256</value>. Мы постепенно
> увеличивали этот параметр, пока mysql threads не перестал складываться
> в полочку. Т.к. предполагали, что складывает его в полочку именно
> недостаток одновременно работающих процессов. Возможно - предположение
> и подход не верны. Хотелось бы услышать комментарии профи.
кроме max_children надо ещё увеличивать MinSpareServers и MaxSpareServers
разумный предел по этим трём характеристикам определяется количеством
памяти и средним потреблением rss процессами php.
т.е. если потребление 60 Мб и кроме php никого на хосте нет, то
максимально значение для 4Гб оперативной памяти будет:
4Гб - 1Гб на файловый кеш и буфера = 3000Мб/60 = 50шт. т.е.
максимальное количество max_children=50 чтобы не терять
производительность на форках:
MinSpareServers=60 MaxSpareServers=60 StartServers=60.
если пренебрегать этим, то система будет уходить в swap, иногда
внезапно. Также надо помнить, что даже 16 процессоров плохо
справляются с одновременным выполнением 500 задач.
Также, чем больше процессов php тем больше будет тредов в mysql, а
каждый тред в mysql это определённое количество буферов: join,
network, sort и прочие.
> 2. Как могут накапливаться запросы на mysql, если мы в принципе
> отключили все select & update? Посмотрите на график количества SQL
> запросов. Тем не менее, как видно, колбасня тредов не пропала после
> этого.
начинается запрос. php подключается к mysql (кто-то сессии использует
либо mysql_connect сейчас не закоментарен)
php долго выполняется (2-10 секунд) пытаясь получить ответ с
удалённого сервиса или читая с медленного диска (не ваша ситуация).
php завершает выполнение и дисконнектится от mysql.
В результате в munin мы видим количество тредов соизмеримое с
количеством max_children в php-fpm
> 3. Подскажите, какой физический смысл у графика VMStat? О накоплении
> чего идет речь?
если есть 200 процессов которые ждут ответа от одного сервиса (это
может быть mysql с myisam и большим update/insert, web сервис, сетевая
файловая система и т.п.),
то когда сервис выдаёт ответ в короткое время всем 200 процессам, то
все 200 процессов пытаются исполнится на 4-16 ядрах/cpu. В этом случае
наступает thead trashing, подрастают переключения контекста,
продрастает system, что видно на cpu usage, и running proccesses на
графиках vmstat
> 4. Вы прямо телепат :). Действительно вводилась система парсинга
> ответа от удаленного веб-сервиса. Кстати ее отключения - ряд
> показателей упал раза в два. Но запросы к веб-сервису не убрали.
во время пиковой нагрузки подключитесь strace или gdb к php процессу и
посмотрите какие syscall он выполняет, если poll,select на сокетах
(через lsof можно посмотреть ip:port связанный с сокетом), тогда вы
однозначно поймёте при обращении к чему происходит тупняк.
в случае с медленными web сервисами, наиболее частые запросы надо
кешировать в memcached или на худой конец в базе или файлах. если
значение обновляется, то делать prefetch. (т.е. по крону забирать
сразу 10-20 ответов вместо одного).
> 5. Кроме того, в системе сейчас есть концептуальный недостаток,
> который планируем исправить в ближайшее время. Хотелось бы услышать
> экспертное мнение на этот счет. Сервис кеширует ответы от веб-сервиса
> в файловой системе. На текущий момент в папке накопилось 200к файлов.
если файловая система поддерживает хранение таблиц файлов в виде
дерева, то это не проблема.
хотя ls в этой папке будет вечен.
> Может ли это быть причиной схода с ума операционки и процессов?
если strace показывает очень медленный вызов stat, значит это проблема
настроек файловой системы.
но конкретно на ваших графиках не видно что процессы проводят
значительное время на wait on io
и сам объём io низок. И если не используется никаких сетевых файловых
систем, то этим тюнингом можно заняться, когда будет проблема.
> Решить планируем следующим образом: сделать внутренние папки и раскладывать
> файлики в них по хешам. Получится примерно 1000 папок по 2-3к файлов в
> каждой.
если linux то нужен dir_index, ни в коем случае не использовать xfs с
маленькими файлами,
подобрать block size файловой системы чтобы уменьшить табличку с
открытыми inode.
>

> 5. Кроме того, в системе сейчас есть концептуальный недостаток,
> который планируем исправить в ближайшее время. Хотелось бы услышать
> экспертное мнение на этот счет. Сервис кеширует ответы от веб-сервиса
> в файловой системе. На текущий момент в папке накопилось 200к файлов.
> Может ли это быть причиной схода с ума операционки и процессов? Решить

ежу понятно что может.

> планируем следующим образом: сделать внутренние папки и раскладывать
> файлики в них по хешам. Получится примерно 1000 папок по 2-3к файлов в
> каждой.

я бью по первым двум букам хеша (получается 256 папок ), потом по сл двум буквам (в каждой папке по 256 папок), ну а там, как получится...

On 01/14/10 16:44, silly sad wrote:
> On 01/14/10 16:30, Alexandre Kalendarev wrote:


>> планируем следующим образом: сделать внутренние папки и раскладывать
>> файлики в них по хешам. Получится примерно 1000 папок по 2-3к файлов в
>> каждой.
> я бью по первым двум букам хеша (получается 256 папок ), потом по сл
> двум буквам (в каждой папке по 256 папок), ну а там, как получится...
>

почти все так делают и это реально круто!
сразу на (если это слова языка) 26^2 делится количество файлов в идеале.
но если на одну букву попадает слишком дофига слов то можно и в три
этажа разбивать


и при этом количество вычислений минимально!
и всегда можно восстановить нужный путь В УМЕ!

2010/1/14 Alexandre Kalendarev <akalend@mail.ru>:
>
>> 5. Кроме того, в системе сейчас есть концептуальный недостаток,
>> который планируем исправить в ближайшее время. Хотелось бы услышать
>> экспертное мнение на этот счет. Сервис кеширует ответы от веб-сервиса
>> в файловой системе. На текущий момент в папке накопилось 200к файлов.
>> Может ли это быть причиной схода с ума операционки и процессов? Решить
>
> ежу понятно что может.

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

--
Aleksej Besciokov
EMail/JID: proforg@maloletka.ru
phone: +7 495 7853149

> >> 5. Кроме того, в системе сейчас есть концептуальный недостаток,
> >> который планируем исправить в ближайшее время. Хотелось бы услышать
> >> экспертное мнение на этот счет. Сервис кеширует ответы от веб-сервиса
> >> в файловой системе. На текущий момент в папке накопилось 200к файлов.
> >> Может ли это быть причиной схода с ума операционки и процессов? Решить
> >
> > ежу понятно что может.
>
> я бы небыл столь категоричен
> все современные FS нормально работают с таким (да и большим на
> порядки) количеством файлов в папке
> то есть могут быть некоторые задержки, но никак не "причиной схода с
> ума операционки и процессов"
> проблемы начинаются при получении листинга - но это, в общем то, очень
> редкая операция, в нормальной работе не применяемая

принципиально согласен, у меня немного категоричное заявление,
но лучше все же бить и не допускать кол-во файлов более 10 000 на директорию.