Здравствуйте.
FreeBSD 7.1-RELEASE-p5
nginx/0.8.20
PHP 5.2.8
php5-fpm-5.2.8

на одном из серверов сегодня начало случаться такое:
2267 www 1 4 0 141M 42848K sbwait 0 0:04 6.30% php-cgi
2218 www 1 4 0 140M 43304K sbwait 0 0:07 6.05% php-cgi
2342 www 1 4 0 140M 41836K sbwait 0 0:04 5.18% php-cgi
2299 www 1 4 0 140M 43192K sbwait 0 0:04 5.18% php-cgi
2298 www 1 4 0 140M 41400K sbwait 0 0:03 5.08% php-cgi
либо такое:
11349 www 1 4 0 183M 0K accept 2 0:03 0.00% <php-cgi>
11273 www 1 4 0 205M 0K accept 4 0:03 0.00% <php-cgi>
11398 www 1 4 0 183M 7996K accept 4 0:03 0.00% php-cgi
11286 www 1 4 0 205M 0K accept 1 0:03 0.00% <php-cgi>
11278 www 1 4 0 205M 0K accept 2 0:03 0.00% <php-cgi>
11416 www 1 4 0 205M 0K accept 1 0:03 0.00% <php-cgi>
11265 www 1 4 0 183M 0K accept 0 0:03 0.00% <php-cgi>
11383 www 1 4 0 183M 0K accept 1 0:03 0.00% <php-cgi>
11408 www 1 4 0 183M 0K accept 3 0:03 0.00% <php-cgi>
11356 www 1 4 0 183M 0K accept 7 0:03 0.00% <php-cgi>
11232 www 1 4 0 205M 0K accept 7 0:03 0.00% <php-cgi>
11361 www 1 4 0 183M 0K accept 5 0:02 0.00% <php-cgi>
11355 www 1 4 0 183M 0K accept 3 0:02 0.00% <php-cgi>

в это время с диском da0 творится такое:
fe1# iostat -w1
tty da0 pass0 pass1 cpu
tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id
0 1198 37.46 273 9.99 0.00 0 0.00 0.00 0 0.00 6 0 12 0 81
0 229 6.00 13 0.08 0.00 0 0.00 0.00 0 0.00 2 0 1 0 96
0 2101 9.69 39 0.37 0.00 0 0.00 0.00 0 0.00 2 0 2 0 96
0 76 43.10 1861 78.33 0.00 0 0.00 0.00 0 0.00 4 0 9 1 86
0 2137 26.45 2112 54.55 0.00 0 0.00 0.00 0 0.00 14 0 9 1 76
0 77 13.53 1461 19.30 0.00 0 0.00 0.00 0 0.00 5 0 18 0 77
0 3586 25.66 433 10.85 0.00 0 0.00 0.00 0 0.00 2 0 61 0 37
0 76 30.96 598 18.08 0.00 0 0.00 0.00 0 0.00 15 0 16 0 68
0 3857 11.95 969 11.31 0.00 0 0.00 0.00 0 0.00 10 0 19 0 71
0 164 35.43 175 6.05 0.00 0 0.00 0.00 0 0.00 4 0 6 0 90
0 3678 17.21 821 13.80 0.00 0 0.00 0.00 0 0.00 14 0 48 0 38
0 76 41.35 562 22.69 0.00 0 0.00 0.00 0 0.00 27 0 22 0 51
0 3612 17.47 900 15.34 0.00 0 0.00 0.00 0 0.00 10 0 76 1 13

и nginx в стостоянии biord. пытался поймать php-cgi в sbwait дебагером, но
кроме такого ничего не получалось:
(gdb) where
#0 0x000000080118384a in accept () from /lib/libc.so.7
#1 0x0000000000595f50 in fcgi_accept_request ()
#2 0x0000000000597bd7 in main ()



Куда смотреть, ребята?
--
Think before you print.
Best regards, Alexey Bobok.

Очень много читаю что пишут здесь.Откуда появляются иногда косяки,удивляюсь.
А nginx собирался из исходников..У меня конечно тоже прыгает нагрузка на
диски,но это не от php-fpm(5.2.11)
Может nginx'y даунгрейд до 0.7.65? а все остальное обновить?
Машину тюнили?sysctl,etc?

2010/5/31 Алексей Бобок <alexey.bobok@gmail.com>

> Здравствуйте.
> FreeBSD 7.1-RELEASE-p5
> nginx/0.8.20
> PHP 5.2.8
> php5-fpm-5.2.8
>
> на одном из серверов сегодня начало случаться такое:
> 2267 www 1 4 0 141M 42848K sbwait 0 0:04 6.30% php-cgi
> 2218 www 1 4 0 140M 43304K sbwait 0 0:07 6.05% php-cgi
> 2342 www 1 4 0 140M 41836K sbwait 0 0:04 5.18% php-cgi
> 2299 www 1 4 0 140M 43192K sbwait 0 0:04 5.18% php-cgi
> 2298 www 1 4 0 140M 41400K sbwait 0 0:03 5.08% php-cgi
> либо такое:
> 11349 www 1 4 0 183M 0K accept 2 0:03 0.00% <php-cgi>
> 11273 www 1 4 0 205M 0K accept 4 0:03 0.00% <php-cgi>
> 11398 www 1 4 0 183M 7996K accept 4 0:03 0.00% php-cgi
> 11286 www 1 4 0 205M 0K accept 1 0:03 0.00% <php-cgi>
> 11278 www 1 4 0 205M 0K accept 2 0:03 0.00% <php-cgi>
> 11416 www 1 4 0 205M 0K accept 1 0:03 0.00% <php-cgi>
> 11265 www 1 4 0 183M 0K accept 0 0:03 0.00% <php-cgi>
> 11383 www 1 4 0 183M 0K accept 1 0:03 0.00% <php-cgi>
> 11408 www 1 4 0 183M 0K accept 3 0:03 0.00% <php-cgi>
> 11356 www 1 4 0 183M 0K accept 7 0:03 0.00% <php-cgi>
> 11232 www 1 4 0 205M 0K accept 7 0:03 0.00% <php-cgi>
> 11361 www 1 4 0 183M 0K accept 5 0:02 0.00% <php-cgi>
> 11355 www 1 4 0 183M 0K accept 3 0:02 0.00% <php-cgi>
>
> в это время с диском da0 творится такое:
> fe1# iostat -w1
> tty da0 pass0 pass1 cpu
> tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id
> 0 1198 37.46 273 9.99 0.00 0 0.00 0.00 0 0.00 6 0 12 0 81
> 0 229 6.00 13 0.08 0.00 0 0.00 0.00 0 0.00 2 0 1 0 96
> 0 2101 9.69 39 0.37 0.00 0 0.00 0.00 0 0.00 2 0 2 0 96
> 0 76 43.10 1861 78.33 0.00 0 0.00 0.00 0 0.00 4 0 9 1
> 86
> 0 2137 26.45 2112 54.55 0.00 0 0.00 0.00 0 0.00 14 0 9 1
> 76
> 0 77 13.53 1461 19.30 0.00 0 0.00 0.00 0 0.00 5 0 18 0 77
> 0 3586 25.66 433 10.85 0.00 0 0.00 0.00 0 0.00 2 0 61 0 37
> 0 76 30.96 598 18.08 0.00 0 0.00 0.00 0 0.00 15 0 16 0 68
> 0 3857 11.95 969 11.31 0.00 0 0.00 0.00 0 0.00 10 0 19 0 71
> 0 164 35.43 175 6.05 0.00 0 0.00 0.00 0 0.00 4 0 6 0 90
> 0 3678 17.21 821 13.80 0.00 0 0.00 0.00 0 0.00 14 0 48 0 38
> 0 76 41.35 562 22.69 0.00 0 0.00 0.00 0 0.00 27 0 22 0 51
> 0 3612 17.47 900 15.34 0.00 0 0.00 0.00 0 0.00 10 0 76 1 13
>
> и nginx в стостоянии biord. пытался поймать php-cgi в sbwait дебагером, но
> кроме такого ничего не получалось:
> (gdb) where
> #0 0x000000080118384a in accept () from /lib/libc.so.7
> #1 0x0000000000595f50 in fcgi_accept_request ()
> #2 0x0000000000597bd7 in main ()
>
>
>
> Куда смотреть, ребята?
> --
> Think before you print.
> Best regards, Alexey Bobok.
>
>

sysctl стандартный, только увеличено
kern.maxfiles=204800
kern.maxfilesperproc=200000
2000 одновременных конектов - не считаю, что очень большая нагрузка.
хотя возможно уже надо чето по памяти для процессов увеличивать уже.

31 мая 2010 г. 17:43 пользователь No1zilla <smile.neversmile@gmail.com>написал:

> Очень много читаю что пишут здесь.Откуда появляются иногда
> косяки,удивляюсь.
> А nginx собирался из исходников.У меня конечно тоже прыгает нагрузка на
> диски,но это не от php-fpm(5.2.11)
> Может nginx'y даунгрейд до 0.7.65? а все остальное обновить?
> Машину тюнили?sysctl,etc?
>
> 2010/5/31 Алексей Бобок <alexey.bobok@gmail.com>
>
> Здравствуйте.
>> FreeBSD 7.1-RELEASE-p5
>> nginx/0.8.20
>> PHP 5.2.8
>> php5-fpm-5.2.8
>>
>> на одном из серверов сегодня начало случаться такое:
>> 2267 www 1 4 0 141M 42848K sbwait 0 0:04 6.30% php-cgi
>> 2218 www 1 4 0 140M 43304K sbwait 0 0:07 6.05% php-cgi
>> 2342 www 1 4 0 140M 41836K sbwait 0 0:04 5.18% php-cgi
>> 2299 www 1 4 0 140M 43192K sbwait 0 0:04 5.18% php-cgi
>> 2298 www 1 4 0 140M 41400K sbwait 0 0:03 5.08% php-cgi
>> либо такое:
>> 11349 www 1 4 0 183M 0K accept 2 0:03 0.00%
>> <php-cgi>
>> 11273 www 1 4 0 205M 0K accept 4 0:03 0.00%
>> <php-cgi>
>> 11398 www 1 4 0 183M 7996K accept 4 0:03 0.00% php-cgi
>> 11286 www 1 4 0 205M 0K accept 1 0:03 0.00%
>> <php-cgi>
>> 11278 www 1 4 0 205M 0K accept 2 0:03 0.00%
>> <php-cgi>
>> 11416 www 1 4 0 205M 0K accept 1 0:03 0.00%
>> <php-cgi>
>> 11265 www 1 4 0 183M 0K accept 0 0:03 0.00%
>> <php-cgi>
>> 11383 www 1 4 0 183M 0K accept 1 0:03 0.00%
>> <php-cgi>
>> 11408 www 1 4 0 183M 0K accept 3 0:03 0.00%
>> <php-cgi>
>> 11356 www 1 4 0 183M 0K accept 7 0:03 0.00%
>> <php-cgi>
>> 11232 www 1 4 0 205M 0K accept 7 0:03 0.00%
>> <php-cgi>
>> 11361 www 1 4 0 183M 0K accept 5 0:02 0.00%
>> <php-cgi>
>> 11355 www 1 4 0 183M 0K accept 3 0:02 0.00%
>> <php-cgi>
>>
>> в это время с диском da0 творится такое:
>> fe1# iostat -w1
>> tty da0 pass0 pass1 cpu
>> tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id
>> 0 1198 37.46 273 9.99 0.00 0 0.00 0.00 0 0.00 6 0 12 0 81
>> 0 229 6.00 13 0.08 0.00 0 0.00 0.00 0 0.00 2 0 1 0 96
>> 0 2101 9.69 39 0.37 0.00 0 0.00 0.00 0 0.00 2 0 2 0 96
>> 0 76 43.10 1861 78.33 0.00 0 0.00 0.00 0 0.00 4 0 9 1
>> 86
>> 0 2137 26.45 2112 54.55 0.00 0 0.00 0.00 0 0.00 14 0 9 1
>> 76
>> 0 77 13.53 1461 19.30 0.00 0 0.00 0.00 0 0.00 5 0 18 0
>> 77
>> 0 3586 25.66 433 10.85 0.00 0 0.00 0.00 0 0.00 2 0 61 0 37
>> 0 76 30.96 598 18.08 0.00 0 0.00 0.00 0 0.00 15 0 16 0 68
>> 0 3857 11.95 969 11.31 0.00 0 0.00 0.00 0 0.00 10 0 19 0 71
>> 0 164 35.43 175 6.05 0.00 0 0.00 0.00 0 0.00 4 0 6 0 90
>> 0 3678 17.21 821 13.80 0.00 0 0.00 0.00 0 0.00 14 0 48 0 38
>> 0 76 41.35 562 22.69 0.00 0 0.00 0.00 0 0.00 27 0 22 0 51
>> 0 3612 17.47 900 15.34 0.00 0 0.00 0.00 0 0.00 10 0 76 1 13
>>
>> и nginx в стостоянии biord. пытался поймать php-cgi в sbwait дебагером, но
>> кроме такого ничего не получалось:
>> (gdb) where
>> #0 0x000000080118384a in accept () from /lib/libc.so.7
>> #1 0x0000000000595f50 in fcgi_accept_request ()
>> #2 0x0000000000597bd7 in main ()
>>
>>
>>
>> Куда смотреть, ребята?
>> --
>> Think before you print.
>> Best regards, Alexey Bobok.
>>
>>
>


--
Think before you print.
Best regards, Alexey Bobok.

31 мая 2010 г. 18:39 пользователь Алексей Бобок
<alexey.bobok@gmail.com> написал:
> sysctl стандартный, только увеличено
> kern.maxfiles=204800
> kern.maxfilesperproc=200000
> 2000 одновременных конектов - не считаю, что очень большая нагрузка.
> хотя возможно уже надо чето по памяти для процессов увеличивать уже.

А сколько php-cgi запускается?

>>> 2267 www         1   4    0   141M 42848K sbwait 0   0:04  6.30% php-cgi

>>> 11398 www         1   4    0   183M  7996K accept 4   0:03  0.00% php-cgi
>>> 11286 www         1   4    0   205M     0K accept 1   0:03  0.00% <php-cgi>

Что top говорит про swap(used,in/out)?
По приведенным обрывкам всё смахивает на вытеснение в него php-cgi.

--
WNGS-RIPE

Yesterday May 31, 2010 at 18:39 Алексей Бобок wrote:

> sysctl стандартный, только увеличено
> kern.maxfiles=204800
> kern.maxfilesperproc=200000
> 2000 одновременных конектов - не считаю, что очень большая нагрузка.
> хотя возможно уже надо чето по памяти для процессов увеличивать уже.

А сколько php-cgi запускается?

> >> 2267 www 1 4 0 141M 42848K sbwait 0 0:04 6.30% php-cgi

> >> 11398 www 1 4 0 183M 7996K accept 4 0:03 0.00% php-cgi
> >> 11286 www 1 4 0 205M 0K accept 1 0:03 0.00% <php-cgi>

Что top говорит про swap(used,in/out)?
По приведенным обрывкам всё смахивает на вытеснение в него php-cgi.

--
WNGS-RIPE

Yesterday May 31, 2010 at 18:39 Алексей Бобок wrote:

> sysctl стандартный, только увеличено
> kern.maxfiles=204800
> kern.maxfilesperproc=200000
> 2000 одновременных конектов - не считаю, что очень большая нагрузка.
> хотя возможно уже надо чето по памяти для процессов увеличивать уже.

А сколько php-cgi запускается?

> >> 2267 www 1 4 0 141M 42848K sbwait 0 0:04 6.30% php-cgi

> >> 11398 www 1 4 0 183M 7996K accept 4 0:03 0.00% php-cgi
> >> 11286 www 1 4 0 205M 0K accept 1 0:03 0.00% <php-cgi>

Что top говорит про swap(used,in/out)?
По приведенным обрывкам всё смахивает на вытеснение в него php-cgi.

--
WNGS-RIPE

200 процессов.
это был мини ддос на одну страницу с тяжелым пхп кодом. порезали
несколько ИПов и стало все ок.


1 июня 2010 г. 2:11 пользователь Oleksandr V. Typlyns'kyi
<wangsamp@gmail.com> написал:
> Yesterday May 31, 2010 at 18:39 Алексей Бобок wrote:
>
>> sysctl стандартный, только увеличено
>> kern.maxfiles=204800
>> kern.maxfilesperproc=200000
>> 2000 одновременных конектов - не считаю, что очень большая нагрузка.
>> хотя возможно уже надо чето по памяти для процессов увеличивать уже.
>
>  А сколько php-cgi запускается?
>
>> >> 2267 www         1   4    0   141M 42848K sbwait 0   0:04  6.30% php-cgi
>
>> >> 11398 www         1   4    0   183M  7996K accept 4   0:03  0.00% php-cgi
>> >> 11286 www         1   4    0   205M     0K accept 1   0:03  0.00% <php-cgi>
>
>  Что top говорит про swap(used,in/out)?
>  По приведенным обрывкам всё смахивает на вытеснение в него php-cgi.
>
> --
> WNGS-RIPE
>



--
Think before you print.
Best regards, Alexey Bobok.

Интересно,с eaccelerator'ом вы бы заметили это?
Поделитесь как выяснили что это был ддос.Какие логи смотрели,как
куда.Недавно сталкивался с тем же.

2010/6/5 Алексей Бобок <alexey.bobok@gmail.com>

> 200 процессов.
> это был мини ддос на одну страницу с тяжелым пхп кодом. порезали
> несколько ИПов и стало все ок.
>
>
> 1 июня 2010 г. 2:11 пользователь Oleksandr V. Typlyns'kyi
> <wangsamp@gmail.com> написал:
> > Yesterday May 31, 2010 at 18:39 Алексей Бобок wrote:
> >
> >> sysctl стандартный, только увеличено
> >> kern.maxfiles=204800
> >> kern.maxfilesperproc=200000
> >> 2000 одновременных конектов - не считаю, что очень большая нагрузка.
> >> хотя возможно уже надо чето по памяти для процессов увеличивать уже.
> >
> > А сколько php-cgi запускается?
> >
> >> >> 2267 www 1 4 0 141M 42848K sbwait 0 0:04 6.30%
> php-cgi
> >
> >> >> 11398 www 1 4 0 183M 7996K accept 4 0:03 0.00%
> php-cgi
> >> >> 11286 www 1 4 0 205M 0K accept 1 0:03 0.00%
> <php-cgi>
> >
> > Что top говорит про swap(used,in/out)?
> > По приведенным обрывкам всё смахивает на вытеснение в него php-cgi.
> >
> > --
> > WNGS-RIPE
> >
>
>
>
> --
> Think before you print.
> Best regards, Alexey Bobok.
>

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

7 июня 2010 г. 10:23 пользователь No1zilla <smile.neversmile@gmail.com> написал:
> Интересно,с eaccelerator'ом вы бы заметили это?
> Поделитесь как выяснили что это был ддос.Какие логи смотрели,как
> куда.Недавно сталкивался с тем же.
>
> 2010/6/5 Алексей Бобок <alexey.bobok@gmail.com>
>>
>> 200 процессов.
>> это был мини ддос на одну страницу с тяжелым пхп кодом. порезали
>> несколько ИПов и стало все ок.
>>
>>
>> 1 июня 2010 г. 2:11 пользователь Oleksandr V. Typlyns'kyi
>> <wangsamp@gmail.com> написал:
>> > Yesterday May 31, 2010 at 18:39 Алексей Бобок wrote:
>> >
>> >> sysctl стандартный, только увеличено
>> >> kern.maxfiles=204800
>> >> kern.maxfilesperproc=200000
>> >> 2000 одновременных конектов - не считаю, что очень большая нагрузка.
>> >> хотя возможно уже надо чето по памяти для процессов увеличивать уже.
>> >
>> >  А сколько php-cgi запускается?
>> >
>> >> >> 2267 www         1   4    0   141M 42848K sbwait 0   0:04  6.30%
>> >> >> php-cgi
>> >
>> >> >> 11398 www         1   4    0   183M  7996K accept 4   0:03  0.00%
>> >> >> php-cgi
>> >> >> 11286 www         1   4    0   205M     0K accept 1   0:03  0.00%
>> >> >> <php-cgi>
>> >
>> >  Что top говорит про swap(used,in/out)?
>> >  По приведенным обрывкам всё смахивает на вытеснение в него php-cgi.
>> >
>> > --
>> > WNGS-RIPE
>> >
>>
>>
>>
>> --
>> Think before you print.
>> Best regards, Alexey Bobok.
>
>



--
Think before you print.
Best regards, Alexey Bobok.

2010/6/7 Алексей Бобок <alexey.bobok@gmail.com>:
> там еакселератор итак есть)) я честно говоря не очень понял, почему он
> не помог, хотя я не смотрел что было бы без него))
eaccelerator не позволяет получить большую скорость выполнения php
скрипта, если:
a) скрипт делает долгие запросы в базу / много запросов в memcache /
чтение большого количества данных из файлов
b) скрипт занимается большой вычислительной нагрузкой/работой с
большим количеством строк или крупными массивами.

> 2010/6/7 Алексей Бобок <alexey.bobok@gmail.com>:
> > там еакселератор итак есть)) я честно говоря не очень понял, почему он
> > не помог, хотя я не смотрел что было бы без него))
> eaccelerator не позволяет получить большую скорость выполнения php
> скрипта, если:
> a) скрипт делает долгие запросы в базу / много запросов в memcache /
> чтение большого количества данных из файлов
> b) скрипт занимается большой вычислительной нагрузкой/работой с
> большим количеством строк или крупными массивами.

и еще если в скрипте есть конструкции типа или им подобным:
1) $foo = $$bar;
2) $bar = new $foo();

Александр

On 07.06.2010, at 16:29, Ihalainen Nickolay wrote:

> 2010/6/7 Алексей Бобок <alexey.bobok@gmail.com>:
>> там еакселератор итак есть)) я честно говоря не очень понял, почему он
>> не помог, хотя я не смотрел что было бы без него))
> eaccelerator не позволяет получить большую скорость выполнения php
> скрипта, если:
> a) скрипт делает долгие запросы в базу / много запросов в memcache /
> чтение большого количества данных из файлов
> b) скрипт занимается большой вычислительной нагрузкой/работой с
> большим количеством строк или крупными массивами.


опкод кеши это вообще ни разу не панацея :)
то есть от "мини-ддоса" он в принципе "помочь" не мог

ну и 200 процессов php-cgi это достаточно много, чтоб не сказать слишком много
тут скорее бы помогла статистика по загрузке/использованию процессов (которая аналог mod_status)


--
Алексей Бещёков
+7 495 7853149
proforg@gmail.com

Yesterday Jun 7, 2010 at 20:35 Алексей Бещёков wrote:

> опкод кеши это вообще ни разу не панацея :)
> то есть от "мини-ддоса" он в принципе "помочь" не мог
>
> ну и 200 процессов php-cgi это достаточно много, чтоб не сказать слишком много
> тут скорее бы помогла статистика по загрузке/использованию процессов (которая аналог mod_status)

Дело не столько в количестве, сколько в потребляемой ими памяти.
Активный swap убивает производительность напрочь.

--
WNGS-RIPE