cyber2, если вы не знали - "бинарными" файлами (бинарниками)
часто называют файлы в "узнаваемых" системой специальных
форматах (a.out, ELF, PE, etc).
В частности, при запуске _не_бинарного_ файла нужно еще _обязательно_
разрешить _чтение_ для пользователя, который его запускает. Или
попросту для _всех_ - "chmod +r файл".
Плюс, при выполнении текстового скрипта - файл
должен быть оформлен специально (вряд-ли *.php скрипт ТС оформлен
с учетом этого):
http://en.wikipedia.org/wiki/Shebang_(Unix)
Так что ТС советуем запускать "/usr/bin/php /path/to/script.php" и не мучаться.
SeoNizator, для вас это открытие?
Боюсь, я таки тоже не телепат. Настройки далеки от умолчания - для меня
далеко неочевидно зачем это сделано. Почему например изменены настройки
и worker и prefork?
KeepAlive Off + небольшой MaxClients - вполне могли привести к проблемам с отдачей картинок.
Для каких-то рекоммендаций нужен не кусок вывода
mod_status - а весь он. Плюс какое-то представление о нагрузке
сервера по top, например.
Обращайтесь в почту/ЛС - поможем.
Seconds since beginning of most recent request = секунд с начала самого последнего реквеста.
Видно, что данный слот вообще пустует и с ним не ассоциирован никакой
процесс (Pid = "-") апача. В данный момент этот слот не занят обработкой
реквестов, SS секунд прошло с _начала_ самого последнего реквеста
в этом слоте.
Вот если при этом много idle workers - можно поиграться с настройками
mpm (prefork или worker, смотря что у вас) Min/MaxSpareServers.
Вы уверены, что понимаете смысл этой колонки (SS)?
Как бы намекну, что это вовсе не время обработки реквеста.
Если есть какая-то проблема с отдачей картинок - Вам нужно выбрать какие-то
другие критерии для ее иллюстрации.
Крутите бекап, если такие "висит" существенны.
1. renice.
2. IO/шедулер (например, в Linux можно крутить ionice).
3. реорганизация бекапа (что-то исключить, изменить расписание). Нередко
сталкивался с ситуациями, когда бекапят все подряд, включая всякий
хлам типа кешей CMS.
4. изменить скрипты бекапа. что используется-то?
PS: А всякими php-fpm/xcache здесь мало помочь можно - причина
"висит" в бекап, а не в апаче.
1. Dimid, хоть top посмотрите в период запуска проблемного скрипта.
или смотрите
vmstat 1 -S m
2. Как запускается скрипт? cron от какого-то пользователя - посмотрите ulimit -a для этого пользователя. Из под mod_python апачевского - убедитесь, что не упираетесь в
какой-нибудь RLimitMem, выставленный в апаче.
crontab -u <apache user> -e
Где <apache user> - пользователь, от которого работает апач (например, www-data в debian).
на "хостенге" "админом" - криво установлен nginx скорее всего.
нужно установить/настроить mod_rpaf для апача.
Дело в том, что nginx не банит сразу по IP на файерволе (что очень плохая
затея). Это как минимум - "вторая стадия" (обработка error.log на предмет срабатывания
лимитов). Просто возвращается 503 ошибка, обработчик 503 можно и нужно сделать
статическим, nginx статику отдает на ура.
Подобный статус ошибки (в отличие от DROP в файерволе) "поймут" и пользователи
сайта, и поисковые боты.
