php перестает отвечать на запросы

[grigori]

Здравствуйте,
у меня есть проблема на одном из VPS: в какой-то момент демон PHP-
fcgi, как это кажется, перестает отвечать на запросы.
На перегрузку он реагирует, после перегрузки все работает хорошо.

Возможно, просто возникает большая очередь запросов и он не
справляется?
Как бы это проверить?

Григорий

[Andrei Nigmatulin]

Например, php принимает fastcgi соединения на 127.0.0.1:9000 :

$ netstat -np | grep 127.0.0.1:9000
tcp 0 0 127.0.0.1:9000 127.0.0.1:59053 ESTABLISHED 21881/php-cgi
tcp 0 0 127.0.0.1:9000 127.0.0.1:59057 ESTABLISHED -

Первая строка - это accepted соединение, вторая - ожидающее в очереди
(backlog), еще не принятое.

Если кол-во accepted соединений до fastcgi сервера равно кол-ву воркеров, а
присутствут ожидающие - значит все воркеры в этот момент заняты. Например,
тормозят скрипты или база данных.

--
Andrei Nigmatulin
GPG PUB KEY 6449830D

Now I lay me down to sleep(3)
Pray the OS my core to keep
If I die before I wake
Pray the Disk my core to take

[grigori]

У меня они сейчас через unix-сокет,
могу попробовать пустить по tcp.
Спасибо за вариант. А то в nginx я не нашел статистики текущих
соединений, как у апача.

On 23 июн, 21:56, Andrei Nigmatulin <andrei.nigmatu...@gmail.com>
wrote:

[Andrei Nigmatulin]

On Monday 23 June 2008 23:51, grigori wrote:
> У меня они сейчас через unix-сокет,
> могу попробовать пустить по tcp.
> Спасибо за вариант. А то в nginx я не нашел статистики текущих
> соединений, как у апача.

Такая статистика будет скоро в php-fpm.

А по поводу unix sockets - там есть ньюанс:
http://groups.google.com/group/highload-php-ru/msg/a5a2883173f56f5d

[grigori]

Спасибо.
Перенес сайты с нагрузкой на tcp socket, выделил в отдельный пул,
увеличил воркеров.
Должно помочь :)

On Jun 23, 11:10 pm, Andrei Nigmatulin <andrei.nigmatu...@gmail.com>
wrote:

[Itreek]

Есть такое, правда не такое подробное как у апача...

http://wiki.codemongers.com/NginxHttpStubStatusModule

[grigori]

> http://wiki.codemongers.com/NginxHttpStubStatusModule

Спасибо, попробую.

> Первая строка - это accepted соединение, вторая - ожидающее в очереди

Андрей, спасибо за подсказку!
Действительно, была очередь.
Разделил проекты разных типов по разным пулам, "медленные" скрипты
больше не мешают другим сайтам.
Увеличил количество воркеров для медленных скриптов до 20ти,
трафик за день вырос в 4 раза до 8к страниц в день и все работает на
VPS с 256 МБ памяти :)

Григорий

[Alex Vorona]

grigori пишет:

>> Первая строка - это accepted соединение, вторая - ожидающее в очереди
>>
> Андрей, спасибо за подсказку!
> Действительно, была очередь.
> Разделил проекты разных типов по разным пулам, "медленные" скрипты
> больше не мешают другим сайтам.
> Увеличил количество воркеров для медленных скриптов до 20ти,
> трафик за день вырос в 4 раза до 8к страниц в день и все работает на
> VPS с 256 МБ памяти :)
>
> Григорий
>
>

про пхп-акселераторы не забудьте. После них странички на пхп обычно
начинают "вылетать" :), хотя и до этого вроде бы нагрузки на сервере не
было.

[grigori]

Можно еще вопрос?
Спустя два дня опять сайт отвечает очень долго, смотрю:

#netstat -np |grep 127.0.0.1:9000 |grep ESTABLISHED
выдает 36 строк типа
tcp 872 0 127.0.0.1:9000
127.0.0.1:46501 ESTABLISHED -

и всего одну-две строки
tcp 8 0 127.0.0.1:9000 127.0.0.1:46447 ESTABLISHED 8126/php-cgi

У меня установлено 18 воркеров и работает 18 процессов php-cgi


команда #netstat -np |grep 127.0.0.1:9000
выдает 223 разных строки со статусами CLOSE_WAIT, TIME_WAIT, CLOSE,
FIN_WAIT2, ESTABLISHED


Сразу после рестарта php-fpm появляется нормальные 10-15 "ESTABLISHED
3782/php-cgi" и сайт работает быстро.

Что я делаю неправильно, куда смотреть?

Григорий

On 23 июн, 21:56, Andrei Nigmatulin <andrei.nigmatu...@gmail.com>
wrote:

[grigori]

Похоже, проблема в CLOSE_WAIT :

# netstat -np |grep 127.0.0.1:9000|grep php |wc -l
18


в гугле по CLOSE_WAIT нашел
http://www.sunmanagers.org/pipermail/summaries/2006-January/007068.html
из которого понял, что все мои воркеры висят и ждут закрытия сокета,
когда nginx уже отвалился
и я не знаю, что мне с этим делать ...

Григорий

[Andrei Nigmatulin]

On Saturday 28 June 2008 17:51, grigori wrote:
> Похоже, проблема в CLOSE_WAIT :
>
> # netstat -np |grep 127.0.0.1:9000|grep php |wc -l
> 18
>
>
> в гугле по CLOSE_WAIT нашел
> http://www.sunmanagers.org/pipermail/summaries/2006-January/007068.html
> из которого понял, что все мои воркеры висят и ждут закрытия сокета,
> когда nginx уже отвалился
> и я не знаю, что мне с этим делать ...

А чем они заняты в этот момент ?
$ strace -p <pid>
или
$ gdb /usr/local/bin/php-cgi <pid>
(gdb) where

[grigori]

> А чем они заняты в этот момент ?
> $ strace -p <pid>
> или
> $ gdb /usr/local/bin/php-cgi <pid>
> (gdb) where
>
>

fcntl64(5, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET,
start=1073741824, len=1}, 0xbfff5a30) = 0
fcntl64(5, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET,
start=1073741826, len=510}, 0xbfff5a30) = 0
fcntl64(5, F_SETLK64, {type=F_UNLCK, whence=SEEK_SET,
start=1073741824, len=1}, 0xbfff5a30) = 0
access("/www/vekcel/sqlite/mirrors.sq3-journal", F_OK) = 0

похоже, лок SQLITE ...
перейду сегдня на MYSQL

[Andrei Nigmatulin]

Это тот воркер, у которого fastcgi соединение в данный момент в CLOSE_WAIT ?

[grigori]

Да, вероятно проблема была в sqlite - не справлялась с дисковыми
операциями,
и в логах были ошибки "database is locked".
У меня update при каждом вызове скрипта.

Перешел на mysql с таблицей MEMORY, посмотрю завтра на пике.

Спасибо за подсказку!


On Jun 28, 5:46 pm, Andrei Nigmatulin <andrei.nigmatu...@gmail.com>
wrote:

[grigori]

On 25 июн, 20:47, Alex Vorona <vorona...@gmail.com> wrote:
> про пхп-акселераторы не забудьте. После них странички на пхп обычно
> начинают "вылетать" :), хотя и до этого вроде бы нагрузки на сервере не
> было.

Поставил APC, появились segfault

/var/log/messages:
Jun 29 22:02:41 vm kernel: php-cgi[18897]: segfault at 656a626f ip
00f1b87d sp bfee38a0 error 4 in ZendOptimizer.so[e89000+147000]

в каталоге сайта есть бинарный файл core.18897

Стоит отдебажить, или это может быть связано с соседним топиком "fpm +
ZO" и стоит использовать тот патч?

Григорий

[Alex Vorona]

grigori пишет:

> On 25 июн, 20:47, Alex Vorona <vorona...@gmail.com> wrote:
>
>> про пхп-акселераторы не забудьте. После них странички на пхп обычно
>> начинают "вылетать" :), хотя и до этого вроде бы нагрузки на сервере не
>> было.
>>
>
> Поставил APC, появились segfault
>
>

ZO реально нужен для декодирования зазенденых скриптов? Если нет - в
топку его имхо :) APC я не пробовал, но в связке ZO+eaccelerator проблем
не наблюдаю.

> /var/log/messages:
> Jun 29 22:02:41 vm kernel: php-cgi[18897]: segfault at 656a626f ip
> 00f1b87d sp bfee38a0 error 4 in ZendOptimizer.so[e89000+147000]
>
> в каталоге сайта есть бинарный файл core.18897
>
> Стоит отдебажить, или это может быть связано с соседним топиком "fpm +
> ZO" и стоит использовать тот патч?
>
>

в топике вроде бы речь про бсд
> Григорий

[grigori]

> ZO реально нужен для декодирования зазенденых скриптов? Если нет - в
> топку его имхо :) APC я не пробовал, но в связке ZO+eaccelerator проблем
> не наблюдаю.

Да, ZO нужен для декодирования других сайтов.
Возможно, их стоит вынести в отдельный пул со своим конфигом.
Eaccelerator попробую.
С XCache были проблемы с тем, что обновление скрипта не замечалось.

> > Стоит отдебажить, или это может быть связано с соседним топиком "fpm +
> > ZO" и стоит использовать тот патч?
>
> в топике вроде бы речь про бсд

Потому и спрашиваю :)

P.S. проблема с CLOSE_WAIT решилась переходом на таблицу базы в
памяти.

Григорий

[Nikita Stupin]

APC не работает с ZO используйте eAccelerator.

30 июня 2008 г. 2:28 пользователь grigori <grigori....@gmail.com> написал: