покажите df -h и mount. может у вас какая-то специальная файловая система в памяти для сессий и она по старой панельной традиции не очищается.
Зачем вы тут вообще разглагольствуете уже неделю? Начинайте действовать.
Cо сколькими провайдерами вы уже вступили в преступную связь? Они же выдвинули технические требования для подключения? почему бы вам не разгласить их и не нанять админа конкретно под эту задачу? только из Списка Страшных Слов /ru/forum/comment/6512544 уберите DOD, ZIP, GOPHER и т.д - смех да и только.
Если еще нет - получается вы собираетесь свалить на админа задачу совсем другую, нежели заявляете.
Ну вот я посмотрел на код и просто запустил - выкачивает нормально.
myhand, а на убунте тупит. вы что на вечном тестинге?
Pilat, букв не жалко? я то все понимаю и возражаю не вам.
Если смотреть на ситуацию с точки зрения хостера, то ему нужно сделать хоть какой-нибудь бекап. Если он не ломает innodb и это уже хорошо.
Те, кто знает про транзакции и пишут правильный код - сами разберутся с бекапом.
Ну клиенты всякие бывают. Раз вы тут спрашиваете, значит они вам интересны.
Попробуйте все-же сначала найти скрипты, а потом поставить серверный php-профайлер срабатывающий от cookies и походить по ним. Будет большой файл, но можно будет понять какая строчка скрипта проблемная. С gdb тут неудобно будет, ведь вы не видите что в логике скрипта привело к странным вызовам библиотеки.
Если /usr/bin/php использует свой php.ini и скрипты в состоянии зависнуть из командной строки, то и профайлер не обязательно в рабочий php прицеплять. В тот отдельный php.ini можно
Andreyka, вы там нигде не говорили, что это сделано специально для скриптов с ошибками написанных с допущением 32битной арифметики.
Pavel.Odintsov, не на пустом. но существование этой программы ведь не значит, что бекап innodb снапшотом может привести к аварии. логика где?
занятно. однако оно не висит, а выполняет работу :
#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битный сервер под себя.
а вы можете выделить и минимизировать скрипт, который зависает, чтобы можно было уже нормально отправить разработчикам php?
ну типа поржать: пока будете выделять, найдете в чем причина.
если там мгновенный снапшот, то что с innodb такого может случиться? расскажите
