Wordpress жрет оперативную память
Обновлено: 06.07.2024
Добрый день. Скажите, в наше время 512 рам на впс это очень мало? Если на сервере установлена панель веста и вордпресс(тем более не один а много вордпрессов). Сколько рамов для этого надо?
Смотря как настроено кэширование на сайтах и как настроена сама система.
Но, думаю, 512 MB в любом случае мало, рекомендую брать VPS от 1 GB.
Объемы памяти сейчас не такие уж дорогие.
Понятно, в этом деле я не разбираюсь, наверное лучше останусь на виртуальном хостинге. Просто я взял 512 рам и поставил туда весту и несколько сайтов. Сегодня захожу и смотрю что грузят на все 512 мегабайт . Получается это очень мало на сегодня?
mariux:Понятно, в этом деле я не разбираюсь, наверное лучше останусь на виртуальном хостинге. Просто я взял 512 рам и поставил туда весту и несколько сайтов. Сегодня захожу и смотрю что грузят на все 512 мегабайт . Получается это очень мало на сегодня?
Для Linux это нормально, процессы резервируют память под кэш и буферизацию для более быстрой работы. При недостатке памяти, часть кэша освобождается.
Наблюдайте за системным журналом операционной системы из консоли /var/log/messages или /var/log/syslog. Если какому-либо процессу не хватит памяти, то наиболее толстый процесс будет закрыт OOMKiller'ом с надписью "Out of memory".
512 мегабайт памяти вполне можно настроить так, чтобы все работало без убийства процессов. Но для этого придется поработать с Apache и mysql (или что там у вас стоит). И следует сразу рассчитывать на то, что нагрузку такие сайты будут держать невысокую. Проще чуть переплатить за память и не иметь проблем с настройками.
Выполните free -m
Если все ушло в кэш и swap не используется то все нормально. Хотя 1 Гб маловато.
512 Мб может быть достаточно. Но нужно будет поработать головой и потратить время. Большинству, выгоднее "переплатить" за 1 гб и больше, чем красноглазить в консоли.
Для вордпресса нужно гига 2. Если там много вордпрессов, то может и больше понадобится, хотя частично может помочь увеличение swap, если это норм хостинг с быстрыми не загруженными ssd.
Как вам уже сказали, при верно настроенном кэшировании и сервере (в том числе и сервере БД), 512 МБ для пары-тройки обычных (не особо посещаемых) сайтиков без кучи плагинов должно хватить. Однако, если вы задаете подобные вопросы, то сами вряд ли будете замарачиваться со всякими настройками, поэтому лучше просто возьмите виртуалку хотя бы с 1 ГБ.
Как минимизировать использование CPU в WordPress?
Рассмотрим несколько эффективных трюков и рекомендаций, которые помогут снизить нагрузку на процессор, являющийся одним из самых важных элементов в обеспечении стабильной работы вашего интернет-ресурса.
1. Удаление ненужных и “тяжелых” плагинов
Устанавливая те или иные плагины, вы таким образом добавляете на свой сайт WordPress необходимый для его работы функционал. Но довольно часто в списке активных плагинов присутствуют и такие, которые просто-напросто не не используются. Обычно такая ситуация возникает в процессе подбора и тестирования того или иного плагина. Сделав свой выбор, бывает, что просто забываем удалить те, которые не подошли. Кроме того, некоторые функции плагина могут “накладываются” друг на друга. В обоих случаях всегда полезно удалить эти плагины, снизив таким образом нагрузку на CPU.
Важно помнить, что способов удаления плагинов существует несколько. Наиболее безопасным среди них является использование стандартных инструментов WordPress. Для этого существует целый админ-раздел Плагины, где в списке необходимо выбрать плагин, затем нажать кнопку Удалить.
Иные способы менее безопасны и требуют понимания принципов “движка”.
Еще одним важным моментом, связанным с плагинами WordPress, является их надменное потребление ресурсов сервера.
Так, среди их большого количества, существуют и такие, которые способны оказать значительное влияние на производительность сайта. Высокую нагрузку создает присутствие в них тяжелых библиотек и скриптов, для выполнения которых требуется больше ресурсов. О таких плагинах мы писали в одной из наших прошлых статей.
Таких плагинов, бесспорно, следует избегать, если вы хотите, чтобы использование процессора контролировалось.
Если вы не уверены, какие именно плагины чрезмерно “прожорливы” к ресурсам, можно воспользоваться бесплатным хостингом (например, Beget ) или испытать их на локальном сервере. В обоих случаях вы сможете установить полноценную копию WordPress, на которой тестировать работу и поведение того или плагина. Если выбранный плагин устраивает, то можете установить его на своем веб-сайте.
2. Использование WP Disable
Он также предоставляет подробную статистику, доступную в админ-панели вашего сайта. Рекомендуется отключать функции, которые вам действительно не нужны. Помните, что вы всегда можете включить их обратно. Кроме того, если вы не уверены в опции и что она делает, лучше ее игнорировать.
3. Оптимизация изображений
Для этого можно воспользоваться специальными инструментами (например, бесплатным приложением PNGGauntlet ).
Кроме того, неплохо задействовать на своем сайте автоматическую оптимизацию изображений (об этом мы писали в одной из наших прошлых статей).
4. Настройка правил обхода сайта роботами
Любой веб-сайт, доступный в Сети, сканируется множеством роботов. Но не все они полезны. Некоторые из них могут использовать ваши данные для сторонних целей. Когда робот сканирует сайт, он создает дополнительную нагрузку на центральный процессор сервера, обслуживающего ваш сайт. Чтобы обезопасить свой сайт от этого, вы можете легко заблокировать их и позволить сканировать свой веб-ресурс лишь некоторым из них.
Поисковая система Bing также предлагает аналогичный контроль скорости сканирования. Вы можете сделать это, перейдя в Bing Webmasters Tools, а затем изменить ее в настройках Crawl Control.
6. Очистка базы данных
Регулярные запросы к базе данных вашего сайта добавляют в нее много избыточной информации, которая впоследствии больше никогда не будет использована (например, ревизии постов, промежуточная информация во время выборок и пр.) Помимо этого, когда вы удаляете плагин, он все же оставляет некоторые данные в базе данных. От всего этого она может “раздуться” до больших размеров.
Наиболее корректным способом решения этой задачи является задействование специальных инструментов, которые удаляют все лишнее из базы данных вашего сайта. Наиболее популярным среди WordPress-пользователей является бесплатный плагин WP-Optimize .
Нажмите, пожалуйста, на одну из кнопок, чтобы узнать понравилась статья или нет.
А тут случилось мне поднимать один сайт на WordPress‘е в дроплете DigitalOcean с 512 мегабайтами оперативной памяти.
Сразу к сути - в 512 метрах ему очень тесно.
Итак, есть дроплет в DigitalOcean, я рулю им через SSH. В дроплете стоит Ubuntu, Apache, MySQL и лежит сайт на WordPress‘е.
Началось с того, что вдруг вырубился MySQL и отказался стартовать обратно обратно. Хотя конфиг я не изменял и вообще ничего не трогал, просто запустил сайт для общего доступа (до этого заходил на него только я один). Дальше буду приводить все свои действия по решению.
Запускал я его такой командой:
На что он мне выдавал:
Так как конфиги я не трогал, то все рецепты по их редактированию я пропускал. Если у вас ситуация другая, то посмотрите тут ещё. Через некоторое время после чтения этой статьи и форумов выяснилось, что проблема… в нехватке оперативной памяти либо места на диске. Так как места на диске завались, то остаётся оперативка.
Информацию лучше браит непосредственно на самом сервере. Потому для мониторинга потребления оперативки на сервере, а также для получения статуса MySQL (ещё жив или уже слёг) я запилил себе отправку состояния сервера через Telegram.
Команда проверки использования памяти:
Результат (в мегабайтах) выдаётся примерно такой:
Вот у меня картина была такая, что из 512 метров свободно два, а то и вообще один.
Для оптимизации использования памяти попробовал следовать советам статьи Configuring Apache/PHP/MySQL for Low Memory (RAM) VPS - взял из неё значения для конфигов MySQL и Apache. Также хотел потключать модули Apache в соответствии с предложенным там списком, но он у меня после таких манипуляций просто не стартовал, потому я вернул их взад.
Вроде стало получше, но от перегрузок всё равно не спасало. Также при помощи команды top выяснилось, что память жрёт не только MySQL, но и Apache, только он-то не падает, а вот база - да.
Далее я создал swap по исправленной инструкции отсюда:
После первой команды он немного подумает, так как будет создаваться swap-файл на 512 метров.
И добавил в файл /etc/fstab строку:
Не могу сказать, насколько это вообще хоть на что-то повлияло. Потому через некоторое время (после установки nginx) я его выключил:
И удалил строку из /etc/fstab .
Попробовал как-то оптимизировать Wordpress с помощью плагинов.
WP Super Cache
После этих манипуляций MySQL стартовал, но вскоре опять встал… Вот тут я сдался и сменил дроплет с 512 МБ на 1 ГБ. Но и с гигабайтом оперативки MySQL падал и не поднимался.
Спасением оказался плагин WP Super Cache - после его включения неистово сократилось потребление всего, и всё спокойно себе работает. До этого даже простой проверки через этот сервис хватало, чтобы всё издохло. Так что можно сказать, что этот плагин просто необходим для нормальной работы.
Настроил я его так (вопреки рекомендуемым настройкам):
И также изменил настройки для Permalinks:
Но кстати после установки nginx я отключил этот плагин, и всплеска потребления ресурсов не произошло. Так что непонятно, есть от него польза или нет.
WP-Memory-Usage
Надо же ведь как-то следить за сервером, когда компьютер с SSH-терминалом вне досягаемости.
Есть вот такой плагин: WP-Memory-Usage - позволяет смотреть потребление памяти прямо из админки (хотя не знаю, насколько значение соответствует действительности).
Судя по-всему, он показывает не общее потребление, а конкретно сколько памяти потребовалось, чтобы всё прогрузить для текущего пользователя, так что пользы не очень много. Выключил.
Но самое главное, что я узнал, и что должен был знать с самого начала - как раз на такие случаи используется веб-сервер nginx.
- Apache переносится с 80 порта на другой, например 8080 , причём делается доступным только локально;
- Ставится nginx и запускается на 80 порту, то есть теперь запросы принимает он;
- Далее nginx настраивается таким образом, чтобы php-файлы передавать в Apache на его порт, а всё остальное обрабатывать самому.
Дальше пойдут инструкции по настройке, которых я нахватался по форумам и блогам, дополненные мной. Ресурсов было настолько много, что я не помню, где что брал. Простите меня все авторы, которых я не указал.
Итак, сначала надо поставить плагин Permalink Fix & Disable Canonical Redirects Pack, который исправляет что-то там с перенаправлениями в Permalinks.
Настройки Apache
Настройки nginx
Пишем конфиг для сайта - просто файл без расширения - /etc/nginx/sites-enabled/mysite :
Теперь конфиг всего сервера /etc/nginx/nginx.conf :
Запуск сервера и перезагрузка настроек:
Всё, nginx работает и раздаёт сайт.
Проверить текущий веб-сервер можно командой:
В результате ваще этого всего - не то, чтобы я заметил драматическое снижение потребления оперативки, но падать от нехватки оной база перестала. Я уменьшил дроплет обратно с 1 ГБ до 512 МБ - всё огонь. Конечно, если одновременно подключится несколько десятков пользователей, то в какой-то момент некоторым начнёт выдаваться 502 Bad Gateway, но база не падает, и как только нагрузка снизится, сайт будет отдаваться нормально.
Короче, можно сказать, что для выживания WordPress на 512 МБ оперативной памяти необходим nginx и корректные настройки для него, Apache и MySQL. По желанию также можно попробовать различные припарки вроде swap-файла и плагина WP Super Cache.
Медлительность сайта не нравится всем: владельцу, посетителям, поисковым роботам. Симптоматика обычно показывает долгий ответ сервера, нестабильность работы, чрезмерную и спонтанную нагрузку на 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 на CPU. В этом случае для решения проблемы достаточно изменить тему.
Читайте также: