Ошибка 500 — превышение лимитов памяти. Помогите отловить виновника.

kodovsky
(@kodovsky)

7 лет, 10 месяцев назад

Здравствуйте.

Прошу помощи в отлове виновника превышения лимитов по памяти.

Сразу пишу большой пост — напишу всё, что по этому поводу «накопал» перед тем как спросить у сообщества.

Перечитал всё, что нашел на этом форуме по теме. Ответа не нашел, поэтому спрашиваю.

Сайт http://koldovskie.com
Хостер UniHost

Конфигурация сервера.
Operating System : Linux
Server : Apache/2.4.6 () mpm-itk/2.4.7-03 OpenSSL/1.0.1e-fips PHP/5.4.16 mod_wsgi/3.4 Python/2.7.5
PHP Version : 5.3.29
MYSQL Version : 5.5.47-MariaDB-cll-lve

Два месяца назад хостер сделал переезд сайта из Германии во Францию — в другой датацентр на другие сервера. Сам переезд произошел без проблем. Проблемы начались позже.
Начал периодически замечать, что иногда проскакивает ошибка 500. Либо 502. Бывает, что сайт долго подгружается — приходится подождать пару секунд, пока отклинется. Бывает, что ошибка 504 проскакивает.

Написал хостеру. Те ответили, что ошибка связана с превышением лимитов памяти согласно тарифного плана (был лимит 192 Мб по тарифному плану). Посмотрел статистику в ISPManager — действительно, есть превышение лимитов.

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

В январе 2016 сайт без проблем выдержал несколько дней посещаемости по 2000-4000 в сутки. Сейчас же наблюдаю глюки при посещаемости в сутки макс — 250 чел.

Ладно, доплатил, увеличили лимиты памяти. Сейчас лимит памяти 384Мб.
Однако, ошибки остаются.

Периодичность возникновения ошибок превышения лимитов памяти отследить не получилось. Их может не быть несколько часов (от 4 до 12 часов без ошибок) потом два часа ошибки возникают, потом опять нет.

Думал уже, что какая-то функция из cron запускаясь, съедает память, так нет — периодичности ярко выраженной нет. Сравнивал из cron периоды запуска процессов — они не совпадают с периодами возникновения ошибок.

Хостер предоставляет только статистику почасово — за период с 12 по 13 возникло 38 ошибок превышения лимитов памяти.
Просил хостера дать более подробную статистику, чтобы «поймать» точное время возникновения переполнения. Мне отказали, сославшись на то, что они более подробных логов не ведут. Только так.

Отчет средний выглядит так.
Среднее MiB 13, Лимит 384, Макс 384 (или меньше, если за этот час ошибок не было).

Мизерное среднее потребление памяти говорит о том, что нагрузки на сервер нет в среднем. Какой-то один процесс, запускаясь, съедает всю память до максимума, так что происходит отказ.
Какой-то один процесс.

Вопрос — как его «поймать»? Учитывая, что ярко выраженной периодичности возникновения ошибок нет.

Можно, конечно, отключить все плагины на сайте. И подключать по одному. Но тогда придется подключать по одному плагину в сутки.
К тому же я не уверен, что дело именно в плагинах.

Посещаемость сайта сейчас низкая. Но регулярно «пасутся» боты от поисковиков. Боты могут нагрузку такую создавать?

И еще.
Это из error.log.

[Fri Oct 28 12:48:16.385153 2016] [cgi:error] [pid 766740] [client 185.8.42.190:37195] AH01215: PHP Notice: Undefined index: adman_edit in /var/www/koldovsk/data/www/koldovskie.com/wp-content/plugins/new-adman/new-adman.php on line 125, referer: http://koldovskie.com/wp-admin
[Fri Oct 28 12:48:16.976445 2016] [cgi:error] [pid 766813] [client 185.8.42.190:37222] AH01215: PHP Notice: Undefined index: adman_edit in /var/www/koldovsk/data/www/koldovskie.com/wp-content/plugins/new-adman/new-adman.php on line 125, referer: http://koldovskie.com/wp-admin
[Fri Oct 28 13:01:24.524039 2016] [cgi:error] [pid 791986] [client 185.8.42.190:46150] AH01215: \xd0\x91\xd0\xb0\xd0\xb7\xd0\xb0 \xd0\xb4\xd0\xb0\xd0\xbd\xd0\xbd\xd1\x8b\xd1\x85 WordPress \xd0\xb2\xd0\xbe\xd0\xb7\xd0\xb2\xd1\x80\xd0\xb0\xd1\x82\xd0\xb8\xd0\xbb\xd0\xb0 \xd0\xbe\xd1\x88\xd0\xb8\xd0\xb1\xd0\xba\xd1\x83 There is no such grant defined for user ‘wordpress_user’ on host ‘localhost:’ \xd0\xb2 \xd0\xbe\xd1\x82\xd0\xb2\xd0\xb5\xd1\x82 \xd0\xbd\xd0\xb0 \xd0\xb7\xd0\xb0\xd0\xbf\xd1\x80\xd0\xbe\xd1\x81 SHOW GRANTS FOR ‘wordpress_user’@’localhost:’, \xd0\xb2\xd1\x8b\xd0\xbf\xd0\xbe\xd0\xbb\xd0\xbd\xd0\xb5\xd0\xbd\xd0\xbd\xd1\x8b\xd0\xb9 do_action(‘wp-security_page_wps_scanner’), call_user_func_array, WsdPlugin::pageWpInfo, WsdUtil::includePage, include(‘/plugins/wp-security-scan/res/pages/scanner.php’), WsdUtil::loadTemplate, include(‘/plugins/wp-security-scan/res/pages/tpl/box-scan-results-wp.php’), WsdInfo::getDatabaseUserAccessRightsInfo, WsdInfoServer::getDatabaseUserAccessRights, referer: http://koldovskie.com/wp-admin/edit.ph
[Fri Oct 28 13:07:32.565084 2016] [cgi:error] [pid 808497] [client 185.8.42.190:49656] AH01215: \xd0\x91\xd0\xb0\xd0\xb7\xd0\xb0 \xd0\xb4\xd0\xb0\xd0\xbd\xd0\xbd\xd1\x8b\xd1\x85 WordPress \xd0\xb2\xd0\xbe\xd0\xb7\xd0\xb2\xd1\x80\xd0\xb0\xd1\x82\xd0\xb8\xd0\xbb\xd0\xb0 \xd0\xbe\xd1\x88\xd0\xb8\xd0\xb1\xd0\xba\xd1\x83 There is no such grant defined for user ‘wordpress_user’ on host ‘localhost:’ \xd0\xb2 \xd0\xbe\xd1\x82\xd0\xb2\xd0\xb5\xd1\x82 \xd0\xbd\xd0\xb0 \xd0\xb7\xd0\xb0\xd0\xbf\xd1\x80\xd0\xbe\xd1\x81 SHOW GRANTS FOR ‘wordpress_user’@’localhost:’, \xd0\xb2\xd1\x8b\xd0\xbf\xd0\xbe\xd0\xbb\xd0\xbd\xd0\xb5\xd0\xbd\xd0\xbd\xd1\x8b\xd0\xb9 do_action(‘wp-security_page_wps_scanner’), call_user_func_array, WsdPlugin::pageWpInfo, WsdUtil::includePage, include(‘/plugins/wp-security-scan/res/pages/scanner.php’), WsdUtil::loadTemplate, include(‘/plugins/wp-security-scan/res/pages/tpl/box-scan-results-wp.php’), WsdInfo::getDatabaseUserAccessRightsInfo, WsdInfoServer::getDatabaseUserAccessRights, referer: http://koldovskie.com/wp-admin/edit.ph
2016/10/28 13:22:39 [error] 758338#758338: *1228135 upstream prematurely closed connection while reading response header from upstream, client: 46.72.73.255, server: koldovskie.com, request: «GET /favicon.ico HTTP/1.1», upstream: «http://127.0.0.1:8080/favicon.ico», host: «koldovskie.com

Может быть из-за этого?

Заранее благодарен за помощь.

Просмотр 13 ответов — с 1 по 13 (всего 13)

Модератор Yui
(@fierevere)

永子

7 лет, 10 месяцев назад

ошибки 500 вероятно из за нехватк памяти, или смотрите получше в логи

то что показали в логах из за плагина wp-security-scan
попробуйте его отключить и посмотрите не исправит ли это ситуацию

502 — превышено число процессов apache, возможно слишком много клиентов или процесс подвисает, что вызывает 504

и да PHP в режиме CGI памяти кушает много больше и работает сильно медленнее чем в варианте других обработчиков

dubina
(@dubina)

7 лет, 10 месяцев назад

2 самых простых решения
1 перейти на пхп 7
2 поставить cloudflare

Модератор Yui
(@fierevere)

永子

7 лет, 10 месяцев назад

перейти на пхп 7

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

поставить cloudflare

не поможет. только если высокая нагрузка на сайт, посетителями или паразитами

Автор kodovsky
(@kodovsky)

7 лет, 10 месяцев назад

Не могу сказать, что проблема решена. Сейчас в процессе.

wp-security-scan — это как раз Acunetix WP Security. О нём я написал здесь.
https://ru.wordpress.org/support/topic/%D0%BE%D1%81%D0%BE%D0%B1%D0%B5%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D0%B8-%D0%BF%D0%BB%D0%B0%D0%B3%D0%B8%D0%BD%D0%B0-acunetix-wp-security/

Вчера установил Query Monitor и начал тестировать.
Первое, что показал Query Monitor — среднее количество запросов к БД от 130 до 170.

Отключил все плагины. И включал по одному. Потребление памяти и количество запросов.
В результате отсеялся «мусор».
Количество запросов к БД на главной странице сайта 67, из которых 50 — это запросы ядра WP.

Среднее потребление памяти по данным Query Monitor — 70-80Мв.

Плагин bbPress даёт до 200 запросов к БД. Но это только при заходе на форум. Форум мне нужен для работы. Поэтому этот плагин оставил. К тому же форум закрытый, только для ограниченного числа «своих», поэтому это не критично.

Но проблему это не решило. Превышение лимитов памяти осталось.

Вчера вечером бомбил хостера скриншотами.

Почему страница /wp-admin/plugins.php где 25 запросов к БД и 80 мегабайт памяти использовано, генерируется 2.48 с., а главная страница сайта, где 67 запросов, 74 МБ памяти генерируется 0.79 с.?
А через минуту, при обновлении главной страницы сайта те же 67 запросов, те же 74МБ памяти, но страница генерируется 22 с.
И при этом access.log показывает, что в это время на сайте присутствую я, один пользователь и поисковый бот mail.ru
Значит дело не в моём сайте, а в настройках сервера хостера.

Побудил хостера проверять.

Ночью прислали ответ, что скопировали мой аккаунт на другой сервер на 72 часа для тестирования.

Параметры серверов.
Основной сервер.
Operating System : Linux
Server : Apache/2.4.6 () mpm-itk/2.4.7-03 OpenSSL/1.0.1e-fips PHP/5.4.16 mod_wsgi/3.4 Python/2.7.5
Memory usage : 83.22 MByte
PHP Version : 5.3.29
MYSQL Version : 5.5.47-MariaDB-cll-lve

Сервер для тестирования
Operating System : Linux
Server : Apache/2.4.6 () mpm-itk/2.4.7-03 OpenSSL/1.0.1e-fips PHP/5.4.16
Memory usage : 49.64 MByte
PHP Version : 5.4.16
MYSQL Version : 5.5.50-MariaDB

Те же самые страницы, те же самые скрипты, та же самая база данных — а потребление памяти почти в два раза меньше.

Но, основной сервер может выдать страницу за 0.7 секунды, а может и за 20-30 секунд. Нестабильно.
А «тестировочный» сервер выдает страницу за 2-4 секунды стабильно. Но при этом «ошибка 502» при любой активации/деактивации любого плагина.

Может быть дело в том, что «основной» сервер (51.255.85.188) обрабатывает 701 сайт? По данным http://whois.domaintools.com/51.255.85.188

Написал хостеру свои результаты тестов. Что-то там делают.
Сейчас посмотрел — «тестировочный» сервер начал выдавать страницы меньше чем за секунду. Но и памяти страницы стали потреблять по 75-80 Мб.

Так что пока что разбираемся.

Модератор Юрій
(@yube)

7 лет, 10 месяцев назад

Те же самые страницы, те же самые скрипты, та же самая база данных — а потребление памяти почти в два раза меньше.

Как вариант: на основном 64-разрядная система, на тестовом — 32-разрядная.

Модератор Yui
(@fierevere)

永子

7 лет, 10 месяцев назад

32 vs 64 не настолько различаются в памяти, overhead обычно не более 15-20%
на основном PHP в режиме CGI, поэтому цифра в 80 и более Мб — ожидаема
на тестовом — возможно работает mpm-itk + mod_php (модуль PHP для апача) , его потребление памяти как раз ожидаемо меньше в 2 раза (использование разделяемой памяти, если используется opcode cache то кешированные опкоды скриптов также вычитаются из использованной памяти PHP)

Модератор Юрій
(@yube)

7 лет, 10 месяцев назад

32 vs 64 не настолько различаются в памяти, overhead обычно не более 15-20%

Решил наконец-то проверить, на сколько действительно различаются при прочих совсем равных. Свежеустановленные на VirtualBox ubuntu 16.10 server, WP 4.6.1 и плагин Server IP & Memory Usage Display
1. Memory: 2.59 of 128 MB (2%) | WP LIMIT: 40 MB | IP 192.168.61.122 (ubuntu-16.10-64) | PHP 7.0.8-3ubuntu3 @64BitOS
2. Memory: 1.85 of 128 MB (1%) | WP LIMIT: 40 MB | IP 192.168.61.121 (ubuntu-16.10-32) | PHP 7.0.8-3ubuntu3 @32BitOS

(жаль, конечно, что php7, а не, скажем, 5.4, но переставлять ради эксперимента очень не хочется)
Модератор Yui
(@fierevere)

永子

7 лет, 10 месяцев назад
сравнение было бы интереснее если нагрузить сайт скриптами побольше. цифры маленькие просто сейчас

ну и явно используется какой-то кеш опкода
для CGI (у автора темы на основном сервере) он неэффективен
- Ответ изменён 7 лет, 10 месяцев назад пользователем Yui.
Модератор Юрій
(@yube)

7 лет, 10 месяцев назад

сравнение было бы интереснее

С радостью предоставлю это право другим экспериментаторам 🙂

ну и явно используется какой-то кеш опкода

opcache из коробки. Семерка-с.

Автор kodovsky
(@kodovsky)

7 лет, 10 месяцев назад

В общем, по итогам принято решение остаться на «тестировочном» сервере.

Что там хостер «докручивал» не знаю. Но сайт сейчас стабильно генерирует страницы максимум за 1.5 секунды. Правда, и потребление памяти 70-80 мегабайт.
Ну да ладно.

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

Был один момент при отладке. Постоянно ошибка 502 при активации/деактивации плагина, размещении записи в блоге, размещении/редактировании/удалении поста на форуме.

При этом само действие производится — аплагин активируется, запись добавляется. Но это видно после перезагрузки страницы.

Этот глюк исчез когда в wp-config.php вернул обратно WP_DEBUG: false

Но сайт еще оптимизировать и оптимизировать.

Вопрос к сообществу.
Что можете посоветовать по поводу оптимизации. Я имею в виду какие толковые руководства к изучению.

Модератор Yui
(@fierevere)

永子

7 лет, 10 месяцев назад

Постоянно ошибка 502 при активации/деактивации плагина, размещении записи в блоге, размещении/редактировании/удалении поста на форуме.

а сама запись сколько размещается? т.е. сколько проходит времени между нажатием на кнопку и появлением страницы ошибки?
вероятно у хостера на nginx задано слишком маленькое значение fastcgi_read_timeout или proxy_read_timeout

Автор kodovsky
(@kodovsky)

7 лет, 10 месяцев назад

а сама запись сколько размещается? т.е. сколько проходит времени между нажатием на кнопку и появлением страницы ошибки?

Секунд 10-15 проходило.

вероятно у хостера на nginx задано слишком маленькое значение fastcgi_read_timeout или proxy_read_timeout

Может быть.
Но сейчас уже это не важно.
Сайт пока работает стабильно и шустро.

1 перейти на пхп 7

Можно и так. Если взять VPS. Возможно, через пару месяцев так и сделаю.

И всё ещё раз повторю просьбу.
Пожалуйта, дайте наводку на толковые мануалы по оптимизации вордпресс.

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

Но не хотелось бы «разгребать» кучи «советов ни о чем» из выдачи гугла.

wpgear
(@wpgear)

7 лет, 10 месяцев назад

На мой взгляд, если вы действительно заинтересованны результатами, то имеет смысл переходить на выделенный сервер.

Иначе, все представленные тесты просто не имеют смысла по причине того, что вы не можете выделить свои ресурсы на фоне сторонних. (что вы там говорили про 701 сайт?)

Это все равно, что измерять яркость фонарика на фоне фонарного столба.