Zníženie zaťaženia servera

V tomto článku sa ponoríme do toho, prečo dochádza k zvýšenému zaťaženiu servera, a rozoberieme rôzne spôsoby optimalizácie procesov s vysokým zaťažením. Osobitná pozornosť bude venovaná optimalizácii kódu v Apache/Nginx a MySQL, budeme hovoriť o cachovaní ako pomocnom nástroji a tiež zvážime možné externé hrozby, ako sú DDOS útoky, a spôsoby, ako im predchádzať.

Prečo dochádza k zaťaženiu servera

Pred pristúpením k optimalizácii servera je potrebné vykonať dôkladnú analýzu aktuálneho zaťaženia zdrojov. To zahŕňa meranie zaťaženia procesora, využitia RAM, aktivity siete a ďalších kľúčových parametrov. Pochopenie dynamiky a špičkového zaťaženia umožňuje identifikovať úzke miesta a optimalizovať alokáciu zdrojov, čím sa zvyšuje stabilita a výkon serverovej infraštruktúry.

Pre počiatočné riešenie problémov s vysokým zaťažením servera odporúčame vykonať všeobecnú diagnostiku servera . Ak to nestačí, je potrebná podrobnejšia analýza zdrojov . Ako pomocný nástroj môže byť užitočné preskúmanie protokolov Linuxového servera, pretože práve tam sa vo väčšine prípadov nachádza zdroj problému.

Optimalizácia servera Apache/Nginx

Zvýšené zaťaženie servera v dôsledku indexovania

K zvýšenému zaťaženiu v dôsledku indexovania na serveri môže dôjsť napríklad vtedy, keď vyhľadávače skenujú veľké množstvo stránok na vašom webe. To môže viesť k zvýšenému využívaniu zdrojov servera a následne k spomaleniu výkonu stránky. Identifikácia príčiny je pomerne jednoduchá; musíte otvoriť súbor umiestnený na adrese:

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

Pri indexovaní vyhľadávacími nástrojmi sa používateľovi zobrazia položky nasledujúceho charakteru:

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

Ako prvé riešenie na zníženie zaťaženia môžete použiť nastavenie metaznačiek „noindex“ a „nofollow“ na stránkach, ktoré nie je potrebné indexovať. Druhým riešením je súbor .htaccess , kde je potrebné pridať položky zodpovedajúce konkrétnym vyhľadávačom, napríklad na skrytie pred Yandexom a Googlom:

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

Podobne je potrebné vykonať úpravy aj pre ostatné vyhľadávače. Treba poznamenať, že možnosti súboru .htaccess sa neobmedzujú len na blokovanie indexovania. Odporúčame vám bližšie sa oboznámiť s jeho hlavnými funkciami v článku.

Používanie nastavení ukladania do vyrovnávacej pamäte

Nesprávne nastavenia vyrovnávacej pamäte na serveri môžu tiež viesť k vysokému zaťaženiu. Na optimalizáciu tohto parametra je potrebné vykonať zodpovedajúce zmeny v konfiguračných súboroch alebo súbore .htaccess . V prípade Apache je vhodnejšia druhá možnosť, pre Nginx prvá.

Na serveri Apache musíte otvoriť súbor .htacess a vložiť doň nasledujúci kód:

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

Potom povoľte modul Expires pomocou príkazu:

sudo a2enmod expires

Potom reštartujte webový server:

sudo service apache2 restart

A aktivujte modul zadaním:

ExpiresActive On

Na serveri Nginx stačí do konfiguračného súboru pridať nasledujúci kód:

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

A vykonajte opätovné načítanie služby:

sudo service nginx restart

Upozorňujeme, že s týmito nastaveniami sa direktívy Allow a Deny obídu.

Použitie kompresie údajov

Povolenie kompresie dát pomocou Gzip na webových serveroch Apache a Nginx pomáha znížiť množstvo dát prenášaných medzi serverom a klientom, čo zlepšuje výkon a skracuje čas načítania webovej stránky.

Ak chcete povoliť Gzip na Apache , musíte aktivovať modul mod_deflate :

sudo a2enmod deflate

Potom reštartujte webový server:

sudo service apache2 restart

Nakoniec pridajte nasledujúci blok do konfiguračného súboru alebo .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>

Táto konfigurácia umožňuje kompresiu pre určité typy súborov a zakazuje ju pre obrázky.

V prípade Nginx sa konfigurácia vykonáva v bloku http konfiguračného súboru. Je potrebné pridať nasledujúci kód:

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;

Podobne ako v Apache , aj tu sa nastavujú parametre kompresie pre určité typy súborov. Po vykonaní zmien na ktoromkoľvek z webových serverov je potrebné opätovné načítanie služby:

sudo service apache2 restart

Or

sudo service nginx restart

DDOS útok na server

Vysoké zaťaženie servera môže nastať v dôsledku DDoS útoku. Prítomnosť DDoS útoku je možné identifikovať monitorovaním náhleho nárastu návštevnosti, abnormálnych požiadaviek a poklesu výkonu servera. Kontrola protokolov pre opakované požiadavky z jednej IP adresy alebo skenovanie portov môže tiež naznačovať možný DDoS útok. Existuje veľa ochranných opatrení, ale budeme diskutovať len o základoch.

Používanie siete CDN (Content Delivery Network) . CDN môže slúžiť ako sprostredkovateľ medzi vaším webovým serverom a používateľmi, distribuovať prevádzku a ukladať obsah do vyrovnávacej pamäte, aby sa zmiernil dopad útoku DDoS. CDN môžu mať tiež vstavané mechanizmy ochrany pred DDoS, vrátane distribúcie záťaže a filtrovania prevádzky.

Konfigurácia firewallov a systémov detekcie narušenia (IDS/IPS) . Firewally je možné nakonfigurovať tak, aby filtrovali prevádzku na základe rôznych kritérií, ako sú IP adresy a porty. IDS/IPS dokážu detekovať abnormálne správanie prevádzky a blokovať podozrivé pripojenia. Tieto nástroje môžu byť účinné pri sledovaní a blokovaní potenciálne škodlivej prevádzky.

Konfigurácia webových serverov Apache a Nginx na zmiernenie vplyvu útokov DDoS.

Ako riešenie pre Apache povolíme modul mod_evasive . Ak to chcete urobiť, odkomentujte alebo pridajte nasledujúci riadok do konfiguračného súboru httpd.conf alebo apache2.conf :

LoadModule evasive20_module modules/mod_evasive.so

V tom istom súbore musíte pridať blok nastavení:

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

Podobne aktivujeme modul mod_ratelimit :

LoadModule ratelimit_module modules/mod_ratelimit.so

A pridajte konfiguráciu:

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

Konfigurácia pre Nginx je podobná ako pre Apache . V konfiguračnom súbore nginx.conf je potrebné použiť nasledujúce direktívy:

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;

        ...
    }
}

Po vykonaní zmien v každej zo služieb je potrebné ich znova načítať:

sudo systemctl restart apache2

Alebo:

sudo systemctl restart nginx

Tieto príklady poskytujú iba základnú konfiguráciu, ktorú je možné ďalej upravovať v závislosti od konkrétnych požiadaviek a charakteru útokov.

Optimalizácia dopytov MySQL

Optimalizácia dotazov databázy MySQL na webovom serveri sa dá dosiahnuť rôznymi spôsobmi a jedným z nich je správna konfigurácia konfiguračného súboru. Tento súbor sa zvyčajne nazýva my.cnf alebo my.ini a nachádza sa v adresári /etc/ alebo /etc/mysql/ . Musíte ho otvoriť a vykonať nasledujúce zmeny:

[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

Zvážme aj ďalšie odporúčania, ktoré môžu uľahčiť interakciu s databázou servera:

1. Použi vysvetlí príkaz pred dotazom SQL na analýzu jeho vykonania. To vám umožní získať plán vykonávania pre dotaz a určiť, ktoré indexy sa používajú, ktoré tabuľky sa skenujú atď.
2. Indexy zrýchľujú vyhľadávanie údajov, takže správne navrhnuté indexy môžu výrazne zlepšiť výkon dotazov. Venujte pozornosť stĺpcom, ktoré sa často používajú KDE or REGISTRÁCIA podmienok.
3. Nepoužívajte SELECT *. Zadajte iba tie stĺpce, ktoré sú skutočne potrebné pre váš dotaz, namiesto výberu všetkých stĺpcov v tabuľke.
4. Vyhnite sa používaniu funkcií v KDE podmienky. Používanie funkcií (napr DOLNÝ, HORNÁ, LEFT, PRÁVO) v KDE podmienky môžu spôsobiť, že indexy budú zbytočné. Snažte sa vyhnúť ich priamemu použitiu v podmienkach.
5. Použitie INNER JOIN kde je to možné, pretože je to zvyčajne efektívnejšie. Tiež sa uistite, že zodpovedajúce stĺpce na spájanie majú indexy.
6. Použitie LIMIT obmedziť počet vrátených riadkov, ak potrebujete získať len určitý počet výsledkov.
7. Zvážte ukladanie výsledkov dotazov do vyrovnávacej pamäte, najmä ak sa menia len zriedka, aby ste znížili zaťaženie servera.

Poštový server vytvára vysoké zaťaženie servera

V tejto časti preskúmame, ako zistiť, či je poštový server vysoko zaťažený a aké kroky možno podniknúť na optimalizáciu jeho prevádzky vrátane kontroly frontu správ a konfigurácie parametrov servera. Začnite kontrolou frontu správ. S tým vám môže pomôcť utilita mailq , na jej aktiváciu zadajte príslušný príkaz do terminálu:

mailq

Zobrazí sa zoznam správ vo fronte, ak nejaké existujú. Každá správa bude zobrazená s jej jedinečným identifikátorom a informáciou o stave odoslania. Podobný výsledok je možné získať kontrolou protokolov poštového klienta.

Vo väčšine prípadov dochádza k vysokej záťaži v prípade narušenia servera, keď začne odosielať spam. Ak je však správca po kontrole presvedčený, že server nebol napadnutý zvonku a používatelia nezanedbávajú spam, je čas prejsť na optimalizáciu poštového servera. Tu sú kroky, ktoré vám pomôžu:

1. Uistite sa, že záznamy DNS vašej domény sú správne nakonfigurované, vrátane SPF, DKIMa dMarc záznamy na zlepšenie doručovania pošty a ochranu pred spamom. Správnu konfiguráciu parametrov nájdete v článku o diagnostika poštového servera.
2. Skontrolujte nastavenia siete vrátane konfigurácie brány firewall a pravidiel smerovania, aby ste sa vyhli blokovaniu a urýchlili doručovanie pošty.
3. Nakonfigurujte parametre frontu správ podľa zaťaženia servera. To môže zahŕňať nastavenie maximálnej veľkosti frontu a časových limitov.
4. Zvážte riešenia, o ktorých sme hovorili v tomto článku vyššie. Pravidelne optimalizujte databázu poštového servera, aby ste zlepšili výkon, používajte mechanizmy ukladania do vyrovnávacej pamäte na zrýchlenie vyhľadávania a spracovania údajov, ako sú napríklad dotazy DNS.
5. Ak poštový server stále pravidelne naráža na vysoké zaťaženie, zvážte možnosti škálovania, ako je použitie klastra poštových serverov alebo cloudových riešení.

Záver

Zvýšené zaťaženie servera priamo ovplyvňuje rýchlosť načítania webových stránok, čo v konečnom dôsledku ovplyvňuje používateľskú skúsenosť a reputáciu vo vyhľadávačoch. Efektívne riadenie tejto záťaže teda zohráva kľúčovú úlohu pri zabezpečovaní nepretržitej funkčnosti zdroja a zvyšovaní jeho dostupnosti pre návštevníkov.