Wordpress жрет оперативную память
Разберемся с установленной темой
Если на сайте стоит шаблон с нелицензионного ресурса, он не проходил или не прошел проверку аккредитованных специалистов, он может провоцировать нагрузку WordPress на CPU. В этом случае для решения проблемы достаточно изменить тему.
То, что wordpress кушает немало памяти, думаю, всем известно. Я периодически выкладываю на своем блоге некоторые посты, которые могут быть полезны при оптимизации wordpress.
Чтобы уменьшить потребляемую wordpress память я по стопам Макса делал прямой перевод wordpress 2.6.5 и wordpress 2.9, которыми, в принципе, доволен. Жесткий перевод движка позволял сократить 3-4 Мб оперативной памяти и позволял генерировать страницу немного быстрее, но терялся потенциал мультиязычности. Простым пользователям, далеким от всех этих «интернет штучек», достаточно сложно установить/обновить wordpress самостоятельно, хотя лично я считаю, что это того стоит!
Сергеем Бирюковым был написан плагин, который позволяет не так хорошо, как в прямом переводе, но в значительной мере решить проблему затрат памяти на локализацию. Он написал очень полезный плагин Pure PHP Localization, который позволяет уменьшить потребление памяти на 2-3 мб в wordpress. Кроме того плагин также сокращает память, потребляемую файлами локализациями плагинов и темы, т.е. чем небольше у вас на блоге плагинов, с русской локализацией, тем ощутимее будет прирост.
Я решил не распространять и полностью отказаться от распространения прямого перевода wordpress 2.9. Т.к. реализованный Сергеем способ является «из коробки». Т.е. не требует от пользователя никаких телодвижений. Просто поставил и активировал в админке. Разница в памяти между этими способами небольшая и она того не стоит.
ru_RU_lite
Этот способ скорее всего всем известен и уже давно широко применяется — использование облегченных файлов локализации ru_RU_lite.
В родном файле локализации ru_RU содержится перевод всего движка и плагина akismet (я им не пользуюсь, поэтому файл локализации можно сократить файл на несколько десятков строк). На самом сайте многие строки файла локализации, которые используются в админке не нужны, но они занимают память не принося пользы. Чтобы такого не происходило используется файл перевода ru_RU_lite, который содержит только необходимые строки перевода и весит в разы меньше. Это позволяет сократить порядка 1 Мб памяти, все зависит от настроек хостинга и тд. Также можно сделать с файлами локализации плагинов (в шаблоне стоит просто переименовать файл локализации).
В сборки Ивана Калинина (Lecactus) файл ru_RU_lite уже есть в дистрибутиве и в файле wp-config.php есть все нужные строки, которые позволяют использовать облегченный перевод. Нужно просто эти строки(у) раскомментировать.
Если у вас нет файлов ru_RU_lite.po и ru_RU_lite.mo в директории \wp-content\languages\ то скачать файлы облегченного перевода можно здесь или найти на сайте Ивана Калинина и в файле wp-config.php вместо
Показатели на моем локалхосте до применения вышеописанных методов
Php eaccelerator
Установка на хостинге php eaccelerator позволяет уменьшить потребляемую wordpress память в несколько раз. У меня на VDS Php eaccelerator уменьшил показатель потребляемой памяти в 9 раз. Блог потребляет всего 1,5 Мб памяти.
Сказать точно и грамотно я не могу за счет чего идет такой прирост, думаю, если интересно, то можно узнать на проекте Php eaccelerator о принципах работы. Кто разбирается в php, думаю, подскажут правильно, точно и понятно, что там происходит.
Запросы в wordpress
Есть два пути уменьшения запросов к БД:
1) Полностраничное кэширование.
2) Кэширование запросов
Про полностраничное кэширование уже много писали, поэтому не буду заострять на этом много внимания. Хочу лишь дать ссылку на относительно свежий обзор плагинов полностраничного кэширования для wordpress.
Для получения информации о кэшировании запросов в wordpress идем тоже к Владимиру Колесникову. Я писал об этом этом замечательном плагине, который позволяет очень сильно уменьшить количество запросов к базе данных. На чистом wordpress 2,9 с дефолтным шаблонов количество запросов к БД снижается с 19 до 3. Спасибо Владимиру! Чем ни больше плагинов у вас установлено и чем ни больше запросов к БД делает ваш шаблон, тем более ощутимая экономия получается.
Запросы в премиум шаблонах
Основным источников дополнительных запросов являются в большей степени плагины, но шаблоны тоже делают «лишнии» запросы к БД.
В премиум темах для wordpress бывает такое, что на странице настроек темы в админке можно сделать различные настройки, что, в принципе, удобно для простых пользователей. Но часто каждая опция реализована в виде отдельного запроса get_option('name_option'), где 1 поле соответствует 1 значение, что порой является причиной лишних обращений к БД и делает БД немного «солиднее». Можно объединить все значения в массив и сохранить результат в 1 поле. Т.к. образом для того чтобы вынуть все нужные настройки темы производиться только 1 запрос к БД, то что запрос немного «тяжелее», думаю можно пренебречь. Из 2х зол выбираем меньшую.
Прочее
Процесс оптимизации не имеет границ )
В данном посте я хотел затронуть самые эффективные способы оптимизации именно wordpress, которые я знаю и используюсь. Также есть много способов, заставить сайт работать «шустрее», начиная от объединения картинок в спрайты, до настроек веб сервера.
Представьте такую картину: сайт на WordPress практически не работает на хостинге из-за предельной нагрузки на CPU. Причину медленной работы или, вернее сказать, полной невозможности загрузки сайта, я узнал от техподдержки своего хостинга Джино. Мне сообщили, что мой аккаунт периодически превышает допустимое ограничение по нагрузке на CPU и в период превышения производится автоматическое ограничение ресурсов для стабильной работы сервера.
А на вкладке Графики нагрузки наблюдается солидное превышение жесткого лимита:
а чего вы хотите что бы 500мб оперативы хватало для обработки большого количества запросов? я бы вообще побоялся размещать сайты на таком впс.
надо поставить xcache, для вп есть плагин хороший DB Cache Reloaded Fix && WPLANG Lite и посмотреть что там в конфигах, можно повыкидывать все лишние модули с веб сервера и т.д, а еще лучше вообще кэшировать в nginx, wp приделать просто.
Медлительность сайта не нравится всем: владельцу, посетителям, поисковым роботам. Симптоматика обычно показывает долгий ответ сервера, нестабильность работы, чрезмерную и спонтанную нагрузку на CPU, но количество задействованных процессов остается на минимальном уровне.
Понять причину такого явления сложно. Ясно одно: нужна оптимизация использования CPU в WordPress для восстановления производительности ресурса. Проводится она несколькими способами. Какой из них сработает в конкретном случае? Не разобраться без тестирования, поэтому рассмотрим все методики.
Пройдемся по работающим плагинам
Найти проблемные плагины помогает инструмент GTmetrix. Его использование интуитивно понятно: вводим ссылку, получаем анализ.
Если какой-то элемент в отчете появляется больше одного раза, его стоит удалить или заменить на облегченный вариант.
Примеры тяжелых программных модулей:
- WooCommerce
- Wordfence
- Jetpack
- Gravity Forms
- Visual Composer
Есть и определенные настройки плагинов, вызывающие нагрузку WordPress на CPU: отчеты о трафике, текущие проверки, которые требуют регулярного сканирования, отправки уведомлений. Некоторые модули включают множество ненужных функций (heartbeat API, Gravatars, Emojis).
Чтобы снизить нагрузку WordPress, стоит избегать дублирования функций разными модулями. Установленный Yoast делает карту сайта, поэтому Google XML Sitemaps удаляем. Если хостинг предоставляет услугу создания резервных копий, можно отключить в админке бэкап. Или Google Analytics, собирающий мощную статистику, — ему не нужны помощники.
У многих тяжеловесных модулей есть и облегченные версии. Когда нет возможности удалить или заменить сложные плагины, стоит попробовать другие способы оптимизации и при необходимости купить виртуальный сервер с увеличенными системными параметрами.
Один комментарий к “ Сайт на WordPress максимально нагружает сервер ”
Вот вот. Я тоже вначале сайт на Joomla сделал. И были проблемы с индексацией: некоторые разные страницы разные поисковики не индексировали. Поскольку сайт потом почти статический стал, перевёл его на простой HTML без какой-либо CMS.
Когда вы приобретаете сервер VPS с 256MB или 512MB оперативной памяти на борту и лишь часть мощности процессора, то использовать для таких сервисов как MySQL/PHP/Apache настройки по умолчанию является очень плохой идеей. В настоящее время у меня запущено 3 сайта на самом дешевом тарифном плане с 512MB RAM/1 CPU. Не уверен полностью, но посещаемость составляет порядка 5-10 тысяч посетителей в день. Далее я хочу поделиться инструкцией как оптимизировать LAMP используя всего лишь 512 MB и при этом не уходя в swap. Обычно при такой настройки используется 256 – 378Mb памяти и все работает довольно быстро.
Определяем доступную память и активность swap.
Перед началом оптимизации давайте взглянем на количество используемой памяти. Для этого необходимо выполнить следующую команду:
Для того. чтобы посмотреть список запущенных процессов и отсортировать их по использованию памяти, необходимо выполнить вот такую команду:
Настраиваем LAMP сервер для потребления малого количества оперативной памяти. Останавливаем, отключаем ненужные сервисы
Первый и очевидный вопрос, который необходимо задать — это «какие сервисы мне не нужны в использовании?». Недавно, я обнаружил очень удобную утилиту для управления сервисами. Она называется "sysv-rc-conf" и управляет сервисами при помощи псевдографики и флажками. Выгдялит вот так:
Здесь представлен список сервисов, которые я изменил.
Не запускайте X-сервер, выключите все ненужные сервисы и настройте Apache, MySQL, PHP только с базовой необходимой функциональностью.
Apache
Самая большая проблема Apache — это объем оперативной памяти, который он использует. Я буду рассматривать следующие способы ускорения работы и снижения потребления оперативной памяти:
- Обрабатывать меньшее количество одновременных запросов;
- Меньшая загрузка модулей(отключить неиспользуемые);
- Меньше журналирования.
Настроить Apache на использование только наименьшего количество запущенных дочерних процессов
Prefork — это где случается настоящая магия. Это то, где мы говорим Apache генерировать много процессов. По умолчанию выделяется большое количество, что и приводит к потреблению оперативной памяти сервера. Убедитесь, что apache2.conf не настроен для запуска слишком большого количества серверов или имеет множество запасных. Ниже пример:
Также обязательно отрегулируйте параметр "KeepAliveTimeout", установив значение 10 или 15. На мой взгляд, 15 секунд слишком много, чем маленькой странице требуется для просмотра и короче, чем требуется для длительного просмотра страницы.
Загружайте только самые необходимые модули
Настроенный по умолчанию веб-сервер Apache подгружает слишком много ненужных модулей. Проверить какие модули установлены и включены можно следующей командой:
Ниже представлен список модулей, которые необходимы для работы Wordpress.
Вам необходимо закомментировать остальные модули для экономии памяти. Или же вы можете включить/отключить модули через командную строку. Для включения воспользуйтесь командой:
После проделанных манипуляций вам необходимо обязательно перезагрузить веб-сервер Apache:
Уменьшаем журналирование
Меня устраивают такие настройки, ну а вы сами решайте.
Оптимизация MySQL сервера
Тонкая настройка MySQL для использования малого количества оперативной памяти довольно проста.
Далее мы будем рассматривать следующие типы настроек MySQL:
- Вещи, которые мы можем отключить;
- Оптимизация параметров MySQL сервера;
- Сторонние инструменты настройки конфигурации MySQL.
Для оптимизации MySQL нам необходимо отредактировать файл /etc/mysql/my.cnf.
Вещи, которые нам необходимо выключить
- MyISAM предлагает блокировки на уровне таблиц, это значит, что когда информация записывается в таблицу, то вся таблица блокируется и если в этот момент будут еще записи, которые должны выполнится одновременно в ту же таблицу, то они должны будут подождать, пока первая запись добавиться успешно;
- InnoDB, с другой стороны предлагает блокировки на уровне строк, это значит, что когда происходит запись в строку, то только эта единичная строка блокируется; остальные же доступны для записи.
Проблемы блокировок табличного уровня заметны только на очень нагруженных серверах. Для обычных же веб-сайтов, MyISAM показывает лучшую производительность на дешевых серверах.
Если вы решили использовать MyISAM таблицы, то вам необходимо добавить следующие строки в конфигурационный файл my.cnf:
Если у вас будут только MyISAM таблицы, вы можете отключить InnoDB движок, тем самым сэкономив оперативную память, добавив лишь одну строку в my.cnf:
Если вы в прошлом использовали InnoDB, то ниже я предоставляю вам скрипт, который автоматически переконвертирует все таблицы InnoDB в MyISAM.
Оптимизируем параметры MySQL сервера
Ниже представлены несколько параметров, которые могут быть отрегулированы с целью ускорения MySQL сервера.
Key buffer size
Это один из самых важных параметров, влияющий на потребление оперативной памяти и производительности, который необходимо оптимизировать. MySQL пытается положить все, что проиндексировано в key buffer, поэтому этот параметр приносит огромную производительность. SQL-запрос будет подан непосредственно из оперативной памяти RAM. Я не могу сказать, какой размер вы должны установить для key buffer, потому что только вы знаете, сколько RAM имеется у вас свободной.
The Query Cache
Если вы делаете одинаковые запросы два раза подряд, то результат помещается в кэш запросов, таким образом mysql не придется делать запрос снова. Если вы собираетесь повышать производительность, то этот параметр может принести огромную пользу, но возрастет потребление памяти. Поэтому вам необходимо установить этот параметр не слишком огромным, но и не слишком маленьким, то есть столько, сколько необходимо вашему веб-сайту.
Ниже приведены три переменные, которые влияют на то, как работает ваш кэш запросов:
Maximum Number of Connections
Это опциональный параметр. Если вы уже ограничили количество процессов apache, то все уже хорошо. Если нет, и вам необходимо обрабатывать тысячи пользователей одновременно, необходимо увеличить значение этого параметра.
The table Cache
Каждый раз вы обращаетесь к таблице, MySQL подгружает ссылку на таблицу как одну запись в кэш таблицы. Это делается для каждого параллельного доступа к таблице, это действительно важно для производительности, незначительно для использования памяти. Вы можете постоянно увеличивать кэш таблицы, но тогда лы упретесь в лимит на количество открытых файлов в вашей операционной системе, так что имейте это в виду. Если установлен слишком маленький кэш таблицы, то mysql будет блевать на вас, вы же не хотите этого.
Ниже приведен корректный my.cnf, который я оптимизировал на моем VPS с самым низким тарифным планом.
Сторонние мастера настройки MySQL
Я нашел Percona, которая предоставляет бесплатную настройку MySQL и помогает выбрать самые лучше возможности MySQL сервера для достижения лучшей производительности, а также сэкономить время, избежать сложных моментов и рисков, которые могут возникнуть при самостоятельной настройке my.cnf.
Мониторинг MySQL сервера
MySQL хранит статистику, которая помогает определить самые лучшие значения для использования. Кроме этого, имеются две удобные утилиты, которые можно использовать для чтения этой статистики и выводить в понятном формате: tuning-primer.sh and mysqltuner.pl.
Эти скрипты позволят мониторить ваш MySQL сервер, и после предоставят подсказку о параметрах, которые необходимо настроить на вашем сервере.
Оптимизация PHP и кэширование
PHP не очень интенсивно использует память, поэтому я не думаю, что нужно сильно беспокоится о потреблении памяти этим процессов, если ваше приложение не нуждается в этом, но даже в случае необходимости оптимизации, значительно уменьшения потребляемой памяти не будет. Но я исследовал и потом нашел несколько настроек для PHP конфигурации, которые уменьшают потребления памяти веб-сервером.
Alternative PHP Cache
Установите PHP Cache, например, такой как, Alternative PHP Cache. PHP cache будет хранить скомпилированные PHP скрипты таким образом, что они будут заново использованы без компиляции и, соответственно, не создадут нагрузку:
Ниже мой сконфигурированный php.ini файл.
Static Cache
Заключение
Я выложил в открытый доступ конфигурацию моего веб-сервера, чтобы доказать, что можно добиться высокой производительности даже от самого дешевого VPS контейнера с 512МБ RAM и 1Ghz CPU. Использую я Ubuntu 12.04 LTS, LAMP, Varnish,APC Cache для размещения 3-х веб-сайтов, сделанных на Wordpress (не мультисайтовых) с посещаемостью 10к в день. Давайте взглянем на результаты тестов от Blitz.io:
Как видите, 0,23% пользователей получают Connection Timeout, когда мой веб-сайт имеет 42,735,587 хитов в день (WOW), может можно еще что-то оптимизировать, но я получаю удовольствие от работы моего веб-сервера. Если ты устал от этого руководства или не хочешь делать руками, то можешь воспользоваться такими сервисами, как PuPHPet или Vagrant.
Материалы по теме:
Испробовав несколько способов установки постраничной навигации на сайт Wordpress, я сделал выбор в пользу плагина WP-PageNavi.
Для противников использования большого количества плагинов в Wordpress предлагаю вариант создания постраничной навигации без их применения.
Одним из нескольких действенных способов оптимизации блога и снижения нагрузки на сервер хостинга является кэширование.
artstyle, наймите сис. админа, который Вам настроит сервер.
P.S. Панель управления не занимается тюнингом ПО на сервере!
24519 www-data 15 0 85844 49m 5980 S 0.0 9.7 0:06.21 apache2
28053 www-data 16 0 73252 37m 6444 S 0.0 7.4 0:02.16 apache2
28464 www-data 16 0 73224 37m 5720 S 0.0 7.2 0:01.60 apache2
23615 www-data 15 0 73240 37m 5916 S 0.0 7.3 0:03.08 apache2
22113 www-data 15 0 80200 43m 5648 S 0.0 8.5 0:04.84 apache2
22114 www-data 15 0 62968 25m 5156 S 0.0 5.1 0:03.28 apache2
22172 www-data 15 0 90664 47m 5608 S 0.0 9.3 0:04.85 apache2
22175 www-data 15 0 46312 9468 4608 S 0.0 1.8 0:00.46 apache2
14269 www-data 15 0 80192 43m 5692 S 0.0 8.5 0:01.86 apache2
18058 www-data 15 0 61968 26m 6200 S 0.0 5.2 0:03.61 apache2
1341 root 15 0 45368 8856 5060 S 0.0 1.7 0:09.53 apache2
в основном апач грузит систему.
где искать и куда смотреть?
дада именно он. ребутаю апач и потребление памяти сбрасывается.
Почему это происходит?
Причин может быть несколько. Для примера, опишу свою. Я подозреваю, что в моём случае это происходило по вине поисковых роботов. Дело в том, что мой сайт годом ранее попал под АГС Яндекса. Принимаемые меры вывода не привели к положительному результату и я решил пойти своим путем. Я поставил сайт на Джумлу, затем перенес на Вордпресс. Проиндексировались все варианты и, соответственно, стало много 404-х ошибок. На Вордпресс-сайте в тот момент не было ничего лишнего, 9 плагинов установленных, да и страниц относительно немного, но, как видите, сервер он грузил по полной программе.
Варианты устранения проблемы
1. Отключить wp-cron.php
wp-cron.php — это скрипт, отвечающий за выполнение различных задач. Основные из них:
- проверка обновлений WordPress и плагинов;
- запланированная публикация постов;
- рассылка уведомлений о новых комментариях и прочих событиях;
- запуск плагинов, таких например как Akismet для фильтрации комментариев на наличие спама;
- оповещение сторонних сервисов о публикации нового материала.
Если выполнение этого файла вызывает нездоровую нагрузку на сервер — можно отключить эти задачи. Для этого в файл конфигурации WordPress wp-config.php добавляем строку:
Добавить её можно там, где есть другие строки с define .
Второй вариант решения — в самом файле wp-cron.php закомментировать строку:
- В этом коде применен один из способов временного отключения (закомментирования) строки в виде двух слэшей ( // ).
- Для успешного отключения wp-cron.php необходимо выполнить оба варианта!
2. Использовать плагин heartbeat-control
3. Увеличить интервал между запросами поисковых ботов
Новая скорость сканирования будет действовать в течение 90 дней, затем все восстановится автоматом, либо это можно сделать ранее и самостоятельно. В Яндексе же для снижения нагрузки на сайт и ограничения активности поискового робота можно использовать директиву Crawl-delay , которая прописывается в файле robots.txt . Она задает поисковому роботу минимальный период времени (в секундах) между окончанием загрузки одной страницы и началом загрузки следующей. Crawl-delay поддерживается Яндексом, но не учитывается другими поисковиками, поэтому, если Вам ну уж очень важна эта директива, можно создавать несколько вариантов записей в файле robots.txt для разных поисковых ботов. Примеры записи Crawl-delay с разными таймаутами:
Директиву Crawl-delay необходимо добавить непосредственно после директив Allow и Disallow. Устанавливать слишком большой таймаут (например, до минуты), наверное некорректно. Потому, что, во-первых, теоретически, Вы можете слишком ограничить частоту обращений для индексации каждой страницы, то есть значительно замедлить индексацию сайта. А во-вторых нет гарантии, что робот обратит внимание на такие ваши рекомендации. Выбирайте для себя оптимальное значение в пределах разумной достаточности. Какое именно? Это зависит от параметров сайта.
4. Включить кэширование на сайте
- flv|gif|jpg|jpeg|png|ico|swf|js|css|pdf — это типы файлов, которые попадают под кэширование.
- max-age — указание время хранения файлов в кэше в секундах.
5. Блокировка IP — адресов
На сайтах иногда могут появляться пользователи, нарушающие правила, спамеры, хамовитые, дерзкие ребята, невзлюбившие ваш блог и т. д. Их действия, в какой-то степени, могут оказывать влияние на скорость загрузки страниц сайта в сторону замедления. Блокировать IP адреса непрошеных пользователей может помочь плагин Best WP Security . Второй вариант выполнения этой задачи — размещения следующего кода в файле .htaccess:
Для добавления нового IP дублируйте строку deny from , заменяя IP адреса .
6. Ручная оптимизация сайта
- Отключить лишние плагины, проверить корректность работы активированных. Отключайте плагины сайта по очереди и следите за его работой. Обнаружив проблемный плагин, попробуйте его обновить или установить стабильную версию, или замените аналогом, с которым не возникает проблем.
- Удалить посторонние и «левые» скрипты. Здесь могут оказать помощь различные антивирусные утилиты и качественный легальный антивирус, например, KIS. Можно попробовать проверку сайта на вирусы онлайн, набрав в поисковике соответствующий запрос.
P.S. В результате выполнения всех или нескольких пунктов в большинстве случаев проблема должна исчезнуть. Но полной гарантии никто дать не может, так как к каждому сайту нужен индивидуальный подход.
Желаю вам стабильной работы ресурса, позитива и прекрасного настроения!
система стандарт (нe nginx)
исп лайт.
2 юзера. 2 домена.
с первым сайтом все ок. хоть 200 раз ф5 тыкай максимум на 5-10 мб подгрузит. но это жесть
пустой WORDPRESS жрет по 20мб памяти в секунду
столкнулся такой проблемой.
поставил пустой вордпресс и если заходить на сайт и 10 раз в секунду тыкать Ф5 то вордпресс зажрет всю память сервера и сервер просто начнет лагать 15-20 секунд пока не отвиснет)
в чем может быть проблема?
вот видео
Читайте также: