Как устранить странные ошибки 404 в WP-ADMIN?

Question

Я запускаю сайт WordPress с примерно 70 активными плагинами.

Время от времени я получаю страницу случайной ошибки («не найден», хотя я не проверял заголовки, чтобы увидеть, является ли это 404) на /wp-admin/ Страница, которая появляется из ниоткуда.

Просто попытаться снова разрешить ошибку, однако это довольно неудобно, если ошибка происходит во время обновления плагина (потому что автоматическая реактивная эксплуатация не удается). Я думаю, что эта же проблема отвечает за определенные модули на моей панели инструментов, которые не могут загружаться иногда.

Учитывая список плагинов, которые я установил, кто -нибудь знает о проблемах с любым из них или между ними, которые могут вызвать эту проблему?

Редактировать:

Информация об хостинге: Dreamhost; Я думаю, что сервер работает на пользовательской сборке Debian с Apache httpd

Answer 1

У меня были проблемы весь день с тем, что, казалось, было 404 ошибки.

В любом случае, я только что закончил общаться с человеком технической поддержки Dreamhost, который сказал мне, что учетная запись пользователя, которую я имею с ними, попадал в лимиты ресурсов памяти процесса (все процессы), и именно это вызывает странные, казалось бы, связанные с HTACCESS проблемы. Я получал прерывистые ошибки 404 из файла HTACCESS, который вообще не должен был быть вызван! Это был Dreamhost с сервером Hounted House.

Очевидно, процесс убийства робота, который использует Dreamhost, убьет веб -процесс в середине, а затем по какой -то причине (теперь зомби) Apache фактически пытается закончить свою работу (делая все возможное, чтобы выходить из необычного конца к засуднению. мое лучшее предположение). Он бросает ошибку 500 в основной журнал HTTP, но после этого он фактически отпускает условие перезаписывания и правило, которое никогда не должно было быть запущено (используя стандартный файл -f и каталог -Д -файл HTACCESS выше) -и это не так Не напишите новую запись журнала! Новый (невидимый человек) запрос затем запускает файл индекса в последней строке файла htaccess

Остерегайтесь ограничения ресурсов в основных учетных записях DreamHost! Если вы преодолеете их границы, и у вас есть HTACESS с линиями mod_rewrite, вы увидите странные вещи, которые подходят только для ночи Хэллоуина - невидимых мужчин, призрачных 404! нежить процессы! Zombie Apache! HTACCESS Двигается самостоятельно! Икес!

Надеюсь, это поможет вам избежать нескольких часов боли.

Answer 2

Единственный способ отладить это - отключить один плагин за раз, каждый раз, пытаясь воспроизводить проблему, прежде чем отключить другой плагин. Начните с плагинов, которые имеют какое -либо отношение к администрированию WP, затем перейдите к регулярным плагинам темы, виджетам и тому подобному.

Осмотрите страницу «Не найдено», которую вам обслуживают лучше (просмотрите Opera и откройте информационную панель, которая покажет вам заголовки, в качестве альтернативы просмотрите Firefox и проведйте Firebug с включенной панелью «сеть») и выполните поиск по всем Ваши плагины, чтобы увидеть, могут ли они подавать его напрямую. Если нет, взгляните на журнал веб -сервера, чтобы узнать, какой именно ресурс он не может служить; Плагин может делать какое -то необычное перенаправление или переписывание, так что это не обязательно URL, который вы видите в своем браузере, который вызывает 404.

Answer 3

Я могу только рассказать о своем собственном опыте, и до сих пор я не нашел «определенного» правила, чтобы исправить все Проблемы на одном ударе.

Основная проблема с настройкой Dreamhost заключается в том, что в вечной борьбе за то, чтобы сохранить потребление памяти как минимум, это означает избавление от как можно большего количества функций, а именно, все, что уменьшит пропускную способность (хорошо для посетителей!) Или CPU (хорошо Для сервера, но DreamHost не управляет потреблением процессора так агрессивно, как они управляют ОЗУ). Например, это означает избавление от Gzip'ed HTML + CSS (который будет потреблять CPU + RAM) или любой из нескольких плагинов Minify (который также будет потреблять ОЗУ). Чем более сложный кэш (мне нравится использовать общий кэш W3 или, по крайней мере, WP Super Cache), тем больше оперативной памяти также будет потреблено.

Точно так же многие плагины, которые ограничивают количество запросов MySQL для повышения производительности, вместо этого потребляют ОЗУ. Таким образом, поиск компромисса, где вы все еще можете держать свой сайт, отвечать хорошей производительностью, избегая потребления драгоценной оперативной памяти, является сложной задачей!

До сих пор мои лучшие результаты на оживленных сайтах - это снять оптимизацию скорости страницы и дополнительную веб -безопасность, которая, по -видимому, будет потреблять много оперативной памяти, и вместо этого полагаться на комбинацию с общим кэшем W3 и CloudFlare (бесплатный прокси -сервис обратного прокси). Cloudflare эффективно будет делать то же самое, что и модуль «дополнительная веб -безопасность», но, поскольку он работает за пределами Dreamhost, все в порядке. W3 Total Cache потребляет много памяти, но после того, как страницы будут статически храниться локально, CloudFlare будет очень эффективно кэшировать их - так что вы можете получить 404/500 при редактировании постов, по крайней мере, ваши посетители не будут испытывать их (CloudFlare также может обслуживать статические страницы Даже если Dreamhost дает 404 или 500).

Также благодаря эта статья, Я обнаружил, что FastCGI использует больше оперативной памяти, чем «нормальный» CGI. И поскольку PHP 5.3 лучше управляет RAM (более агрессивная сборы мусора, меньше утечек памяти), я экспериментально переключился на PHP 5.3 CGI (не FastCGI) без оптимизации скорости страниц и дополнительной веб -безопасности, полагаясь на W3 Total Cache + CloudFlare на Ускорить сайт. Теперь бэк -офф медленнее (больше потребления процессора!), Но, по крайней мере, я не вижу 404/500 (пока!).

Я все еще недоволен комбинацией, поэтому я, безусловно, буду продолжать настраивать настройки Dreamhost, надеясь еще больше сократить сбору с оперативной памятью и все еще получить достаточную производительность. Как сказал @DGW, я также использую много плагинов - потому что мне нужны их функциональность. Не у всех, кто ведет WP с DreamHost, есть простые потребности в блоге; Чем сложнее сайт, тем более функциональности ему потребуется ... и это красота WordPress, вам просто нужно использовать плагины, которые вам действительно нужны, и сохранить установку Core WP простой, если вы довольны несколькими потребностями. Плагины, однако, не обязательно «плохие» или такие тяжелые на сайте; Но это правда, что некоторые могут потреблять много оперативной памяти ...

Answer 4

Это всего лишь грубая идея: если вы получите «настоящую» ошибку 404 (с настройкой заголовков), то вы можете искать свои плагины и искать PHP header() функция и номер 404. Это может сверлить количество плагинов с 70 до лишь некоторых. Тогда вам нужно только проверить их.

Это можно легко сделать с помощью IDE, подобной Eclipse PDT, который предлагает поиск конкретного вызова функции PHP.

Рядом с этим, но без гарантии, что он успешно работает, состоит в том, чтобы написать плагин, который зацепится в настройку заголовка, а затем дает вам след, какой код фактически устанавливает потенциал 404 (Backtrace). Это будет работать только в том случае, если плагин использует функцию WordPress API. Первый метод для поиска функции PHP будет работать независимо от WP API.

Answer 5

Требуется дополнительная информация:

1) Почему так много плагинов?

2) Какую ОС работает ваш хостинг?

3) Какой веб -сервер?

4) Есть ли у вас доступ к журналам сервера HTTPD, особенно в журналах ошибок?

5) Что журналы ошибок говорят в сроки [s], окружающие эти проблемы?

(Теперь, по правде говоря, если мы обобщаем для «среднего J6P, управляемого WordPress, может быть этот точный вопрос, мы могли бы начать с указания указанного J6P, чтобы ответить, по крайней мере, вышеупомянутые 5 вопросов ...)