При выполнении пишет:
Fatal error: Maximum execution time of 30 seconds exceeded in
/storage/home/supremeg/dataexpress-ru/htdocs/blog/wp-includes/gettext.php on
line 157
Как подобное решается?
Проблемы со скриптом
При выполнении пишет:
Fatal error: Maximum execution time of 30 seconds exceeded in
/storage/home/supremeg/dataexpress-ru/htdocs/blog/wp-includes/gettext.php on
line 157
Как подобное решается?
При выполнении ЧЕГО?
я такое на локалхосте видал при работе с e-commerce
При запуске главной или админки.
У меня три блога на одном хостинге и со всеми эти проблемы. Для каждого используется отдельная база.
Происходит это не каждый раз, а где то в 60% случаев иногда даже больше.
Хостер говорит, что проблема в скрипте.
Вот эта ошибка выскакивает на http://www.finstrategy.ru/
Хостер, наверно, заточен под статические сайты на html, всё остальное для его серверов – непосильный труд. 🙂
да, нет, хостинг меня устраивал до недавнего времени. это ht-systems.ru.
служба поддержи очень оперативная, но в данном случае проблем наверное все же в скрипте, а из-за ограничения в 30 секунд он не выполняется.
бе-е-едный хо-о-остер =)
upd. тогда это чутку больше чем странно. я бы грешил на хостера
Понимаете, оперативность суппорта не заменит производительность сервера. Если страница генерируется больше 30 секунд, это значит что или сервер ни к черту, или скрипты кривые. Поскольку WP работает на тысячах хостов, генерируя страницы значительно быстрее 30 секунд, то… Неплохо бы время выполнения этапов посмотреть, примерно так, как Макс смотрел потребление памяти.
для того чтобы проверить потребление нужно что то добавить в wp-settings.php?
я программировании не секу. могу только вырезать и вставить 🙂
Посмотрел условия своего хостинга:
9.5. На программы PHP, выполняющиеся в контексте Web-сервера накладываются следующие ограничения:
· максимальное допустимое время работы: не более 15 процессорных секунд и не более 30 секунд реального времени;
· максимальный объём задействованной резидентной памяти – 8 Мб, виртуальный памяти – 32 Мб, объём адресного пространства процесса: 512 Мб секция данных и 16 Мб стек;
· максимальное количество открытых файлов на один процесс – 120;
9.6. Максимальное количество одновременных соединений с сервером MySQL – 100.
не могу понять чем 8мб от 32мб отличаются?
т.е. WP просит 8 а надо 10?
надо памяти как минимум 16 для нормальной работы
той которой сейчас 8 надо 16? :rolleyes:
той, которая memory_limit надо 16 🙂
Хостер предлагает посмотреть мне phpinfo и говорит, что памяти выделяется больше чем по договору. Т.е. намекает что прблема все же в скрипте. Может есть какие-то варианты обрезания WP для меньшей ресурсопотребляемости? вот здесь выложил инфо
http://www.finstrategy.ru/phpinfo.php
оказалось что памяти 32
Supreme, ну, залейте файлы движка по новой, отключите все плагины и выберите дефолтную тему. Если будет продолжать тормозить и ругаться – уходите с этого хостинга.
Вы догадываетесь, что у каждого участника этого форма где-то стоит Вордпресс, возможно, даже несколько, и все вкладываются в отведенное хостером время? 😉
Попробуй еще оптимизировать свою тему и пересмотреть свои плагины
я об этом догадываюсь! 🙂
плагины я уже все отключил и тема стоит дефолтовая, версия последняя.
установил wp 2.0.11 – все тоже самое только ошибка в другой строке 🙂
решилась проблема! это была дыра WP только что обновил на 2.3.3!!
Черная? 🙂 Какая еще дыра, расскажите.
вот здесь комментарий к этой версии: (http://mywordpress.ru/2008/02/05/wordpress-233/)
"судя по тому какие файлы обновились опять исправили какие то дыры в безопасности и что то поправили в файле gettext.php (отвечает за локализацию)"
это как раз мой случай!
В 2.3.3 наконец-то внесли изменения в то место, где определяется тип .mo-файла. Хотя дырой я бы это не называл.
http://trac.wordpress.org/changeset/6708/branches/2.3/wp-includes/gettext.php
оказывается проблема не решилась 🙂
т.е. решилась временно. пришлось отказаться от локализации, но зато все 3 блога работают!
буду ждать новых версий.
проблема бы решилась намного скорее при смене хостера, но я уважаю мужество людей, которые не ищут легких путей 🙂
ну я бы сменил хостера, если бы проблемы были явно с ним, но проблема оказалась именно с сочетанием локализации wp и хостера. у меня 3 блога и 3 сайта, поэтому сменить хостера не так просто как кажется.
когда я был уже в шаге от ухода, я написал об этом в поддержку и они подсказали, что при изменении в конфиге ru_Ru на en_US ошибка исчезает. как временное решение меня это устраивает.
камрад, у меня то же самое ) http://forum.maxsite.org/viewtopic.php?id=3297 и я тож на ht-systems.ru – вел пару дней переписку с ними – сказали что РНР апдейтить будут (есть данные что проблема именно в этом) месяца через 2 только )))))))
у них кстати еще и phpBB3 глючит =)) траблы с utf8 какие-то невнятные
в общем я серьезно щас думаю от них валить, хотя с ними больше 3-х лет уже и у меня там с десяток сайтов совокупно.
Добрый день.
Пишу от имени компании Ht-Systems.ru.
Данная проблема обсуждается также и на нашем форуме, http://forum.ht-systems.ru/index.php?showtopic=1153
Путём анализа исходного кода было выяснено, что ошибка вызвана не совсем корректной обработкой MO-файла в WP. Детали можно прочитать в соответствующем посте на нашем форуме. Патч там же.
Отсюда вывод: иногда стоит всё-таки искать проблему не у других, а у себя. Проблема всё-таки в WP, хоть и проявляется преимущественно у нас на площадке.
Это сообщение также продублировано в этой теме: http://forum.maxsite.org/viewtopic.php?id=3297 , дабы с поисковиками проще было 😉
P.S. От наших клиентов были также получены отзывы об увеличении производительности работы WP после применения данного патча.
P.P.S.
– грамматическая ошибка в локализации Вашего форума 😛 Должна быть одна Н. Не все йогурты одинаково полезны (c) :D:D:D