Был довольно слабенький сервер с двумя сайтами nginx+php-fpm,
постоянно держался avg 4-5, время генерации страниц было 1-2 сек.
Купили новый сервер, гораздо мощнее, ситуация с avg не изменилась, но
собираться страницы начали быстрее - порядка 0.05-0.1.

На сервере CentOS 5 с ядром 2.6.18-194, php 5.3.5 (поставленный из
remi) + apc (из pecl), mysql 5.1.54 (собранный руками со SphinxSE),
nginx 0.8.53 (тоже из репов), memcache на другом сервере в той же
стойке, на гигабитном канале.

Сами сайты написаны на Zend Framework. Перейти на apache, к сожалению,
пока нет возможности. По-началу грешили на apc, но когда заменили его
на xcache ситуация не изменилась.

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

Слишком маленький average для выяснения причин, имхо.

2 февраля 2011 г. 12:41 пользователь Nergal <nergal.dev@gmail.com> написал:
> Был довольно слабенький сервер с двумя сайтами nginx+php-fpm,
> постоянно держался avg 4-5, время генерации страниц было 1-2 сек.
> Купили новый сервер, гораздо мощнее, ситуация с avg не изменилась, но
> собираться страницы начали быстрее - порядка 0.05-0.1.
>
> На сервере CentOS 5 с ядром 2.6.18-194, php 5.3.5 (поставленный из
> remi) + apc (из pecl), mysql 5.1.54 (собранный руками со SphinxSE),
> nginx 0.8.53 (тоже из репов), memcache на другом сервере в той же
> стойке, на гигабитном канале.
>
> Сами сайты написаны на Zend Framework. Перейти на apache, к сожалению,
> пока нет возможности. По-началу грешили на apc, но когда заменили его
> на xcache ситуация не изменилась.
>
> Подскажите, пожалуйста, в чем могут быть причины такого поведения?

Вас сильно волнует avg 4-5 на слабеньком сервере? o_0

On Feb 2, 12:41 pm, Nergal <nergal....@gmail.com> wrote:
> Был довольно слабенький сервер с двумя сайтами nginx+php-fpm,
> постоянно держался avg 4-5, время генерации страниц было 1-2 сек.
> Купили новый сервер, гораздо мощнее, ситуация с avg не изменилась, но
> собираться страницы начали быстрее - порядка 0.05-0.1.
>
> На сервере CentOS 5 с ядром 2.6.18-194, php 5.3.5 (поставленный из
> remi) + apc (из pecl), mysql 5.1.54 (собранный руками со SphinxSE),
> nginx 0.8.53 (тоже из репов), memcache на другом сервере в той же
> стойке, на гигабитном канале.
>
> Сами сайты написаны на Zend Framework. Перейти на apache, к сожалению,
> пока нет возможности. По-началу грешили на apc, но когда заменили его
> на xcache ситуация не изменилась.
>
> Подскажите, пожалуйста, в чем могут быть причины такого поведения?

Уже и на новом такой же la.

2011/2/2 BlaCat <gvtsoy@gmail.com>

> Вас сильно волнует avg 4-5 на слабеньком сервере? o_0
>
> On Feb 2, 12:41 pm, Nergal <nergal....@gmail.com> wrote:
> > Был довольно слабенький сервер с двумя сайтами nginx+php-fpm,
> > постоянно держался avg 4-5, время генерации страниц было 1-2 сек.
> > Купили новый сервер, гораздо мощнее, ситуация с avg не изменилась, но
> > собираться страницы начали быстрее - порядка 0.05-0.1.
> >
> > На сервере CentOS 5 с ядром 2.6.18-194, php 5.3.5 (поставленный из
> > remi) + apc (из pecl), mysql 5.1.54 (собранный руками со SphinxSE),
> > nginx 0.8.53 (тоже из репов), memcache на другом сервере в той же
> > стойке, на гигабитном канале.
> >
> > Сами сайты написаны на Zend Framework. Перейти на apache, к сожалению,
> > пока нет возможности. По-началу грешили на apc, но когда заменили его
> > на xcache ситуация не изменилась.
> >
> > Подскажите, пожалуйста, в чем могут быть причины такого поведения?
>

2011/2/2 No1 <smile.neversmile@gmail.com>

> Уже и на новом такой же la.
>

А сколько ядер на новом сервере?


--
Best regards,
Bruce Weirdan mailto:
weirdan@gmail.com

4 LA это уже много нынче? И сколько CPU, чайлдов? Как с eaccelerator
ситуация?

2011/2/2 No1 <smile.neversmile@gmail.com>

> Уже и на новом такой же la.
>
> 2011/2/2 BlaCat <gvtsoy@gmail.com>
>
> Вас сильно волнует avg 4-5 на слабеньком сервере? o_0
>>
>> On Feb 2, 12:41 pm, Nergal <nergal....@gmail.com> wrote:
>> > Был довольно слабенький сервер с двумя сайтами nginx+php-fpm,
>> > постоянно держался avg 4-5, время генерации страниц было 1-2 сек.
>> > Купили новый сервер, гораздо мощнее, ситуация с avg не изменилась, но
>> > собираться страницы начали быстрее - порядка 0.05-0.1.
>> >
>> > На сервере CentOS 5 с ядром 2.6.18-194, php 5.3.5 (поставленный из
>> > remi) + apc (из pecl), mysql 5.1.54 (собранный руками со SphinxSE),
>> > nginx 0.8.53 (тоже из репов), memcache на другом сервере в той же
>> > стойке, на гигабитном канале.
>> >
>> > Сами сайты написаны на Zend Framework. Перейти на apache, к сожалению,
>> > пока нет возможности. По-началу грешили на apc, но когда заменили его
>> > на xcache ситуация не изменилась.
>> >
>> > Подскажите, пожалуйста, в чем могут быть причины такого поведения?
>>
>
>


--
Serg Smirnov
email/xmpp: Sergey.A.Smirnov@Gmail.com
skype: serg-smirnoff

Был слабенький, сейчас Intel Xeon E5506 2.13GHz, 16Гб RAM, сасовский
винт на 250Гб

On Feb 2, 1:15 pm, BlaCat <gvt...@gmail.com> wrote:
> Вас сильно волнует avg 4-5 на слабеньком сервере? o_0
>
> On Feb 2, 12:41 pm, Nergal <nergal....@gmail.com> wrote:
>
>
>
>
>
>
>
> > Был довольно слабенький сервер с двумя сайтами nginx+php-fpm,
> > постоянно держался avg 4-5, время генерации страниц было 1-2 сек.
> > Купили новый сервер, гораздо мощнее, ситуация с avg не изменилась, но
> > собираться страницы начали быстрее - порядка 0.05-0.1.
>
> > На сервере CentOS 5 с ядром 2.6.18-194, php 5.3.5 (поставленный из
> > remi) + apc (из pecl), mysql 5.1.54 (собранный руками со SphinxSE),
> > nginx 0.8.53 (тоже из репов), memcache на другом сервере в той же
> > стойке, на гигабитном канале.
>
> > Сами сайты написаны на Zend Framework. Перейти на apache, к сожалению,
> > пока нет возможности. По-началу грешили на apc, но когда заменили его
> > на xcache ситуация не изменилась.
>
> > Подскажите, пожалуйста, в чем могут быть причины такого поведения?

Ошибся, два проца Intel Xeon E5506 по 4 ядра в каждом. Чайлдов с fpm
обычно порядка 30-40, максимум 200. Могу привести конфиги. У APC был
загружен почти полностью (два метра свободных из 40), дали ему 256
метров памяти - не помогло, заменили на xcache - не помогло. Или Вы
именно о eaccelerator?

On 2 фев, 13:41, Serg Smirnov <sergey.a.smir...@gmail.com> wrote:
> 4 LA это уже много нынче? И сколько CPU, чайлдов? Как с eaccelerator
> ситуация?
>
> 2011/2/2 No1 <smile.neversm...@gmail.com>
>
>
>
>
>
>
>
>
>
> > Уже и на новом такой же la.
>
> > 2011/2/2 BlaCat <gvt...@gmail.com>
>
> > Вас сильно волнует avg 4-5 на слабеньком сервере? o_0
>
> >> On Feb 2, 12:41 pm, Nergal <nergal....@gmail.com> wrote:
> >> > Был довольно слабенький сервер с двумя сайтами nginx+php-fpm,
> >> > постоянно держался avg 4-5, время генерации страниц было 1-2 сек.
> >> > Купили новый сервер, гораздо мощнее, ситуация с avg не изменилась, но
> >> > собираться страницы начали быстрее - порядка 0.05-0.1.
>
> >> > На сервере CentOS 5 с ядром 2.6.18-194, php 5.3.5 (поставленный из
> >> > remi) + apc (из pecl), mysql 5.1.54 (собранный руками со SphinxSE),
> >> > nginx 0.8.53 (тоже из репов), memcache на другом сервере в той же
> >> > стойке, на гигабитном канале.
>
> >> > Сами сайты написаны на Zend Framework. Перейти на apache, к сожалению,
> >> > пока нет возможности. По-началу грешили на apc, но когда заменили его
> >> > на xcache ситуация не изменилась.
>
> >> > Подскажите, пожалуйста, в чем могут быть причины такого поведения?
>
> --
> Serg Smirnov
> email/xmpp: Sergey.A.Smir...@Gmail.com
> skype: serg-smirnoff

Пока la меньше количества ядер, можно даже не напрягаться.

2 февраля 2011 г. 16:41 пользователь Nergal <nergal.dev@gmail.com> написал:

> Был довольно слабенький сервер с двумя сайтами nginx+php-fpm,
> постоянно держался avg 4-5, время генерации страниц было 1-2 сек.
> Купили новый сервер, гораздо мощнее, ситуация с avg не изменилась, но
> собираться страницы начали быстрее - порядка 0.05-0.1.
>
> На сервере CentOS 5 с ядром 2.6.18-194, php 5.3.5 (поставленный из
> remi) + apc (из pecl), mysql 5.1.54 (собранный руками со SphinxSE),
> nginx 0.8.53 (тоже из репов), memcache на другом сервере в той же
> стойке, на гигабитном канале.
>
> Сами сайты написаны на Zend Framework. Перейти на apache, к сожалению,
> пока нет возможности. По-началу грешили на apc, но когда заменили его
> на xcache ситуация не изменилась.
>
> Подскажите, пожалуйста, в чем могут быть причины такого поведения?

Т.е. полная загрузка двух процессорного 6-ти ядерного Xeon с HT будет
равен 2400, а не 100.

2 февраля 2011 г. 18:42 пользователь Artem Miolini <miolini@gmail.com> написал:
> Кстати, учитывайте пересчет LA в зависимости от количества ядер, т.к.
> 100% LA = LAtop * CPU_CORES.
>
> 2 февраля 2011 г. 16:56 пользователь Alexey Samoylov
> <alexey.samoylov@gmail.com> написал:
>> Пока la меньше количества ядер, можно даже не напрягаться.
>>
>> 2 февраля 2011 г. 16:41 пользователь Nergal <nergal.dev@gmail.com> написал:
>>>
>>> Был довольно слабенький сервер с двумя сайтами nginx+php-fpm,
>>> постоянно держался avg 4-5, время генерации страниц было 1-2 сек.
>>> Купили новый сервер, гораздо мощнее, ситуация с avg не изменилась, но
>>> собираться страницы начали быстрее - порядка 0.05-0.1.
>>>
>>> На сервере CentOS 5 с ядром 2.6.18-194, php 5.3.5 (поставленный из
>>> remi) + apc (из pecl), mysql 5.1.54 (собранный руками со SphinxSE),
>>> nginx 0.8.53 (тоже из репов), memcache на другом сервере в той же
>>> стойке, на гигабитном канале.
>>>
>>> Сами сайты написаны на Zend Framework. Перейти на apache, к сожалению,
>>> пока нет возможности. По-началу грешили на apc, но когда заменили его
>>> на xcache ситуация не изменилась.
>>>
>>> Подскажите, пожалуйста, в чем могут быть причины такого поведения?
>>
>

Кстати, учитывайте пересчет LA в зависимости от количества ядер, т.к.
100% LA = LAtop * CPU_CORES.

2 февраля 2011 г. 16:56 пользователь Alexey Samoylov
<alexey.samoylov@gmail.com> написал:
> Пока la меньше количества ядер, можно даже не напрягаться.
>
> 2 февраля 2011 г. 16:41 пользователь Nergal <nergal.dev@gmail.com> написал:
>>
>> Был довольно слабенький сервер с двумя сайтами nginx+php-fpm,
>> постоянно держался avg 4-5, время генерации страниц было 1-2 сек.
>> Купили новый сервер, гораздо мощнее, ситуация с avg не изменилась, но
>> собираться страницы начали быстрее - порядка 0.05-0.1.
>>
>> На сервере CentOS 5 с ядром 2.6.18-194, php 5.3.5 (поставленный из
>> remi) + apc (из pecl), mysql 5.1.54 (собранный руками со SphinxSE),
>> nginx 0.8.53 (тоже из репов), memcache на другом сервере в той же
>> стойке, на гигабитном канале.
>>
>> Сами сайты написаны на Zend Framework. Перейти на apache, к сожалению,
>> пока нет возможности. По-началу грешили на apc, но когда заменили его
>> на xcache ситуация не изменилась.
>>
>> Подскажите, пожалуйста, в чем могут быть причины такого поведения?
>

Спасибо, не знал. В таком случае, косвенный вопрос в догонку - как
вообще считается LA? Сколько у админов ни спрашивал (я программист),
те всё хитро улыбаются и выдают один из вариантов фразы "очень хитро".
Гугл тоже не прояснил ничего на этот счет.

On Feb 2, 5:42 pm, Artem Miolini <miol...@gmail.com> wrote:
> Кстати, учитывайте пересчет LA в зависимости от количества ядер, т.к.
> 100% LA = LAtop * CPU_CORES.
>
> 2 февраля 2011 г. 16:56 пользователь Alexey Samoylov
> <alexey.samoy...@gmail.com> написал:
>
>
>
>
>
>
>
> > Пока la меньше количества ядер, можно даже не напрягаться.
>
> > 2 февраля 2011 г. 16:41 пользователь Nergal <nergal....@gmail.com> написал:
>
> >> Был довольно слабенький сервер с двумя сайтами nginx+php-fpm,
> >> постоянно держался avg 4-5, время генерации страниц было 1-2 сек.
> >> Купили новый сервер, гораздо мощнее, ситуация с avg не изменилась, но
> >> собираться страницы начали быстрее - порядка 0.05-0.1.
>
> >> На сервере CentOS 5 с ядром 2.6.18-194, php 5.3.5 (поставленный из
> >> remi) + apc (из pecl), mysql 5.1.54 (собранный руками со SphinxSE),
> >> nginx 0.8.53 (тоже из репов), memcache на другом сервере в той же
> >> стойке, на гигабитном канале.
>
> >> Сами сайты написаны на Zend Framework. Перейти на apache, к сожалению,
> >> пока нет возможности. По-началу грешили на apc, но когда заменили его
> >> на xcache ситуация не изменилась.
>
> >> Подскажите, пожалуйста, в чем могут быть причины такого поведения?

2011/2/2 Nergal <nergal.dev@gmail.com>:
> Спасибо, не знал. В таком случае, косвенный вопрос в догонку - как
> вообще считается LA? Сколько у админов ни спрашивал (я программист),
> те всё хитро улыбаются и выдают один из вариантов фразы "очень хитро".
> Гугл тоже не прояснил ничего на этот счет.

У вас поломатый гугл. В первых же результатах на запрос "load average"
находим ссылку
http://en.wikipedia.org/wiki/Load_(computing)
где достаточно четко написано:

"An idle computer has a load number of 0 and each process using or
waiting for CPU (the ready queue or run queue) increments the load
number by 1. Most UNIX systems count only processes in the running (on
CPU) or runnable (waiting for CPU) states. However, Linux also
includes processes in uninterruptible sleep states (usually waiting
for disk activity), which can lead to markedly different results if
many processes remain blocked in I/O due to a busy or stalled I/O
system."

То есть LA это среднее количество процессов на выполнении и в очереди
на выполнение (а в линксах еще и в uninterrable sleep)
К загрузке CPU это имеет отношение, но косвенное.

--
LEFT-(UANIC|RIPE)

Спасибо.

On Feb 2, 10:31 pm, Mykola Dzham <mykola.dz...@gmail.com> wrote:
> 2011/2/2 Nergal <nergal....@gmail.com>:
>
> > Спасибо, не знал. В таком случае, косвенный вопрос в догонку - как
> > вообще считается LA? Сколько у админов ни спрашивал (я программист),
> > те всё хитро улыбаются и выдают один из вариантов фразы "очень хитро".
> > Гугл тоже не прояснил ничего на этот счет.
>
> У вас поломатый гугл. В первых же результатах на запрос "load average"
> находим ссылкуhttp://en.wikipedia.org/wiki/Load_(computing)
> где достаточно четко написано:
>
> "An idle computer has a load number of 0 and each process using or
> waiting for CPU (the ready queue or run queue) increments the load
> number by 1. Most UNIX systems count only processes in the running (on
> CPU) or runnable (waiting for CPU) states. However, Linux also
> includes processes in uninterruptible sleep states (usually waiting
> for disk activity), which can lead to markedly different results if
> many processes remain blocked in I/O due to a busy or stalled I/O
> system."
>
> То есть LA это среднее количество процессов на выполнении и в очереди
> на выполнение (а в линксах еще и в uninterrable sleep)
> К загрузке CPU это имеет отношение, но косвенное.
>
> --
> LEFT-(UANIC|RIPE)

Полностью согласен с Mykola Dzham
И кроме того отмечу, что наши попытки разогнать, оптимизировать,
настроить работу скриптов удались
именно с APC а не с eaccelerator или xcache - ответа на вопрос не
нашли и не получили а просто унылым
способом после получения тучи проблем выискивали то, что приносило
нестабильность и медленность,
и в начале уловив APC и что там проблемы ... Так сказать если честно
то сложно - закатывайте рукава
и расскажите что найдете.
Удачи.

2011/2/2 Mykola Dzham <mykola.dzham@gmail.com>:
> 2011/2/2 Nergal <nergal.dev@gmail.com>:
>> Спасибо, не знал. В таком случае, косвенный вопрос в догонку - как
>> вообще считается LA? Сколько у админов ни спрашивал (я программист),
>> те всё хитро улыбаются и выдают один из вариантов фразы "очень хитро".
>> Гугл тоже не прояснил ничего на этот счет.
>
> У вас поломатый гугл. В первых же результатах на запрос "load average"
> находим ссылку
> http://en.wikipedia.org/wiki/Load_(computing)
> где достаточно четко написано:
>
> "An idle computer has a load number of 0 and each process using or
> waiting for CPU (the ready queue or run queue) increments the load
> number by 1. Most UNIX systems count only processes in the running (on
> CPU) or runnable (waiting for CPU) states. However, Linux also
> includes processes in uninterruptible sleep states (usually waiting
> for disk activity), which can lead to markedly different results if
> many processes remain blocked in I/O due to a busy or stalled I/O
> system."
>
> То есть LA это среднее количество процессов на выполнении и в очереди
> на выполнение (а в линксах еще и в uninterrable sleep)
> К загрузке CPU это имеет отношение, но косвенное.
>
> --
> LEFT-(UANIC|RIPE)
>

Кажется, отношение суммарной дельты cpu time процессов к максимальному
cpu time. CPU Time это суммарное выделенное время планировщиком задач
на процесс. Т.е. если процесс был запущен 60 сек. тому назад, то это
не говорит о том, что его cpu time был 60 сек. Чем меньше он что-то
"вычисляет", тем меньше его время.

Отсюда, надо сказать, и правильное желание профилировать и
оптимизировать свой код в облаках. Не только для того, чтобы он
быстрее выполнялся. А для того, чтобы меньше платить. В контактовском
облаке Селектел считают, например, его.

2 февраля 2011 г. 22:11 пользователь Nergal <nergal.dev@gmail.com> написал:
> Спасибо, не знал. В таком случае, косвенный вопрос в догонку - как
> вообще считается LA? Сколько у админов ни спрашивал (я программист),
> те всё хитро улыбаются и выдают один из вариантов фразы "очень хитро".
> Гугл тоже не прояснил ничего на этот счет.
>
> On Feb 2, 5:42 pm, Artem Miolini <miol...@gmail.com> wrote:
>> Кстати, учитывайте пересчет LA в зависимости от количества ядер, т.к.
>> 100% LA = LAtop * CPU_CORES.
>>
>> 2 февраля 2011 г. 16:56 пользователь Alexey Samoylov
>> <alexey.samoy...@gmail.com> написал:
>>
>>
>>
>>
>>
>>
>>
>> > Пока la меньше количества ядер, можно даже не напрягаться.
>>
>> > 2 февраля 2011 г. 16:41 пользователь Nergal <nergal....@gmail.com> написал:
>>
>> >> Был довольно слабенький сервер с двумя сайтами nginx+php-fpm,
>> >> постоянно держался avg 4-5, время генерации страниц было 1-2 сек.
>> >> Купили новый сервер, гораздо мощнее, ситуация с avg не изменилась, но
>> >> собираться страницы начали быстрее - порядка 0.05-0.1.
>>
>> >> На сервере CentOS 5 с ядром 2.6.18-194, php 5.3.5 (поставленный из
>> >> remi) + apc (из pecl), mysql 5.1.54 (собранный руками со SphinxSE),
>> >> nginx 0.8.53 (тоже из репов), memcache на другом сервере в той же
>> >> стойке, на гигабитном канале.
>>
>> >> Сами сайты написаны на Zend Framework. Перейти на apache, к сожалению,
>> >> пока нет возможности. По-началу грешили на apc, но когда заменили его
>> >> на xcache ситуация не изменилась.
>>
>> >> Подскажите, пожалуйста, в чем могут быть причины такого поведения?

On 02.02.11 14:29, Nergal wrote:
> Ошибся, два проца Intel Xeon E5506 по 4 ядра в каждом. Чайлдов с fpm
> обычно порядка 30-40, максимум 200

Зачем столько О_О

У нас на более слабом сервере крутиться php-чат + nginx, нагрузка в
среднем 400 запросов в секунду, в пики хватает 15 чайлдов (тупит mysql),
а так достаточно и 5-6 (до 250 запросов)

LA никогда не бывает выше 3, обычно на уровне 2