Smanjenje opterećenja poslužitelja

U ovom ćemo članku istražiti zašto dolazi do povećanog opterećenja poslužitelja i raspravljati o različitim načinima optimizacije procesa visokog opterećenja. Posebna pozornost bit će posvećena optimizaciji koda u Apache/Nginx i MySQL, govorit ćemo o cachingu kao pomoćnom alatu, a također ćemo razmotriti moguće vanjske prijetnje, poput DDOS napada, te načine za njihovo sprječavanje.

Zašto dolazi do opterećenja poslužitelja

Prije nego što pristupite optimizaciji poslužitelja, potrebno je provesti temeljitu analizu trenutnog opterećenja resursa. To uključuje mjerenje opterećenja CPU-a, upotrebe RAM-a, mrežne aktivnosti i drugih ključnih parametara. Razumijevanje dinamike i vršnih opterećenja omogućuje prepoznavanje uskih grla i optimiziranje raspodjele resursa, čime se povećava stabilnost i performanse poslužiteljske infrastrukture.

Za početno rješavanje problema velikog opterećenja poslužitelja, preporučujemo provođenje a opća dijagnostika poslužitelja. Ako to nije dovoljno, detaljnije analiza resursa je neophodno. Kao pomoćni alat, istraživanje zapisnici Linuxa server može biti od pomoći jer se tu u većini slučajeva nalazi izvor problema.

Optimiziranje Apache/Nginx poslužitelja

Povećano opterećenje poslužitelja zbog indeksiranja

Do povećanog opterećenja zbog indeksiranja na poslužitelju može doći, na primjer, kada tražilice skeniraju velik broj stranica na vašoj stranici. To može dovesti do povećane upotrebe resursa poslužitelja i, posljedično, usporiti performanse stranice. Identificiranje uzroka je relativno jednostavno; morate otvoriti datoteku koja se nalazi na:

/var/www/httpd-logs/sitename.access.log

Kada ga tražilice indeksiraju, korisnik će vidjeti unose sljedeće prirode:

11.22.33.44 - - [Date and Time] "GET /your-page-path HTTP/1.1" 200 1234 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Kao prvo rješenje za smanjenje opterećenja možete koristiti postavljanje meta oznaka "noindex" i "nofollow" na stranicama koje nije potrebno indeksirati. Drugo rješenje je .htaccess datoteku, gdje je potrebno dodati unose koji odgovaraju određenim tražilicama, na primjer, za skrivanje od Yandexa i Googlea:

SetEnvIfNoCase User-Agent "^Yandex" search_bot
SetEnvIfNoCase User-Agent "^Googlebot" search_bot
Order Allow,Deny
Allow from all
Deny from env=search_bot

Slično, potrebno je izvršiti izmjene za druge tražilice. Treba napomenuti da mogućnosti .htaccess nisu ograničene samo na blokiranje indeksiranja. Preporučujemo da se bolje upoznate s njegovim glavnim značajkama u članak.

Korištenje postavki predmemoriranja

Netočne postavke predmemoriranja na poslužitelju također mogu dovesti do velikog opterećenja. Za optimizaciju ovog parametra potrebno je napraviti odgovarajuće promjene u konfiguracijskim datotekama ili .htaccess. U slučaju Apachea, posljednja opcija je poželjnija, za Nginx - prva.

Na jednom apaš poslužitelj, trebate otvoriti .htacess datoteku i umetnite sljedeći kod:

<FilesMatch ".(flv|gif|jpg|jpeg|png|ico|swf|js|css|pdf|doc|docx)$">
Header set Cache-Control "max-age=2592000"
</FilesMatch>

Zatim omogućite Istječe modul pomoću naredbe:

sudo a2enmod expires

Nakon toga ponovno pokrenite web poslužitelj:

sudo service apache2 restart

I aktivirajte modul navođenjem:

ExpiresActive On

Na Nginx poslužitelja, dovoljno je u konfiguracijsku datoteku dodati sljedeći kod:

location ~* .(jpg|jpeg|gif|png|ico|css|swf|flv|doc|docx)$ {
root /var/www/yoursite.com;
}

I izvršite ponovno učitavanje usluge:

sudo service nginx restart

Imajte na umu da s ovim postavkama, dopustiti i odbiti direktive će se zaobići.

Korištenje kompresije podataka

Omogućivanje kompresije podataka pomoću gzip na web poslužiteljima Apache i Nginx pomaže u smanjenju količine podataka koji se prenose između poslužitelja i klijenta, što poboljšava performanse i smanjuje vrijeme učitavanja web stranica.

Kako bi se omogućilo gzip on apaš, trebate aktivirati mod_deflate modul:

sudo a2enmod deflate

Zatim ponovno pokrenite web poslužitelj:

sudo service apache2 restart

I na kraju, dodajte sljedeći blok u konfiguracijsku datoteku ili .htaccess:

<IfModule mod_deflate.c>
# Configure compression for specified file types
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript application/x-javascript application/json

# If the browser matches the specified pattern, apply compression only to text/html files
BrowserMatch ^Mozilla/4 gzip-only-text/html

# If the browser matches the specified version patterns of Mozilla 4.0.6, 4.0.7, 4.0.8, disable compression
BrowserMatch ^Mozilla/4\.0[678] no-gzip

# If the browser is MSIE (Internet Explorer), disable compression for all files except text/html
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

# If the request contains the specified pattern (extensions of image files), disable compression
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip
</IfModule>

Ova konfiguracija omogućuje kompresiju za određene vrste datoteka i onemogućuje je za slike.

U slučaju Nginx, konfiguracija se događa u http blok konfiguracijske datoteke. Potrebno je dodati sljedeći kod:

gzip on;
gzip_disable "msie6";

# Adds the Vary header, indicating that the response may change depending on the Accept-Encoding header value
gzip_vary on;

# Enables compression for any proxy servers
gzip_proxied any;

# Sets the compression level. A value of 6 provides a good balance between compression efficiency and resource use
gzip_comp_level 6;

# Sets the size of the buffer for compressed data (16 buffers of 8 kilobytes each)
gzip_buffers 16 8k;

# Specifies that data compression should be used only for HTTP version 1.1 and higher
gzip_http_version 1.1;

# Sets the file types that can be compressed
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

Slično apaš, ovdje se postavljaju parametri kompresije za određene vrste datoteka. Nakon unošenja promjena na bilo kojem od web poslužitelja potrebno je ponovno učitavanje usluge:

sudo service apache2 restart

Or

sudo service nginx restart

DDOS napad na server

Do velikog opterećenja poslužitelja može doći kao rezultat DDoS napada. Identificiranje prisutnosti DDoS napada može se izvršiti praćenjem iznenadnog porasta prometa, abnormalnih zahtjeva i pada performansi poslužitelja. Pregledavanje zapisa za ponovljene zahtjeve s jedne IP adrese ili skeniranje porta također može ukazivati ​​na mogući DDoS napad. Postoje mnoge mjere zaštite, ali mi ćemo govoriti samo o osnovama.

Korištenje CDN-a (Mreža za isporuku sadržaja). CDN može poslužiti kao posrednik između vašeg web poslužitelja i korisnika, distribuirajući promet i predmemorirajući sadržaj za ublažavanje utjecaja DDoS napada. CDN-ovi također mogu imati ugrađene DDoS mehanizme zaštite, uključujući distribuciju opterećenja i filtriranje prometa.

Konfiguriranje vatrozida i sustava za otkrivanje upada (IDS/IPS). Vatrozidi se mogu konfigurirati za filtriranje prometa na temelju različitih kriterija, kao što su IP adrese i portovi. IDS/IPS može otkriti nenormalno ponašanje prometa i blokirati sumnjive veze. Ovi alati mogu biti učinkoviti u praćenju i blokiranju potencijalno zlonamjernog prometa.

Konfiguriranje Apache i Nginx web poslužitelja za ublažavanje utjecaja DDoS napada.

Kao rješenje za Apache, omogućujemo mod_evasive modul. Da biste to učinili, uklonite komentar ili dodajte sljedeći redak u httpd.conf or apache2.conf konfiguracijska datoteka:

LoadModule evasive20_module modules/mod_evasive.so

U istoj datoteci morate dodati blok postavki:

<IfModule mod_evasive20.c>
# Hash table size for storing request information
DOSHashTableSize 3097

# Number of requests to one page before activating protection
DOSPageCount 2
DOSPageInterval 1

# Number of requests to all pages before activating protection
DOSSiteCount 50
DOSSiteInterval 1

# Blocking period in seconds for IP addresses
DOSBlockingPeriod 10
</IfModule>

Slično, aktiviramo mod_ratelimit modul:

LoadModule ratelimit_module modules/mod_ratelimit.so

I dodajte konfiguraciju:

<IfModule mod_ratelimit.c>
# Setting the output filter for rate limiting (Rate Limit)
SetOutputFilter RATE_LIMIT

# Beginning of the settings block for the location "/login"
<Location "/login">

# Setting the environment variable rate-limit with a value of 1
SetEnv rate-limit 1

# Ending of the settings block for the location "/login"
</Location>
</IfModule>

Konfiguracija za Nginx je sličan apaš. U nginx.conf konfiguracijsku datoteku, potrebno je koristiti sljedeće upute:

http {
...
# Defining a zone for connection limits
limit_conn_zone $binary_remote_addr zone=addr:10m;

# Defining a zone for request limits
limit_req_zone $binary_remote_addr zone=req_zone:10m rate=1r/s;

server {
        ...
        # Configuring connection limits
        limit_conn addr 10;

        # Configuring request limits
        limit_req zone=req_zone burst=5;

        ...
    }
}

Nakon što izvršite izmjene na svakoj od usluga, potrebno ih je ponovno učitati:

sudo systemctl restart apache2

Ili:

sudo systemctl restart nginx

Ovi primjeri daju samo osnovnu konfiguraciju, koja se može dodatno prilagoditi ovisno o specifičnim zahtjevima i prirodi napada.

Optimiziranje MySQL upita

Optimiziranje MySQL upita baze podataka na web poslužitelju može se postići na različite načine, a jedan od njih je pravilna konfiguracija konfiguracijske datoteke. Obično je ova datoteka imenovana moj.cnf or moj.ini i nalazi se u / itd / or /etc/mysql/ imenik. Morate ga otvoriti i napraviti sljedeće promjene:

[mysqld]
# Location of the file for recording slow queries. Be sure to replace it with your path
log-slow-queries = /var/log/mariadb/slow_queries.log

# Threshold time for considering slow queries (in seconds)
long_query_time = 5

# Enabling recording of queries that do not use indexes
log-queries-not-using-indexes = 1

# Disabling query caching
query_cache_size = 0
query_cache_type = 0
query_cache_limit = 1M

# Size of temporary tables
tmp_table_size = 16M
max_heap_table_size = 16M

# Size of the thread cache
thread_cache_size = 16

# Disabling name resolving
skip-name-resolve = 1

# Size of the InnoDB buffer pool. Set to 50-70% of available RAM
innodb_buffer_pool_size = 800M

# Size of the InnoDB log file
innodb_log_file_size = 200M

Razmotrimo i dodatne preporuke koje mogu olakšati interakciju s bazom podataka poslužitelja:

1. Koristite OBJASNITI naredbu prije SQL upita za analizu njegovog izvršenja. To vam omogućuje da dobijete plan izvršenja za upit i odredite koji se indeksi koriste, koje se tablice skeniraju itd.
2. Indeksi ubrzavaju pretraživanje podataka, tako da pravilno dizajnirani indeksi mogu značajno poboljšati izvedbu upita. Obratite pozornost na stupce koji se često koriste u GDJE or PRIDRUŽITE uvjeti.
3. Izbjegavajte upotrebu IZABERI *. Navedite samo one stupce koji su uistinu potrebni za vaš upit, umjesto odabira svih stupaca u tablici.
4. Izbjegavajte korištenje funkcija u GDJE uvjetima. Korištenje funkcija (kao što je NIŽI, GORNJI, LIJEVO, PRAVO) u GDJE uvjeti mogu učiniti indekse beskorisnim. Pokušajte izbjeći njihovu izravnu upotrebu u uvjetima.
5. Koristiti INNER JOIN gdje je to moguće, jer je to obično učinkovitije. Također, osigurajte da odgovarajući stupci za spajanje imaju indekse.
6. Koristiti OGRANIČAVA da ograničite broj vraćenih redaka ako trebate dobiti samo određeni broj rezultata.
7. Razmislite o predmemoriranju rezultata upita, posebno ako se rijetko mijenjaju, kako biste smanjili opterećenje poslužitelja.

Poslužitelj pošte stvara veliko opterećenje poslužitelja

U ovom ćemo odjeljku istražiti kako utvrditi da je poslužitelj e-pošte pod velikim opterećenjem i koji se koraci mogu poduzeti za optimizaciju njegovog rada, uključujući provjeru reda poruka i konfiguriranje parametara poslužitelja. Počnite s provjerom reda poruka. The mailq uslužni program može pomoći u tome, da biste ga aktivirali, unesite odgovarajuću naredbu u terminal:

mailq

Ovo će prikazati popis poruka u redu čekanja, ako ih ima. Svaka će poruka biti prikazana sa svojim jedinstvenim identifikatorom i informacijama o statusu slanja. Sličan rezultat može se dobiti pregledom zapisa klijenta pošte.

U većini slučajeva do velikog opterećenja dolazi u slučaju kompromitacije poslužitelja kada počne slati neželjenu poštu. Međutim, ako je nakon provjere administrator uvjeren da poslužitelj nije napadnut izvana i da korisnici ne zanemaruju spam, vrijeme je da prijeđete na optimizaciju poslužitelja e-pošte. Evo koraka koji će vam pomoći:

1. Provjerite jesu li DNS zapisi vaše domene ispravno konfigurirani, uključujući SPF, dkim nastavaki DMARC proširenje zapise za poboljšanje isporuke pošte i zaštitu od neželjene pošte. Ispravnu konfiguraciju parametara možete pronaći u članku o dijagnostika poslužitelja pošte.
2. Provjerite mrežne postavke, uključujući konfiguraciju vatrozida i pravila usmjeravanja, kako biste izbjegli blokade i ubrzali isporuku pošte.
3. Konfigurirajte parametre reda poruka u skladu s opterećenjem poslužitelja. To može uključivati ​​postavljanje maksimalne veličine čekanja i vremenskih ograničenja.
4. Razmotrite rješenja o kojima smo ranije govorili u ovom članku. Povremeno optimizirajte bazu podataka poslužitelja e-pošte kako biste poboljšali performanse, koristite mehanizme predmemorije za ubrzavanje pretraživanja i obrade podataka, kao što su DNS upiti.
5. Ako se poslužitelj e-pošte i dalje redovito susreće s velikim opterećenjem, razmislite o mogućnostima skaliranja, poput upotrebe klastera poslužitelja e-pošte ili rješenja u oblaku.

Zaključak

Povećano opterećenje poslužitelja izravno utječe na brzinu učitavanja web stranice, što u konačnici utječe na korisničko iskustvo i ugled u tražilicama. Stoga učinkovito upravljanje ovim opterećenjem igra ključnu ulogu u osiguravanju kontinuirane funkcionalnosti resursa i povećanju njegove dostupnosti za posjetitelje.