php 5.2.13 on 64bit OS

А уверены что по-разным?

Мне в таких ситуациях обычно помогал gdb. Пакеты с отладочными символами есть для большей части дебиановских пакетов. В т.ч. для апача и пхп. Для centos - аналогично, насколько я помню.

Может потому, что это лимит php а не системный. Ограничивайте апача ulimit в init-скриптах - система будет убивать процессы.

И как могут "грузить" систему "процессы в бездействии"?

а вы можете выделить и минимизировать скрипт, который зависает, чтобы можно было уже нормально отправить разработчикам php?

ну типа поржать: пока будете выделять, найдете в чем причина.

myhand, есть разные, и висячие, и работающие (видно отчётливо потому что процессы от юзера)

Это при запуске апача ограничить его процессы по длительности запуска? или как?

netwind, например это

<? date("Y",1000000000000000000); ?>

Разработчик пхп проигнорил предложение лимитировать вводимое число и не обрабатывать эту дату до зависания (

я понимаю конечно что можно и на такое грешить while(1) $i++;

но всё же, попались скрипты которые с такой датой зависают (и только на 64бит) :(

по поводу ulimit

http://opennet.ru/base/sys/ulimit_mc.txt.html

занятно. однако оно не висит, а выполняет работу :

#time php t.php

real 0m42.542s

user 0m42.140s

ltrace -l :

..

0.000102 memcpy(0x0178d938, "System/Localtime", 17) = 0x0178d938

0.000116 calloc(1, 32) = 0x017bb050

0.000061 __strdup(0x17ba12d, 0xde0b6b3a7640000, 0x17be8c0, 129, 10800) = 0x17beaa0

42.957215 __strdup(0x17beaa0, 0x17beaa0, 10, 0x760cbce7c, 23) = 0x17beac0

...

те 42 секунды где-то внутри в библиотечной функции strdup.

Раз уж реализация date в php сделана так как сделана и разработчик не хочет ее менять - вы попали.

Зачем вы вообще работаете с датами, которые не наступят в обозримом времени? всех остальных реализация очевидно устраивает при использовании нормальных дат. То значение, которые вы написали - это 31688740476 год от р.х. Надо этих наркоманов в вебразработку не пускать.

Если не вы, а клиенты - поставьте там ulimit и пусть сами как-нибудь исправят. Или пусть специально покупают 32битный сервер под себя.

netwind, скрипты не мои, просто обидно когда пишут что на вашем сервере не работает сайт, а вот на другом работает, и ничего не сделать кроме как возвращаться на 32бита или править исходники пхп либо что ещё хуже юзерские скрипты :)

тогда для начала лучше смириться с этим и задавать всем юзерам ulimit дабы уберечь сам сервер?

есть ещё и процессы которые просто висят, там видно дело не с date(), а с чем то другим, пока не вычислил.. но факт что на 32юита такого нет!

Я уже говорил, что держку 32-х битные vz контейнера на 64-х битной системе? Надеюсь поняли теперь почему? ;)

Ну клиенты всякие бывают. Раз вы тут спрашиваете, значит они вам интересны.

Попробуйте все-же сначала найти скрипты, а потом поставить серверный php-профайлер срабатывающий от cookies и походить по ним. Будет большой файл, но можно будет понять какая строчка скрипта проблемная. С gdb тут неудобно будет, ведь вы не видите что в логике скрипта привело к странным вызовам библиотеки.

Если /usr/bin/php использует свой php.ini и скрипты в состоянии зависнуть из командной строки, то и профайлер не обязательно в рабочий php прицеплять. В тот отдельный php.ini можно

Andreyka, вы там нигде не говорили, что это сделано специально для скриптов с ошибками написанных с допущением 32битной арифметики.

Да.

Либо искать висящие процессы скриптом и прибивать.

Дебиановский PHP работает 🚬

myhand, а на убунте тупит. вы что на вечном тестинге?