Romka_Kharkov, ну видно же что падает внутри модуля Storable. (падение самой программы в SIGFAUL на совести разработчиков cpanel, потому что там perl генерирует ошибку, которая неправильно обрабатывается)
Зачем изучать все файлы пользователей, когда нужно только открытые в момент падения?
lsof может даже смещение в файле покажет, если повезет и там нет буферизации.
mvolgin: Ну 90 % тошнотиков которые уверены что их проблема в тормазах в том что хостинг тормозит банально не имеют мозгов сделать нужные индерксы на таблицах.
Но ведь, как правило, все нужные индексы в стандартных движках уже есть. Самопис не в моде.
Romka_Kharkov, ну а по первому методу через gdb удалось понять с помощью /proc какие файлы открыты ? что за файлы? их содержимое можно попытаться проанализировать и понять не испорчено ли оно?
С fsck и bad file descriptor это саппорт пошутил так. Совершенно же ясно, что ошибка наведенная какими-то другими ошибками.
Romka_Kharkov: Буду пытаться добиться рабочего варианта от cPanel Support без предоставления root доступа. Пусть бинарик мне соберут дебажный какой-то.... у меня десятки серверов, сотни баксов в месяц за лицензии
А у программиста панели свои планы, релизы и cпринты. У себя в тикет запишут, что вы отказались сотрудничать и все. Раз проблема еще не исправлена на основании чужих жалоб, очевидно, она ваша частная.
Romka_Kharkov: дайте нам рутовый доступ , мы посмотрим..... " я таки советы шлю на### сразу.
А разве у вас есть выбор? Единственный шанс нагуглить собратьев по несчастью, которые уже предоставляли доступ root. Ну или понтануться знанием gdb и strace, что на практике не обязательно помогает догадаться в чем дело.
zloj: Может ли это быть из за MySQL? У меня все базы в innodb, файл ibdata1 весит 4 с лишним гига а базы около двух вроде.
Запросто. "Честная" реализация транзакций требует зафиксировать в надежном хранилище данные прежде чем дать сигнал о завершении транзакции. Возможно псевдопроцесс flush этим и занимается как раз.
Попробуйте настройку mysql innodb_flush_log_at_trx_commit=0. А потом внимательно почитайте, что она означает и готовы ли вы так работать.
madoff: Отдали клиенту 10m посомтрел он 5 минут а дальше что ?, буфер пусть потом тормазит ? на видео , 5 минут удовольствие остальное время страдания ?
Так принято чтобы перемотка в плеере работала нормально. В начале файла содержатся временные метки.
Хоть 10 мб для этого индекса уже много. Скорее чтобы посетитель не закрыл страницу прямо сразу так делают.
Romka_Kharkov, ну видно же что падает внутри модуля Storable. (падение самой программы в SIGFAUL на совести разработчиков cpanel, потому что там perl генерирует ошибку, которая неправильно обрабатывается)
Зачем изучать все файлы пользователей, когда нужно только открытые в момент падения?
lsof может даже смещение в файле покажет, если повезет и там нет буферизации.
Ну 90 % тошнотиков которые уверены что их проблема в тормазах в том что хостинг тормозит банально не имеют мозгов сделать нужные индерксы на таблицах.
Но ведь, как правило, все нужные индексы в стандартных движках уже есть. Самопис не в моде.
Почему же сайты тормозят ?
Romka_Kharkov, ну а по первому методу через gdb удалось понять с помощью /proc какие файлы открыты ? что за файлы? их содержимое можно попытаться проанализировать и понять не испорчено ли оно?
С fsck и bad file descriptor это саппорт пошутил так. Совершенно же ясно, что ошибка наведенная какими-то другими ошибками.
Romka_Kharkov, подробности в лицензионном соглашении рядом c буковками "AS IS".
Да, в крайнем случае, клиент сам и будет ее решать. Так что попробуйте найти компромисс.
Буду пытаться добиться рабочего варианта от cPanel Support без предоставления root доступа. Пусть бинарик мне соберут дебажный какой-то.... у меня десятки серверов, сотни баксов в месяц за лицензии
А у программиста панели свои планы, релизы и cпринты. У себя в тикет запишут, что вы отказались сотрудничать и все. Раз проблема еще не исправлена на основании чужих жалоб, очевидно, она ваша частная.
дайте нам рутовый доступ , мы посмотрим..... " я таки советы шлю на### сразу.
А разве у вас есть выбор? Единственный шанс нагуглить собратьев по несчастью, которые уже предоставляли доступ root. Ну или понтануться знанием gdb и strace, что на практике не обязательно помогает догадаться в чем дело.
Vadya, а то, что у вас gc_probabilty = 0, но очистка сессий все равно каким-то волшебным образом работает, не наводит на мысли ?
Просто это дебиан. Специальный скрипт очистки сессий берет значение из глобального php.ini.
Выключаете скрипт, настраиваете локальные gc_probabilty/gc_divisor.
Может ли это быть из за MySQL? У меня все базы в innodb, файл ibdata1 весит 4 с лишним гига а базы около двух вроде.
Запросто. "Честная" реализация транзакций требует зафиксировать в надежном хранилище данные прежде чем дать сигнал о завершении транзакции. Возможно псевдопроцесс flush этим и занимается как раз.
Попробуйте настройку mysql innodb_flush_log_at_trx_commit=0. А потом внимательно почитайте, что она означает и готовы ли вы так работать.
Отдали клиенту 10m посомтрел он 5 минут а дальше что ?, буфер пусть потом тормазит ? на видео , 5 минут удовольствие остальное время страдания ?
Так принято чтобы перемотка в плеере работала нормально. В начале файла содержатся временные метки.
Хоть 10 мб для этого индекса уже много. Скорее чтобы посетитель не закрыл страницу прямо сразу так делают.
Хочется использовать ООП, но что-то вместо этого выходит не легкий и читабельный код, а комбайн-фреймворк.
Все нормально. Так и должно быть. Теперь вы действительно знаете что такое ООП.
Можно все удалить и приступать непосредственно к написанию сайтов решающих практические задачи.