WordPress і 512 RAM
А тут здарылася мне падымаць адзін сайт на 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:
Але дарэчы пасля ўстаноўкі 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
Спачатку /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?