r0mik: вы так и не сказали полностью ли вешается fcgi
судя по логам nginx не может дождаться ответа от fcgi, но это при обращении к форуму. а при обращении к какому-то другому скрипту что будет?
и покажите top, может у вас там i/o-wait под завязку и оно просто не успевает отработать... у меня была подобная ситуация, когда умники запускали массовую рассылку, правда там vds дохлый совсем и пользователей более 10К (следовательно и писем), но мало ли...
При обращении к другому скрипту/движку - та же проблема. Единственное НО - после смены метода рассылки, в настройках форума vbulletin на smtp, письма идут в несколько потоков + форум и остальные движки висящие на моем сервере ради тестирования все же со скрипом открываются (иногда правда все же проскакивает ошибка "The page *****").
r0mik: вы так и не сказали полностью ли вешается fcgi судя по логам nginx не может дождаться ответа от fcgi, но это при обращении к форуму. а при обращении к какому-то другому скрипту что будет? и покажите top, может у вас там i/o-wait под завязку и оно просто не успевает отработать... у меня была подобная ситуация, когда умники запускали массовую рассылку, правда там vds дохлый совсем и пользователей более 10К (следовательно и писем), но мало ли...
Рассылка запускается автоматом, затем пытаюсь обратиться к форуму - форум не отвечает. Сегодня точно проверю работоспособность другого веб-движка, который так же расположен на этом сервере, в этот же момент запишу показания top-а (iowait в норме).
netwind: настал момент прекратить выпендреж.
Нынче "выпендрежно" использовать веб-сервер не apache? Никого не принуждаю поступать так, как поступил сам.
netwind: gilas, допустим php-cgi что-то делает и виснет. допустим все 6 штук. но почему ваш сервер не может запустить еще больше процессов php-cgi, чтобы обработать запросы остальных клиентов? не пора ли уже перейти на apache, если с другими методами запуска php у вас не сложилось? ?
Проблеме, описанной мною выше, уже несколько месяцев (все никак не доходили руки разобраться). Раньше кол-во php-cgi процессов было 4 шт., форум вел себя так же в процессе этой злополучной рассылки. Спустя некоторое время число пользователей увеличилось и я решил увеличить число процессов до 6 шт. - в момент рассылки ведет себя абсолютно так же, как и с 4-мя.
Дело в том, что при выполнении скрипта, php-cgi процессы начинают жить "своей жизнью". 4-5 процессов висят как будто бы на них и вовсе не приходит запросы, остальные php-cgi процессы то и дело мелькают в top-е вместе с демоном sendmail. Хочу сказать что возникает ощущение полной блокировки всех процессов, в момент работы скрипта. Кстати говоря сами письма уходят не так уж и быстро, это я опять к тому что вычислительная задача на php-cgi и на sendmail очень маленькая.
На apache переходить не хочу, т.к. уже давно от него ушел и возвращаться на него нет желания.
ps - php-cgi виснет в буквальном смысле, так то он работает и не требует каких-либо рестартов. Если рестарт сделать во время работы скрипта-рассылки, форум мгновенно становится доступным и открывается, но через несколько секунд опять происходит затык.
netwind: это еще что за модель? памяти там сколько ? почему всего 6 штук php-cgi его вешают?
попробуйте в vbulletin переключиться на SMTP. Может быть не будут создаваться процессы или поменьше будет расход ресурсов.
Количество электронных писем, отправляемых за один раз - ОДНО.
Как последнее средство - CommunigatePro и тоже отправка через SMTP.
"своя машина" это чтобы никто не думал что проблема из-за других клиентов/пользователей, модель - PC с 3mhz двуядерной головой. Памяти 2 gb, i386. На счет php-cgi - не совсем понял Вас. В моей проблеме речь не идет о нагрузке (в момент проявления проблемы она нулевая), речь идет о прекращении нормальной работы (многопоточной) php-cgi, в момент запуска скрипта, который рассылает пользователям уведомления о новых темах и делает прочие рассылки писем через sendmail.
На счет SMTP - спасибо, изменил настройки форума, посмотрю что будет твориться сегодня.
быть может таблицы лочатся? может скриптом этим, плюс мы не знаем что у вас там за почтовая система... вы проверяли работоспособность каким образом? обращением к этому же форуму или он не работает глобально, то есть не отрабатывает вообще никакой скрипт (простейший echo "bla bla")? я к сожалению не знаю воблу совсем, но где-то с этого начал бы копать...
На счет таблиц - таблиц бд mysql? даже не знаю что сказать на это, в смысле не знаю как проверить. Почтовый демон sendmail с настройками по умолчанию, ос freebsd 7*. Работоспособность проверял простым методом - открываю браузер и пытаюсь открыть страницу своего форума, в ответ получаю
The page you are looking for is temporarily unavailable. Please try again later.
В это время, в nginx начинают сыпаться ошибки таймаутов от php-cgi:
r0mik: перестает отвечать что именно? nginx (сервер) вообще или только fcgi, то есть 504?
сильно сомневаюсь, скрипт же не 6 раз запускается
4. Форум перестает открываться. Nginx принимает запрос, отправляет его php-cgi и через некоторое время отваливается по таймауту.
Nginx работает на ура, чего не скажешь про php-cgi. К сожалению сам не понимаю почему подобный скрипт-рассылки "ложит" все 6 php процессов, хотя по top-у видно что работают в лучшем случае 1-2 шт. php-cgi процессов, остальные просто простаивают.
ps - письма идут в однопоточном режиме, соблюдая некую очередность. это заметил при мониторинге, с помощью команды mailq
вы так и не сказали полностью ли вешается fcgi
судя по логам nginx не может дождаться ответа от fcgi, но это при обращении к форуму. а при обращении к какому-то другому скрипту что будет?
и покажите top, может у вас там i/o-wait под завязку и оно просто не успевает отработать... у меня была подобная ситуация, когда умники запускали массовую рассылку, правда там vds дохлый совсем и пользователей более 10К (следовательно и писем), но мало ли...
вывод top во время рассылки:
76 processes: 2 running, 74 sleeping
CPU: 39.2% user, 0.0% nice, 0.6% system, 0.6% interrupt, 59.7% idle
Mem: 80M Active, 79M Inact, 74M Wired, 1668K Cache, 66M Buf, 1516M Free
Swap: 1000M Total, 1000M Free
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
7737 www 1 98 0 31112K 21472K CPU0 0 1:43 9.67% php-cgi
7953 www 1 45 0 32136K 22336K select 0 2:01 1.07% php-cgi
7954 www 1 20 0 24968K 16828K lockf 0 1:17 0.00% php-cgi
7751 www 1 20 0 22920K 14848K lockf 1 1:16 0.00% php-cgi
7750 www 1 4 0 24968K 16880K accept 1 1:16 0.00% php-cgi
7859 www 1 4 0 23944K 15840K accept 0 1:12 0.00% php-cgi
7860 www 1 4 0 24968K 16696K accept 1 1:09 0.00% php-cgi
При обращении к другому скрипту/движку - та же проблема. Единственное НО - после смены метода рассылки, в настройках форума vbulletin на smtp, письма идут в несколько потоков + форум и остальные движки висящие на моем сервере ради тестирования все же со скрипом открываются (иногда правда все же проскакивает ошибка "The page *****").
вы так и не сказали полностью ли вешается fcgi
судя по логам nginx не может дождаться ответа от fcgi, но это при обращении к форуму. а при обращении к какому-то другому скрипту что будет?
и покажите top, может у вас там i/o-wait под завязку и оно просто не успевает отработать... у меня была подобная ситуация, когда умники запускали массовую рассылку, правда там vds дохлый совсем и пользователей более 10К (следовательно и писем), но мало ли...
Рассылка запускается автоматом, затем пытаюсь обратиться к форуму - форум не отвечает. Сегодня точно проверю работоспособность другого веб-движка, который так же расположен на этом сервере, в этот же момент запишу показания top-а (iowait в норме).
настал момент прекратить выпендреж.
Нынче "выпендрежно" использовать веб-сервер не apache? Никого не принуждаю поступать так, как поступил сам.
gilas, допустим php-cgi что-то делает и виснет. допустим все 6 штук. но почему ваш сервер не может запустить еще больше процессов php-cgi, чтобы обработать запросы остальных клиентов?
не пора ли уже перейти на apache, если с другими методами запуска php у вас не сложилось? ?
Проблеме, описанной мною выше, уже несколько месяцев (все никак не доходили руки разобраться). Раньше кол-во php-cgi процессов было 4 шт., форум вел себя так же в процессе этой злополучной рассылки. Спустя некоторое время число пользователей увеличилось и я решил увеличить число процессов до 6 шт. - в момент рассылки ведет себя абсолютно так же, как и с 4-мя.
Дело в том, что при выполнении скрипта, php-cgi процессы начинают жить "своей жизнью". 4-5 процессов висят как будто бы на них и вовсе не приходит запросы, остальные php-cgi процессы то и дело мелькают в top-е вместе с демоном sendmail. Хочу сказать что возникает ощущение полной блокировки всех процессов, в момент работы скрипта. Кстати говоря сами письма уходят не так уж и быстро, это я опять к тому что вычислительная задача на php-cgi и на sendmail очень маленькая.
На apache переходить не хочу, т.к. уже давно от него ушел и возвращаться на него нет желания.
ps - php-cgi виснет в буквальном смысле, так то он работает и не требует каких-либо рестартов. Если рестарт сделать во время работы скрипта-рассылки, форум мгновенно становится доступным и открывается, но через несколько секунд опять происходит затык.
это еще что за модель? памяти там сколько ? почему всего 6 штук php-cgi его вешают?
попробуйте в vbulletin переключиться на SMTP. Может быть не будут создаваться процессы или поменьше будет расход ресурсов.
Количество электронных писем, отправляемых за один раз - ОДНО.
Как последнее средство - CommunigatePro и тоже отправка через SMTP.
"своя машина" это чтобы никто не думал что проблема из-за других клиентов/пользователей, модель - PC с 3mhz двуядерной головой. Памяти 2 gb, i386. На счет php-cgi - не совсем понял Вас. В моей проблеме речь не идет о нагрузке (в момент проявления проблемы она нулевая), речь идет о прекращении нормальной работы (многопоточной) php-cgi, в момент запуска скрипта, который рассылает пользователям уведомления о новых темах и делает прочие рассылки писем через sendmail.
На счет SMTP - спасибо, изменил настройки форума, посмотрю что будет твориться сегодня.
угу, не внимательно прочел первый раз
быть может таблицы лочатся? может скриптом этим, плюс мы не знаем что у вас там за почтовая система...
вы проверяли работоспособность каким образом? обращением к этому же форуму или он не работает глобально, то есть не отрабатывает вообще никакой скрипт (простейший echo "bla bla")?
я к сожалению не знаю воблу совсем, но где-то с этого начал бы копать...
На счет таблиц - таблиц бд mysql? даже не знаю что сказать на это, в смысле не знаю как проверить. Почтовый демон sendmail с настройками по умолчанию, ос freebsd 7*. Работоспособность проверял простым методом - открываю браузер и пытаюсь открыть страницу своего форума, в ответ получаю
В это время, в nginx начинают сыпаться ошибки таймаутов от php-cgi:
2010/11/17 02:01:30 [error] 43200#0: *1476 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 95.74.7.112, server: адрес_форума, request: "GET /forum/showthread.php?t=1542&page=5 HTTP/1.0", upstream: "fastcgi://unix:/var/run/fastcgi_sock:", host: "адрес_форума", referrer: "http://адрес_форума/forum/showthread.php?t=1542&page=4"
Думаю попытаться каким-либо образом разделить письма на потоки, но это лишь теоретическая зацепка...
перестает отвечать что именно? nginx (сервер) вообще или только fcgi, то есть 504?
сильно сомневаюсь, скрипт же не 6 раз запускается
Nginx работает на ура, чего не скажешь про php-cgi. К сожалению сам не понимаю почему подобный скрипт-рассылки "ложит" все 6 php процессов, хотя по top-у видно что работают в лучшем случае 1-2 шт. php-cgi процессов, остальные просто простаивают.
ps - письма идут в однопоточном режиме, соблюдая некую очередность. это заметил при мониторинге, с помощью команды mailq
Согласен, но как ни пробовал - результатов это действие не дает. Пароль криптуется в md5
Вставлял уже переделанный хеш (даже от другого пользователя, пароль которого я знаю), все равно не пускает...