Smanjenje opterećenja servera

U ovom članku ćemo proučiti zašto dolazi do povećanog opterećenja servera i razmotriti različite načine optimizacije procesa visokog opterećenja. Posebna pažnja će biti posvećena optimizaciji koda u Apache/Nginx i MySQL, govorićemo o keširanju kao pomoćnom alatu, a takođe ćemo razmotriti moguće spoljne pretnje, kao što su DDOS napadi, i načine za njihovo sprečavanje.

Zašto dolazi do opterećenja servera

Prije nego što pređete na optimizaciju servera, potrebno je izvršiti detaljnu analizu trenutnog opterećenja resursa. Ovo uključuje mjerenje opterećenja CPU-a, korištenje RAM-a, mrežne aktivnosti i druge ključne parametre. Razumijevanje dinamike i vršnog opterećenja omogućava identifikaciju uskih grla i optimizaciju alokacije resursa, čime se povećava stabilnost i performanse serverske infrastrukture.

Za početno rješavanje problema visokog opterećenja servera, preporučujemo provođenje opće dijagnostike servera . Ako to nije dovoljno, potrebna je detaljnija analiza resursa . Kao pomoćni alat, istraživanje logova Linux servera može biti korisno, jer se tu u većini slučajeva nalazi izvor problema.

Optimizacija Apache/Nginx servera

Povećano opterećenje servera zbog indeksiranja

Do povećanog opterećenja zbog indeksiranja na serveru može doći, na primjer, kada pretraživači skeniraju veliki broj stranica na vašoj web stranici. To može dovesti do povećane upotrebe serverskih resursa i, posljedično, usporiti performanse stranice. Identifikacija uzroka je relativno jednostavna; potrebno je da otvorite fajl koji se nalazi na:

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

Kada ga pretraživači 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 ne trebaju biti indeksirane. Drugo rješenje je .htaccess datoteka, gdje je potrebno dodati unose koji odgovaraju određenim pretraživačima, na primjer, da bi se sakrili 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 tome, potrebno je napraviti izmjene i za ostale pretraživače. Treba napomenuti da mogućnosti .htaccess datoteke nisu ograničene samo na blokiranje indeksiranja. Preporučujemo da se detaljnije upoznate s njenim glavnim karakteristikama u članku.

Korištenje postavki keširanja

Nepravilne postavke keširanja na serveru također mogu dovesti do velikog opterećenja. Da biste optimizirali ovaj parametar, potrebno je izvršiti odgovarajuće promjene u konfiguracijskim datotekama ili .htaccess . U slučaju Apachea, ova druga opcija je poželjnija, a za Nginx prva.

Na Apache serveru, potrebno je da otvorite .htacess datoteku i ubacite 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 modul Expires pomoću naredbe:

sudo a2enmod expires

Nakon toga ponovo pokrenite web server:

sudo service apache2 restart

I aktivirajte modul navodeći:

ExpiresActive On

Na Nginx serveru, dovoljno je dodati sljedeći kod u konfiguracijsku datoteku:

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 će se s ovim postavkama zaobilaziti direktive Allow i Deny .

Korištenje kompresije podataka

Omogućavanje kompresije podataka pomoću Gzipa na Apache i Nginx web serverima pomaže u smanjenju količine podataka koji se prenose između servera i klijenta, što poboljšava performanse i smanjuje vrijeme učitavanja web stranice.

Da biste omogućili Gzip na Apacheu , potrebno je da aktivirate modul mod_deflate :

sudo a2enmod deflate

Zatim ponovo pokrenite web server:

sudo service apache2 restart

I na kraju, dodajte sljedeći blok u konfiguracijski fajl 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ćava kompresiju za određene tipove datoteka i onemogućuje je za slike.

U slučaju Nginx-a , konfiguracija se odvija u http bloku 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 kao kod Apachea , ovdje se postavljaju parametri kompresije za određene tipove datoteka. Nakon što se izvrše promjene na bilo kojem od web servera, potrebno je ponovno pokretanje servisa:

sudo service apache2 restart

Or

sudo service nginx restart

DDOS napad na server

Visoko opterećenje servera može nastati kao rezultat DDoS napada. Identifikacija prisustva DDoS napada može se obaviti praćenjem naglog povećanja prometa, abnormalnih zahtjeva i pada performansi servera. Pregledavanje dnevnika za ponovljene zahtjeve s jedne IP adrese ili skeniranje portova također može ukazivati ​​na mogući DDoS napad. Postoje mnoge mjere zaštite, ali ćemo razgovarati samo o osnovnim.

Korištenje CDN-a (mreže za isporuku sadržaja) . CDN može poslužiti kao posrednik između vašeg web servera i korisnika, distribuirajući promet i keširajući sadržaj kako bi ublažio utjecaj DDoS napada. CDN-ovi također mogu imati ugrađene mehanizme zaštite od DDoS napada, uključujući raspodjelu opterećenja i filtriranje prometa.

Konfigurisanje zaštitnih zidova (firewall) i sistema za detekciju upada (IDS/IPS) . Zaštitni zidovi (firewall) mogu se konfigurisati za filtriranje saobraćaja na osnovu različitih kriterijuma, kao što su IP adrese i portovi. IDS/IPS mogu detektovati abnormalno ponašanje saobraćaja i blokirati sumnjive veze. Ovi alati mogu biti efikasni u praćenju i blokiranju potencijalno zlonamernog saobraćaja.

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

Kao rješenje za Apache, omogućavamo modul mod_evasive . Da biste to učinili, uklonite komentare ili dodajte sljedeći red u konfiguracijsku datoteku httpd.conf ili apache2.conf :

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 tome, aktiviramo modul mod_ratelimit :

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čna onoj za Apache . U konfiguracijskoj datoteci nginx.conf potrebno je koristiti sljedeće 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;

        ...
    }
}

Nakon izmjena svake od usluga, potrebno ih je ponovo učitati:

sudo systemctl restart apache2

Ili:

sudo systemctl restart nginx

Ovi primjeri pružaju samo osnovnu konfiguraciju, koja se može dalje prilagođavati ovisno o specifičnim zahtjevima i prirodi napada.

Optimizacija MySQL upita

Optimizacija upita MySQL baze podataka na web serveru može se postići na različite načine, a jedan od njih je pravilna konfiguracija konfiguracijske datoteke. Obično se ova datoteka zove my.cnf ili my.ini i nalazi se u direktoriju /etc/ ili /etc/mysql/ . Potrebno je da je otvorite i napravite 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 sa serverskom bazom podataka:

1. Koristiti OBRAZLOŽITE naredba prije SQL upita za analizu njegovog izvršenja. Ovo vam omogućava da dobijete plan izvršenja za upit i odredite koji se indeksi koriste, koje tabele se skeniraju itd.
2. Indeksi ubrzavaju pretragu podataka, tako da pravilno dizajnirani indeksi mogu značajno poboljšati performanse upita. Obratite pažnju na kolone koje se često koriste u GDJE or JOIN uvjetima.
3. Izbjegavajte upotrebu ODABIR *. Navedite samo one kolone koje su zaista neophodne za vaš upit, umjesto da odaberete sve kolone u tabeli.
4. Izbjegavajte korištenje funkcija u GDJE uslovima. Korištenje funkcija (npr NIŽE, GORNJI, LEVO, PRAVO) in GDJE uslovi mogu učiniti indekse beskorisnim. Pokušajte izbjeći njihovu direktnu upotrebu u uslovima.
5. upotreba UNUTAR PRIDRUŽITE SE gdje je to moguće, jer je obično efikasnije. Također, osigurajte da odgovarajuće kolone za spajanje imaju indekse.
6. upotreba LIMIT da ograničite broj vraćenih redova ako trebate dobiti samo određeni broj rezultata.
7. Razmislite o keširanju rezultata upita, posebno ako se rijetko mijenjaju, kako biste smanjili opterećenje servera.

Mail Server stvara veliko opterećenje na serveru

U ovom odjeljku ćemo istražiti kako utvrditi da li je mail server pod velikim opterećenjem i koje korake možemo poduzeti za optimizaciju njegovog rada, uključujući provjeru reda čekanja poruka i konfiguriranje parametara servera. Počnite s provjerom reda čekanja poruka. Uslužni program mailq može vam pomoći u tome, da biste ga aktivirali, unesite odgovarajuću naredbu u terminal:

mailq

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

U većini slučajeva, veliko opterećenje se javlja u slučaju kompromitacije servera kada počne da šalje neželjenu poštu. Međutim, ako je nakon provjere administrator siguran da server nije napadnut izvana i da korisnici ne zanemaruju neželjenu poštu, vrijeme je da se pređe na optimizaciju mail servera. Evo koraka koji će vam pomoći:

1. Uvjerite se da su DNS zapisi vaše domene ispravno konfigurirani, uključujući zaštitni faktor, dkim ekstenzija, I DMARC ekstenzija evidencije 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 mail servera.
2. Provjerite mrežne postavke, uključujući konfiguraciju zaštitnog zida i pravila rutiranja, kako biste izbjegli blokade i ubrzali isporuku pošte.
3. Konfigurirajte parametre reda poruka prema opterećenju servera. Ovo može uključivati ​​postavljanje maksimalne veličine reda čekanja i vremenskih ograničenja.
4. Razmotrite rješenja o kojima smo ranije govorili u ovom članku. Periodično optimizujte bazu podataka servera pošte da biste poboljšali performanse, koristite mehanizme keširanja da biste ubrzali pretragu i obradu podataka, kao što su DNS upiti.
5. Ako se server e-pošte i dalje redovno susreće sa velikim opterećenjem, razmislite o opcijama skaliranja, kao što je korištenje klastera mail servera ili rješenja u oblaku.

zaključak

Povećano opterećenje servera direktno utječe na brzinu učitavanja web stranice, što u konačnici utiče na korisničko iskustvo i reputaciju u pretraživačima. Stoga, efikasno upravljanje ovim opterećenjem igra ključnu ulogu u osiguravanju kontinuirane funkcionalnosti resursa i povećanju njegove dostupnosti posjetiteljima.