WordPress і 512 RAM

  1. WP Super Cache
  2. WP-Memory-Usage
  3. налады Apache
  4. налады nginx

А тут здарылася мне падымаць адзін сайт на WordPress 'Е ў дроплете DigitalOcean з 512 мегабайтамі аператыўнай памяці.

Адразу да сутнасці - у 512 метрах яму вельмі цесна.

Такім чынам, ёсць дроплет ў DigitalOcean, я рулю ім праз SSH. У дроплете варта Ubuntu, Apache, MySQL і ляжыць сайт на WordPress 'е.

Пачалося з таго, што раптам высеклі MySQL і адмовіўся стартаваць назад назад. Хоць конфіг я не змяняў і наогул нічога не чапаў, проста запусціў сайт для агульнага доступу (да гэтага заходзіў на яго толькі я адзін). Далей буду прыводзіць усе свае дзеянні па рашэнні.

Запускаў я яго такой камандай:

sudo /etc/init.d/mysql restart

На што ён мне выдаваў:

Can 't connect to local MySQL server through socket' /var/run/mysqld/mysqld.sock '(111)

Так як конфігі я не чапаў, то ўсе рэцэпты па іх рэдагавання я прапускаў. Калі ў вас сітуацыя іншая, то паглядзіце тут яшчэ . Праз некаторы час пасля чытання гэтага артыкула і форумаў высветлілася, што праблема ... у недахопе аператыўнай памяці альбо месца на дыску. Бо месцы на дыску заваліся, то застаецца аператыўка.

Інфармацыю лепш браит непасрэдна на самім серверы. Таму для маніторынгу спажывання аператыўкі на сэрвэры, а таксама для атрымання статусу MySQL (яшчэ жывы ці ўжо злёг) я запіў сабе адпраўку стану сервера праз Telegram .

Каманда праверкі выкарыстання памяці:

Вынік (у мегабайтах) выдаецца прыкладна такі:

total used free shared buffers cached Mem: 994 596 397 64 29 261 - / + buffers / cache: 305 688

Вось у мяне карціна была такая, што з 512 метраў свабодна два, а то і наогул адзін.

Для аптымізацыі выкарыстання памяці паспрабаваў прытрымлівацца радам артыкула Configuring Apache / PHP / MySQL for Low Memory (RAM) VPS - узяў з яе значэння для конфігаў MySQL і Apache. Таксама хацеў потключать модулі Apache у адпаведнасці з прапанаваным там спісам, але ён у мяне пасля такіх маніпуляцый проста не стартаваў, таму я вярнуў іх ўзад.

Накшталт стала лепей, але ад перагрузак усё адно не ратавала. Таксама пры дапамозе каманды top высветлілася, што памяць жарэ не толькі MySQL, але і Apache, толькі он-то не падае, а вось база - так.

Далей я стварыў swap па выпраўленай інструкцыі адсюль :

dd if = / dev / zero of = / swap.dat bs = 1024 count = 512k mkswap /swap.dat swapon /swap.dat

Пасля першай каманды ён трохі падумае, так як будзе стварацца swap-файл на 512 метраў.

І дадаў у файл / etc / fstab радок:

/swap.dat none swap sw 0 0

Не магу сказаць, наколькі гэта ўвогуле хоць на нешта паўплывала. Таму праз некаторы час (пасля ўстаноўкі nginx) я яго выключыў:

І выдаліў радок з / etc / fstab.

Паспрабаваў неяк аптымізаваць Wordpress з дапамогай убудоў.

WP Super Cache

Пасля гэтых маніпуляцый MySQL стартаваў, але неўзабаве зноў стаў ... Вось тут я здаўся і змяніў дроплет з 512 МБ на 1 ГБ. Але і з гігабайтам аператыўкі MySQL падаў і не паўставала.

Выратаваннем апынуўся убудова WP Super Cache - пасля яго ўключэння апантана скарацілася спажыванне за ўсё, і ўсё спакойна сабе працуе. Да гэтага нават просты праверкі праз гэты сэрвіс хапала, каб усё здох. Так што можна сказаць, што гэты убудова проста неабходны для нармальнай працы.

Наладзіў я яго так (насуперак рэкамендаваным налад):

Наладзіў я яго так (насуперак рэкамендаваным налад):

І таксама змяніў налады для Permalinks:

І таксама змяніў налады для Permalinks:

Але дарэчы пасля ўстаноўкі nginx я адключыў гэты убудова, і ўсплёску спажывання рэсурсаў не адбылося. Так што незразумела, ёсць ад яго карысць ці не.

WP-Memory-Usage

Трэба ж бо як-то сачыць за серверам, калі кампутар з SSH-тэрміналам па-за дасяжнасці.

Ёсць вось такі убудова: WP-Memory-Usage - дазваляе глядзець спажыванне памяці прама з адмінку (хоць не ведаю, наколькі значэнне адпавядае рэчаіснасці).

Мяркуючы па-ўсяму, ён паказвае не агульнае спажыванне, а канкрэтна колькі памяці спатрэбілася, каб усё прогрузить для бягучага карыстальніка, так што карысці не вельмі шмат. Выключыў.

Але самае галоўнае, што я даведаўся, і што трэба было ведаць з самага пачатку - як раз на такія выпадкі выкарыстоўваецца вэб-сервер nginx .

Схема такая:

  1. Apache пераносіцца з 80 порта на іншы, напрыклад 8080, прычым робіцца даступным толькі лакальна;
  2. Ставіцца nginx і запускаецца на 80 порту, то ёсць цяпер запыты прымае ён;
  3. Далей nginx наладжваецца такім чынам, каб php -файлы перадаваць у Apache на яго порт, а ўсё астатняе апрацоўваць самому.

Далей пойдуць інструкцыі па наладжванні, якіх я нахапаўся па форумах і блогах, дапоўненыя мной. Рэсурсаў было настолькі шмат, што я не памятаю, дзе што браў. Прабачце мяне ўсе аўтары, якіх я не паказаў.

Такім чынам, спачатку трэба паставіць плягін Permalink Fix & Disable Canonical Redirects Pack , Які выпраўляе нешта там з перанакіраваннем у Permalinks.

налады Apache

Спачатку /etc/apache2/apache2.conf:

ServerRoot "/ etc / apache2" Mutex file: $ {APACHE_LOCK_DIR} default PidFile $ {APACHE_PID_FILE} Timeout 300 KeepAlive Off MaxKeepAliveRequests 100 KeepAliveTimeout 10 User $ {APACHE_RUN_USER} Group $ {APACHE_RUN_GROUP} HostnameLookups Off ErrorLog $ {APACHE_LOG_DIR} /error.log LogLevel crit IncludeOptional mods-enabled / *. load IncludeOptional mods-enabled / *. conf Include ports.conf <Directory /> Options FollowSymLinks AllowOverride None <Limit PUT DELETE CONNECT OPTIONS PATCH PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK> deny from all </ Limit > </ Directory> <Directory / var / www> Options FollowSymLinks AllowOverride FileInfo </ Directory> <Directory / usr / share> AllowOverride None Require all granted </ Directory> AccessFileName .htaccess <FilesMatch "^ \. ht"> Require all denied </ FilesMatch> AccessFileName .htaccess <FilesMatch "^ \. ht"> Require all denied </ FilesMatch> LogFormat "% v:% p% h% l% u% t \"% r \ "%> s% O \ "% {Referer} i \" \ "% {User-Agent} i \" "vhost_combined LogFormat"% h% l% u% t \ "% r \"%> s % O \ "% {Referer} i \" \ "% {User-Agent} i \" "combined LogFormat"% h% l% u% t \ "% r \"%> s% O "common LogFormat"% {referer} i ->% U "referer LogFormat"% {User-agent} i "agent IncludeOptional conf-enabled / *. conf IncludeOptional sites-enabled / *. conf <DirectoryMatch ^. * / wp-content / uploads /> AllowOverride None php_flag engine off php_admin_value engine Off </ DirectoryMatch> <DirectoryMatch ^. * / wp-content / blogs.dir /> AllowOverride None php_flag engine off php_admin_value engine Off </ DirectoryMatch> # <DirectoryMatch ^. * / wp-admin / > # AuthType Basic # AuthName "Restricted Area" # AuthUserFile /etc/apache2/.htpasswd # Require valid-user # </ DirectoryMatch> <VirtualHost *> ServerAdmin [email protected] DocumentRoot / var / www Servername example.com ServerAlias ​​example .com www.example.com </ VirtualHost> <IfModule mpm_prefork_module> StartServers 1 MinSpareServers 1 MaxSpareServers 4 MaxClients 4 MaxRequestsPerChild 1000 </ IfModule>

Цяпер /etc/apache2/ports.conf:

Listen 127.0.0.1: 8080 <IfModule ssl_module> Listen 443 </ IfModule> <IfModule mod_gnutls.c> Listen 443 </ IfModule> # vim: syntax = apache ts = 4 sw = 4 sts = 4 sr noet

Перазапускаем сервер:

Цяпер ён працуе на порце 8080, і сайт ваш стаў недаступны з інтэрнэту. Нават калі вы паспрабуеце адкрыць яго як example.com:8080.

налады nginx

ўстаноўка:

Пішам конфіг для сайта - проста файл без пашырэння - / etc / nginx / sites-enabled / mysite:

server {listen 80; server_name example.com; root / var / www; index index.php; gzip on; gzip_disable "msie6"; gzip_types text / plain text / css application / json application / x-javascript text / xml application / xml application / xml + rss text / javascript application / javascript; location ~ / \. {Deny all; # Забарона для схаваных файлаў} location ~ * /(?:uploads|files)/.*\.php $ {deny all; # Забарона для загружаных скрыптоў} location ~ * ^. + \. (Ogg | ogv | svg | svgz | eot | otf | woff | mp4 | ttf | rss | atom | jpg | jpeg | gif | png | ico | zip | tgz | gz | rar | bz2 | doc | xls | exe | ppt | tar | mid | midi | wav | bmp | rtf) $ {access_log off; log_not_found off; expires max; # Кэшаванне статыкі} location / {try_files $ uri $ uri / /index.php?q= $ uri & $ args; } Location ~ \ .php $ {proxy_set_header X-Real-IP $ remote_addr; proxy_set_header X-Forwarded-For $ remote_addr; proxy_set_header Host $ host; proxy_pass http://127.0.0.1:8080; }}

Цяпер конфіг ўсім сэрвэры /etc/nginx/nginx.conf:

user www-data; worker_processes 1; pid /run/nginx.pid; events {worker_connections 768; use epoll; # Multi_accept on; } Http {## # Basic Settings ## sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 5; types_hash_max_size 2048; include /etc/nginx/mime.types; default_type application / octet-stream; ## # Logging Settings ## access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; ## # Virtual Host Configs ## include /etc/nginx/conf.d/*.conf; include / etc / nginx / sites-enabled / *; }

Запуск сервера і перазагрузка настроек:

service nginx start nginx -s reload

Усё, nginx працуе і раздае сайт.

Праверыць бягучы вэб-сервер можна камандай:

curl -s -I example.com | awk '$ 1 ~ / Server: / {print $ 2}'

У выніку вашчэ гэтага ўсяго - не тое, каб я заўважыў драматычнае зніжэнне спажывання аператыўкі, але падаць ад недахопу гэтай база перастала. Я паменшыў дроплет назад з 1 ГБ да 512 МБ - усё агонь. Вядома, калі адначасова падключыцца некалькі дзесяткаў карыстальнікаў, то ў нейкі момант некаторым пачне выдавацца 502 Bad Gateway, але база не падае, і як толькі нагрузка знізіцца, сайт будзе аддавацца нармальна.

Карацей, можна сказаць, што для выжывання WordPress на 512 МБ аператыўнай памяці неабходны nginx і карэктныя налады для яго, Apache і MySQL. Па жаданні таксама можна паспрабаваць розныя прыпаркі накшталт swap -файла і ўбудовы WP Super Cache.

Php?