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 z visoko obremenitvijo strežnika priporočamo, da izvedete a splošna diagnostika strežnika. Če to ni dovolj, podrobneje analiza virov je potrebno. Kot pomožno orodje, raziskovanje dnevnike Linuxa strežnik je lahko v pomoč, saj je tam v večini primerov 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 .htaccess datoteko, kjer je treba dodati vnose, ki ustrezajo določenim iskalnikom, na primer, da se skrijejo 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 druge iskalnike. Upoštevati je treba, da zmožnosti .htaccess niso omejene samo na blokiranje indeksiranja. Priporočamo, da se podrobneje seznanite z njegovimi glavnimi značilnostmi v članek.

Uporaba nastavitev predpomnjenja

Nepravilne nastavitve predpomnjenja na strežniku lahko povzročijo tudi veliko obremenitev. Za optimizacijo tega parametra je treba narediti ustrezne spremembe v konfiguracijskih datotekah oz .htaccess. V primeru Apache je boljša druga možnost, za Nginx - prva.

Na an Apache strežnik, morate odpreti .htacess datoteko in vstavite 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 Poteče modul 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 Nginx strežniku, 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 s temi nastavitvami Dovoli in Zavrni direktive bodo zaobšle.

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 spletne strani.

Omogočiti Gzip on Apache, morate aktivirati mod_deflate modul:

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 Nginx, se konfiguracija pojavi v http blok 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 Apache, tukaj se nastavijo parametri stiskanja za določene vrste datotek. Po spremembi katerega koli spletnega strežnika je potrebno ponovno nalaganje 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 CDN (omrežje za dostavo vsebine). CDN lahko služi kot posrednik med vašim spletnim strežnikom in uporabniki, pri čemer distribuira promet in predpomni vsebino za ublažitev vpliva DDoS napada. CDN-ji imajo lahko tudi vgrajene zaščitne mehanizme DDoS, vključno s porazdelitvijo obremenitve in filtriranjem prometa.

Konfiguracija 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 nenormalno 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čamo mod_evasive modul. Če želite to narediti, odkomentirajte ali dodajte naslednjo vrstico v httpd.conf or apache2.conf konfiguracijska datoteka:

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 mod_ratelimit modul:

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 podoben Apache. v nginx.conf konfiguracijske datoteke, 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

Optimiziranje poizvedb baze podatkov MySQL na spletnem strežniku je mogoče doseči na različne načine, eden izmed njih pa je pravilna konfiguracija konfiguracijske datoteke. Običajno je ta datoteka poimenovana moj.cnf or moj.ini in se nahaja v / etc / or /etc/mysql/ imenik. Odpreti ga 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 zelo obremenjen, in katere korake je mogoče izvesti 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. The mailq pripomoček lahko pomaga pri tem, če ga želite aktivirati, v terminal vnesite 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.