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?