Internal Server Error при обработке графики

Вы с помощью php обрабатываете? Попробуйте скриптами imagick через систему. Т.е. shell-командами конкретно в системе, в обход php.

Это вариант, спасибо. Сейчас поковыряюсь.

Всё же, интересно, из-за чего может падать PHP-скрипт?

П.С. Второстепенный вопрос, не важный, но если кто знает... В php.ini стоит output_buffering = Off, но вывод всё равно буферизуется - пока скрипт не закончит работу, ничего не показывается в браузере. Можно ли от этого избавиться?

KostaShah,

Так правильно, ничего и не будет показываться до тех пор, пока скрипт не отработает. Это специфика такая.

И кстати, у вас php стоит как CGI-приложение. Может быть если перекомпилировать его в качестве модуля к apache, ситуация бы изменилась, возможно в лучшую сторону.

Но на другом сервере, на шаред хостинге, это не так. Я в скрипте выдаю эхо поле каждой картинки, и оно сразу выводится в браузер, и я сразу вижу, сколько картинок уже обработалось, как быстро они обрабатываются. Это очень удобно. Интересно, как сделать, чтобы и тут так?

так:

http://php.net/manual/en/function.ob-flush.php

пробовали?

Пробовал flush() - не помогает. А ob_flush() можно (имеет смысл) делать, если не было ob_start() ?

у вас это стоит в общесистемном php.ini ? php-cgi\fastcgi запускается отдельным процессом в системе и у него свой php.ini.

LogLevel debug поставьте в /etc/httpd/conf/httpd.conf - если ценос , если недолинукс типа дебиана, то в /etc/apache2/apache2.conf, передерните апач:

service httpd restart - если центос или RHEL

или

/etc/init.d/apache2 restart - если недолинукс типа дебиана.

так же, необходимо увидеть, что у вас в /etc/httpd/conf.d/mod_fcgid.conf или чтото в этом роде, если у вас всетаки похапе в режиме cgi работает.

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

---------- Добавлено 22.06.2013 в 10:28 ----------

в догонку:

mod_fcgid: process 7817 graceful kill fail, sending SIGKILL - это, возможно, уже не ваш код виноват.

вам серверное ПО говорит - что заслало принудительный килл процессу.

как минимум наверное нужно в /etc/htttpd/conf.d/mod_fcgid.conf или как там этот конфиг называется поставить число:

IPCConnectTimeout

и

IPCCommTimeout

поболее....

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

если у вас впс - то нужно смотреть впс + если впс не хватает ресурсов - увеличивать.

если у вас сервер - то нужно смотреть сервер.

Делайте это по крону

pupseg

почему debian недолинукс?

в debian есть sysvinit-utils,

service apache2 restart

тс,

не смотрите php.ini, смотрите то что возвращает phpinfo()

pupseg, огромное спасибо! Поставил оба параметра (IPCConnectTimeout и IPCCommTimeout) в 3600, прогнал пару раз, полёт нормальный! Не падает! Обработал 60 файлов (все что надо было) за 103 секунды :)

Это был Ubuntu

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

П.С. php.ini находится в /etc/php5/cgi/php.ini , и я убедился, что задействован именно он - изменения в нём отражаются в phpinfo().