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

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

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

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

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

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

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

У меня были проблемы в течение всего дня с 404 пропусками.

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

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

Остерегайтесь ограничений ресурсов в основных учетных записях Dreamhost! если вы выйдете за их пределы, и у вас есть htacess с линиями mod_rewrite, вы увидите странные вещи, которые подходят только для ночи Хэллоуина - невидимые люди, преследуемые 404-ые! нежить! зомби апач! htaccess движется сам по себе! Хлоп!

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

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

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

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

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

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

Пока что мои лучшие результаты на загруженных сайтах - снять флажок Page Speed ​​Optimization и Extra Web Security, которые, очевидно, потребляют много оперативной памяти, и вместо этого полагаться на комбинацию с W3 Total Cache и Cloudflare (бесплатный сервис обратного прокси-сервера). Cloudflare будет выполнять те же действия, что и модуль «Extra Web Security», но, поскольку он работает за пределами DreamHost, все в порядке. W3 Total Cache занимает много памяти, но как только страницы статически хранятся локально, Cloudflare очень эффективно их кеширует - так что вы можете получить 404/500 при редактировании постов, по крайней мере ваши посетители их не увидят (Cloudflare также может обслуживать статические страницы даже если DreamHost дает 404 или 500).

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

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

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

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

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

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

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

2) Какую ОС использует ваш хостинг-провайдер?

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

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

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

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