WordPress i 512 RAM
I wtedy zdarzyło mi się podnieść jedną stronę Wordpress 'w kropli Digitalocean z 512 megabajtami pamięci RAM.
Natychmiast do punktu - w 512 metrach jest bardzo blisko.
Tak więc w DigitalOcean jest kropla, którą steruję przez SSH. W kropli znajduje się Ubuntu , Apache , MySQL i jest to witryna WordPress .
Zaczęło się od tego, że MySQL nagle stracił przytomność i odmówił ponownego rozpoczęcia. Chociaż nie zmieniłem konfiguracji i niczego nie dotknąłem, właśnie uruchomiłem witrynę do publicznego dostępu (wcześniej byłem jedynym, który ją odwiedził). Nadal będę podejmował wszystkie moje działania w sprawie decyzji.
Zacząłem od tego polecenia:
sudo /etc/init.d/mysql restart
Co mi dał:
Czy nie można połączyć się z lokalnym serwerem MySQL przez gniazdo '/var/run/mysqld/mysqld.sock' (111)
Ponieważ nie dotknąłem configów, brakowało mi wszystkich przepisów na ich edycję. Jeśli twoja sytuacja jest inna, patrz tu jeszcze . Jakiś czas po przeczytaniu tego artykułu i forów okazało się, że problemem jest ... brak pamięci RAM lub miejsca na dysku. Ponieważ miejsce na dysku jest pełne, pamięć RAM pozostaje.
Informacje są lepiej pobierane bezpośrednio na samym serwerze. Dlatego, aby monitorować zużycie pamięci RAM na serwerze, a także uzyskać status MySQL (wciąż żywy lub już nie żyje), zapisałem wysyłanie statusu serwera przez telegram .
Polecenie sprawdzające wykorzystanie pamięci:
Wynik (w megabajtach) jest mniej więcej taki:
całkowita ilość użytych darmowych buforów udostępnionych w pamięci podręcznej Mem: 994 596 397 64 29 261 - / + bufory / pamięć podręczna: 305 688
Moje zdjęcie było więc takie, że na 512 metrów są dwa wolne, jeśli nie jedno.
Aby zoptymalizować wykorzystanie pamięci, starałem się podążać za wskazówkami artykułu. Konfiguracja Apache / PHP / MySQL dla VPS o niskiej pamięci (RAM) - wziął z niego wartości dla MySQL i Apache configs. Chciałem także włączyć moduły Apache zgodnie z sugerowaną tam listą, ale nie uruchomiłem go po takich manipulacjach, więc zwróciłem je.
Wydaje się, że jest lepiej, ale nadal nie oszczędzał przed przeciążeniami. Ponadto, używając górnego polecenia, okazało się, że nie tylko MySQL zjada pamięć, ale Apache , tylko nie spada, ale baza robi.
Następnie utworzyłem wymianę dla poprawionych instrukcji. stąd :
dd if = / dev / zero of = / swap.dat bs = 1024 liczba = 512k mkswap /swap.dat swapon /swap.dat
Po pierwszym poleceniu pomyśli trochę, ponieważ zostanie utworzony plik wymiany o długości 512 metrów.
I dodałem linię do pliku / etc / fstab:
/swap.dat none swap sw 0 0
Nie mogę powiedzieć, jak bardzo coś na to wpłynęło. Ponieważ po chwili (po zainstalowaniu nginx ) wyłączyłem go:
I skasowałem linię z / etc / fstab.
Próbowałem jakoś zoptymalizować Wordpressa za pomocą wtyczek.
WP Super Cache
Po tych manipulacjach MySQL uruchomił się, ale wkrótce wstał ... A potem poddałem się i zmieniłem kroplę z 512 MB na 1 GB. Ale nawet z gigabajtem MySQL RAM spadł i nie wzrósł.
Zbawienie było wtyczką WP Super Cache - po włączeniu zużycie wszystkiego gwałtownie spadło i wszystko działa cicho dla siebie. Wcześniej nawet proste sprawdzenie ta usługa wystarczy dla wszystkich izdohlo. Możemy więc powiedzieć, że ta wtyczka jest po prostu niezbędna do normalnego działania.
Ustawiłem to w ten sposób (pomimo zalecanych ustawień):
A także zmienił ustawienia Permalinków :
Ale przy okazji, po zainstalowaniu nginx, wyłączyłem tę wtyczkę i nie nastąpił gwałtowny wzrost zużycia zasobów. Nie jest więc jasne, czy istnieje z tego jakaś korzyść.
WP-Memory-Usage
W końcu trzeba jakoś monitorować serwer, gdy komputer z terminalem SSH jest poza zasięgiem.
Jest taka wtyczka: WP-Memory-Usage - pozwala oglądać zużycie pamięci bezpośrednio od administratora (chociaż nie wiem, ile ta wartość odpowiada rzeczywistości).
Najwyraźniej nie pokazuje całkowitego zużycia, ale przede wszystkim ilości pamięci potrzebnej do załadowania wszystkiego dla bieżącego użytkownika, więc nie ma większego zastosowania. Wyłączony.
Ale najważniejszą rzeczą, której się nauczyłem i co powinienem wiedzieć od samego początku, jest to, że serwer internetowy jest używany do takich przypadków. nginx .
Schemat jest następujący:
- Apache jest przenoszony z portu 80 na inny, na przykład 8080, i jest dostępny tylko lokalnie;
- Nginx jest instalowany i uruchamiany na porcie 80, to znaczy przyjmuje teraz żądania;
- Następnie nginx jest skonfigurowany w taki sposób, że pliki php są przesyłane do Apache na jego porcie, a wszystko inne jest przetwarzane samodzielnie.
Następne będą instrukcje konfiguracji, które wybrałem na forach i blogach, uzupełnione przeze mnie. Było tak wiele zasobów, że nie pamiętam, gdzie je zabrałem. Wybaczcie mi wszystkich autorów, których nie podałem.
Więc najpierw musisz umieścić wtyczkę Permalink Fix & Disable Canonical Redirects Pack co naprawia coś tam z przekierowaniami do permalinków .
Ustawienia Apache
Pierwszy /etc/apache2/apache2.conf:
ServerRootd 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 > </ Directory> <Katalog / var / www> Opcje FollowSymLinks AllowOverride FileInfo </ Directory> <Directory / usr / share> AllowOverride Brak Wymagane wszystkie udzielone </ Directory> AccessFileName .htaccess <FilesMatch "^ Ht"> Wymagaj wszystkich odmowa </ FilesMatch> AccessFileName .htaccess <FilesMatch "^ ht"> Wymagaj odrzucenia </ 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" "połączone 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 Brak silnik php_flag wyłączony silnik php_admin_value Wyłączony </ DirectoryMatch> <DirectoryMatch ^. * / Wp-content / blogs.dir /> AllowOverride Brak silnika php_flag wyłączony silnik php_admin_value Wyłączony </ DirectoryMatch> # <DirectoryMatch ^. * / Wp-admin / > # AuthType Basic # AuthName "Restricted Area" # AuthUserFile /etc/apache2/.htpasswd # Wymagaj prawidłowego użytkownika # </ DirectoryMatch> <VirtualHost *> ServerAdmin [email protected] DocumentRoot / var / www Nazwa serwera example.com Przykład serwera ServerAlias .com www.example.com </ VirtualHost> <IfModule mpm_prefork_module> StartServers 1 MinSpareServers 1 MaxSpareServers 4 MaxClients 4 MaxRequestsPerChild 1000 </ IfModule>
Teraz /etc/apache2/ports.conf:
Listen 127.0.0.1: 8080 <IfModule ssl_module> Listen 443 </ IfModule> <IfModule mod_gnutls.c> Listen 443 </ IfModule> # vim: składnia = apache ts = 4 sw = 4 sts = 4 sr noet
Uruchom ponownie serwer:
Teraz działa na porcie 8080, a Twoja witryna stała się niedostępna z Internetu. Nawet jeśli spróbujesz go otworzyć jako przykład.com:8080.
Ustawienia Nginx
Instalacja:
Piszemy konfigurację strony - tylko plik bez rozszerzenia - / etc / nginx / sites-enabled / mysite:
serwer {posłuchaj 80; nazwa_serwera przyklad.com; root / var / www; index index.php; gzip na; gzip_disable "msie6"; gzip_types tekst / zwykły tekst / aplikacja css / aplikacja json / x javascript tekst / xml aplikacja / xml aplikacja / xml + tekst rss / aplikacja javascript / javascript; lokalizacja ~ / {zaprzecz wszystko; # ban dla ukrytych plików} location ~ * / (?: uploads | files) /.* php $ {deny all; # ban na załadowanych skryptach} lokalizacja ~ * ^. + (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; wygasa max; # static caching} 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; }}
Teraz konfiguracja całego serwera /etc/nginx/nginx.conf:
dane użytkownika www; process_processes 1; pid /run/nginx.pid; wydarzenia {powiązania z pracownikami 768; użyj epolla; # multi_accept on; } http {## # Basic Settings ## sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 5; types_hash_max_size 2048; dołącz /etc/nginx/mime.types; default_type application / octet-stream; ## # Ustawienia logowania ## access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; ## # Virtual Host Configs ## include /etc/nginx/conf.d/*.conf; włącz / etc / nginx / sites-enabled / *; }
Uruchomienie serwera i ponowne uruchomienie ustawień:
usługa nginx uruchom przeładowanie nginx -s
Wszystko, nginx działa i dystrybuuje witrynę.
Możesz sprawdzić bieżący serwer internetowy za pomocą polecenia:
curl -s -I example.com | awk '$ 1 ~ / Server: / {print $ 2}'
W rezultacie to wszystko - nie jest tak, że zauważam dramatyczny spadek zużycia pamięci RAM, ale nie jest to już spadek z powodu braku tej bazy. Zmniejszyłem kroplę z 1 GB do 512 MB - cały ogień. Oczywiście, jeśli kilkudziesięciu użytkowników łączy się w tym samym czasie, w pewnym momencie zostanie wydane 502 Bad Gateway , ale baza nie spadnie, a gdy tylko obciążenie zmniejszy się, witryna zostanie podana normalnie.
W skrócie, możemy powiedzieć, że nginx i poprawne ustawienia dla niego, Apache i MySQL, są niezbędne, aby WordPress przetrwał na 512 MB pamięci RAM. Opcjonalnie możesz również wypróbować różne okłady, takie jak plik wymiany i wtyczka WP Super Cache .
Php?