Zmanjšanje obremenitve strežnika

V tem članku se bomo poglobili v razloge, zakaj pride do povečane obremenitve strežnika, in razpravljali o različnih načinih optimizacije visoko obremenjenih procesov. Posebna pozornost bo namenjena optimizaciji kode v Apache/Nginx in MySQL, govorili bomo o predpomnjenju kot pomožnem orodju, razmislili pa bomo tudi o morebitnih zunanjih grožnjah, kot so DDOS napadi, in načinih, kako jih preprečiti.

Zakaj pride do obremenitve strežnika

Preden nadaljujete z optimizacijo strežnika, je potrebno opraviti temeljito analizo trenutne obremenitve virov. To vključuje merjenje obremenitve procesorja, uporabe RAM-a, omrežne aktivnosti in drugih ključnih parametrov. Razumevanje dinamike in koničnih obremenitev omogoča prepoznavanje ozkih grl in optimizacijo dodeljevanja virov ter tako poveča stabilnost in zmogljivost strežniške infrastrukture.

Za začetno odpravljanje težav pri visoki obremenitvi strežnika priporočamo izvedbo splošne diagnostike strežnika . Če to ni zadostno, je potrebna podrobnejša analiza virov . Kot pomožno orodje je lahko koristno raziskovanje dnevnikov strežnika Linux , saj se tam v večini primerov nahaja vir težave.

Optimizacija strežnika Apache/Nginx

Povečana obremenitev strežnika zaradi indeksiranja

Do povečane obremenitve zaradi indeksiranja na strežniku lahko pride na primer, ko iskalniki pregledajo veliko število strani na vašem spletnem mestu. To lahko povzroči povečano uporabo strežniških virov in posledično upočasni delovanje spletnega mesta. Prepoznavanje vzroka je razmeroma preprosto; odpreti morate datoteko, ki se nahaja na:

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

Ko ga iskalniki indeksirajo, bo uporabnik videl vnose naslednje narave:

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)"

Kot prvo rešitev za zmanjšanje obremenitve lahko uporabite nastavitev meta oznak »noindex« in »nofollow« na straneh, ki jih ni treba indeksirati. Druga rešitev je datoteka .htaccess , kamor je treba dodati vnose, ki ustrezajo določenim iskalnikom, na primer za skrivanje pred Yandexom in Googlom:

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

Podobno je treba urediti tudi za druge iskalnike. Treba je opozoriti, da zmogljivosti datoteke .htaccess niso omejene le na blokiranje indeksiranja. Priporočamo, da se z njenimi glavnimi funkcijami podrobneje seznanite v članku.

Uporaba nastavitev predpomnjenja

Nepravilne nastavitve predpomnjenja na strežniku lahko povzročijo tudi veliko obremenitev. Za optimizacijo tega parametra je treba ustrezno spremeniti konfiguracijske datoteke ali datoteko .htaccess . V primeru Apacheja je slednja možnost boljša, za Nginx pa prva.

Na strežniku Apache morate odpreti datoteko .htacess in vanjo vstaviti naslednjo kodo:

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

Nato omogočite modul Expires z ukazom:

sudo a2enmod expires

Po tem znova zaženite spletni strežnik:

sudo service apache2 restart

In aktivirajte modul tako, da navedete:

ExpiresActive On

Na strežniku Nginx zadostuje, da v konfiguracijsko datoteko dodate naslednjo kodo:

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

In izvedite ponovno nalaganje storitve:

sudo service nginx restart

Upoštevajte, da se s temi nastavitvami direktivi Allow in Deny zaobideta.

Uporaba stiskanja podatkov

Omogočanje stiskanja podatkov z uporabo Gzip na spletnih strežnikih Apache in Nginx pomaga zmanjšati količino podatkov, ki se prenašajo med strežnikom in odjemalcem, kar izboljša zmogljivost in skrajša čas nalaganja spletnih strani.

Če želite omogočiti Gzip na Apacheju , morate aktivirati modul mod_deflate :

sudo a2enmod deflate

Nato znova zaženite spletni strežnik:

sudo service apache2 restart

In končno, dodajte naslednji blok v konfiguracijsko datoteko ali .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>

Ta konfiguracija omogoča stiskanje za nekatere vrste datotek in ga onemogoča za slike.

V primeru Nginxa se konfiguracija izvede v bloku http konfiguracijske datoteke. Dodati je treba naslednjo kodo:

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;

Podobno kot pri Apacheju so tudi tukaj nastavljeni parametri stiskanja za določene vrste datotek. Po spremembah na katerem koli spletnem strežniku je potreben ponovni zagon storitve:

sudo service apache2 restart

Or

sudo service nginx restart

DDOS napad na strežnik

Do visoke obremenitve strežnika lahko pride kot posledica DDoS napada. Prisotnost napada DDoS je mogoče ugotoviti s spremljanjem nenadnega povečanja prometa, neobičajnih zahtev in padcev zmogljivosti strežnika. Pregledovanje dnevnikov za ponavljajoče se zahteve z enega naslova IP ali skeniranje vrat lahko nakazujeta tudi možen napad DDoS. Zaščitnih ukrepov je veliko, vendar bomo govorili le o osnovah.

Uporaba omrežja za dostavo vsebin (CDN) . CDN lahko služi kot posrednik med vašim spletnim strežnikom in uporabniki, saj distribuira promet in shranjuje vsebino v predpomnilnik, da ublaži vpliv napada DDoS. CDN-ji imajo lahko tudi vgrajene mehanizme zaščite pred DDoS, vključno s porazdelitvijo obremenitve in filtriranjem prometa.

Konfiguriranje požarnih zidov in sistemov za zaznavanje vdorov (IDS/IPS) . Požarne zidove je mogoče konfigurirati za filtriranje prometa na podlagi različnih meril, kot so naslovi IP in vrata. IDS/IPS lahko zazna nenavadno vedenje prometa in blokira sumljive povezave. Ta orodja so lahko učinkovita pri sledenju in blokiranju potencialno zlonamernega prometa.

Konfiguriranje spletnih strežnikov Apache in Nginx za ublažitev vpliva napadov DDoS.

Kot rešitev za Apache omogočimo modul mod_evasive . To storite tako, da v konfiguracijsko datoteko httpd.conf ali apache2.conf dodate naslednjo vrstico ali jo odkomentirate :

LoadModule evasive20_module modules/mod_evasive.so

V isto datoteko morate dodati blok nastavitev:

<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>

Podobno aktiviramo modul mod_ratelimit :

LoadModule ratelimit_module modules/mod_ratelimit.so

In dodajte konfiguracijo:

<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 podobna kot za Apache . V konfiguracijski datoteki nginx.conf je treba uporabiti naslednje direktive:

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;

        ...
    }
}

Ko spremenite vsako storitev, jo je treba znova naložiti:

sudo systemctl restart apache2

ali pa:

sudo systemctl restart nginx

Ti primeri zagotavljajo le osnovno konfiguracijo, ki jo je mogoče dodatno prilagoditi glede na specifične zahteve in naravo napadov.

Optimizacija poizvedb MySQL

Optimizacijo poizvedb v podatkovni bazi MySQL na spletnem strežniku je mogoče doseči na različne načine, eden od njih pa je ustrezna konfiguracija konfiguracijske datoteke. Običajno se ta datoteka imenuje my.cnf ali my.ini in se nahaja v imeniku /etc/ ali /etc/mysql/ . Odpreti jo morate in narediti naslednje spremembe:

[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

Razmislimo tudi o dodatnih priporočilih, ki lahko olajšajo interakcijo s strežniško bazo podatkov:

1. Uporaba OBRAZLOŽITE ukaz pred poizvedbo SQL za analizo njene izvedbe. To vam omogoča, da dobite izvedbeni načrt za poizvedbo in določite, kateri indeksi se uporabljajo, katere tabele se skenirajo itd.
2. Indeksi pospešijo iskanje podatkov, zato lahko pravilno oblikovani indeksi bistveno izboljšajo zmogljivost poizvedb. Bodite pozorni na stolpce, ki se pogosto uporabljajo v KJE or PRIDRUŽITE pogoji.
3. Izogibajte se uporabi IZBERI *. Podajte samo tiste stolpce, ki so resnično potrebni za vašo poizvedbo, namesto da izberete vse stolpce v tabeli.
4. Izogibajte se uporabi funkcij v KJE pogojev. Uporaba funkcij (kot je npr SPODNJI, UPPER, LEVO, PRAVICA) v KJE pogoji lahko naredijo indekse neuporabne. Poskusite se izogniti njihovi neposredni uporabi v pogojih.
5. Uporaba INNER JOIN kjer je to mogoče, saj je običajno bolj učinkovito. Zagotovite tudi, da imajo ustrezni stolpci za združevanje indekse.
6. Uporaba LIMIT da omejite število vrnjenih vrstic, če želite dobiti le določeno število rezultatov.
7. Razmislite o predpomnjenju rezultatov poizvedbe, še posebej, če se redko spreminjajo, da zmanjšate obremenitev strežnika.

Poštni strežnik ustvari visoko obremenitev strežnika

V tem razdelku bomo raziskali, kako ugotoviti, ali je poštni strežnik preobremenjen in katere korake je mogoče sprejeti za optimizacijo njegovega delovanja, vključno s preverjanjem čakalne vrste sporočil in konfiguracijo parametrov strežnika. Začnite s preverjanjem čakalne vrste sporočil. Pri tem vam lahko pomaga pripomoček mailq , ki ga za aktivacijo vnesete v terminal ustrezen ukaz:

mailq

To bo prikazalo seznam sporočil v čakalni vrsti, če obstajajo. Vsako sporočilo bo prikazano s svojim edinstvenim identifikatorjem in informacijami o statusu pošiljanja. Podoben rezultat lahko dobite s pregledom dnevnikov poštnega odjemalca.

V večini primerov se visoka obremenitev pojavi v primeru ogroženosti strežnika, ko ta začne pošiljati neželeno pošto. Če pa je skrbnik po preverjanju prepričan, da strežnik ni bil napaden od zunaj in uporabniki ne zanemarjajo vsiljene pošte, je čas, da nadaljujete z optimizacijo poštnega strežnika. Tukaj so koraki, ki vam bodo pomagali:

1. Zagotovite, da so zapisi DNS vaše domene pravilno konfigurirani, vključno z SPF, razširitev dkimin DMARC zapise za izboljšanje dostave pošte in zaščito pred vsiljeno pošto. Pravilno konfiguracijo parametrov najdete v članku o diagnostika poštnega strežnika.
2. Preverite omrežne nastavitve, vključno s konfiguracijo požarnega zidu in pravili usmerjanja, da se izognete blokadam in pospešite dostavo pošte.
3. Konfigurirajte parametre čakalne vrste sporočil glede na obremenitev strežnika. To lahko vključuje nastavitev največje velikosti čakalne vrste in časovnih omejitev.
4. Razmislite o rešitvah, o katerih smo prej govorili v tem članku. Občasno optimizirajte bazo podatkov poštnega strežnika, da izboljšate zmogljivost, uporabite mehanizme predpomnjenja, da pospešite iskanje in obdelavo podatkov, kot so poizvedbe DNS.
5. Če je poštni strežnik še vedno redno obremenjen, razmislite o možnostih skaliranja, kot je uporaba gruče poštnih strežnikov ali rešitev v oblaku.

zaključek

Povečana obremenitev strežnika neposredno vpliva na hitrost nalaganja spletne strani, kar na koncu vpliva na uporabniško izkušnjo in ugled v iskalnikih. Tako ima učinkovito obvladovanje te obremenitve ključno vlogo pri zagotavljanju stalne funkcionalnosti vira in povečanju njegove dostopnosti za obiskovalce.