Snížení zátěže serveru

V tomto článku se ponoříme do toho, proč dochází ke zvýšené zátěži serveru, a probereme různé způsoby optimalizace procesů s vysokou zátěží. Zvláštní pozornost bude věnována optimalizaci kódu v Apache/Nginx a MySQL, budeme hovořit o cachování jako pomocném nástroji a také zvážíme možné externí hrozby, jako jsou DDOS útoky, a způsoby, jak jim předcházet.

Proč dochází k zatížení serveru

Než přistoupíte k optimalizaci serveru, je nutné provést důkladnou analýzu aktuálního zatížení zdrojů. To zahrnuje měření zátěže CPU, využití RAM, síťové aktivity a dalších klíčových parametrů. Pochopení dynamiky a špičkového zatížení umožňuje identifikovat úzká místa a optimalizovat alokaci zdrojů, čímž se zvyšuje stabilita a výkon serverové infrastruktury.

Pro počáteční řešení problémů s vysokou zátěží serveru doporučujeme provést a obecná diagnostika serveru. Pokud to nestačí, podrobněji analýza zdrojů je nutné. Jako pomocný nástroj pro zkoumání logy Linuxu server může být užitečný, protože zde se ve většině případů nachází zdroj problému.

Optimalizace serveru Apache/Nginx

Zvýšené zatížení serveru kvůli indexování

Ke zvýšené zátěži v důsledku indexování na serveru může dojít například tehdy, když vyhledávače skenují velké množství stránek na vašem webu. To může vést ke zvýšenému využití zdrojů serveru a následně ke zpomalení výkonu webu. Identifikace příčiny je poměrně jednoduchá; musíte otevřít soubor umístěný na adrese:

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

Při indexování vyhledávači uvidí uživatel položky následující povahy:

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

Jako první řešení pro snížení zátěže můžete použít nastavení meta tagů "noindex" si "nofollow" na stránkách, které není třeba indexovat. Druhým řešením je . Htaccess soubor, kam je třeba přidat položky odpovídající konkrétním vyhledávačům, například pro skrytí před Yandexem a Googlem:

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

Podobně je třeba provést úpravy pro další vyhledávače. Je třeba poznamenat, že možnosti .htaccess se neomezují pouze na blokování indexování. Doporučujeme se blíže seznámit s jeho hlavními funkcemi v článek.

Použití nastavení mezipaměti

Nesprávné nastavení ukládání do mezipaměti na serveru může také vést k vysoké zátěži. Pro optimalizaci tohoto parametru je potřeba provést odpovídající změny v konfiguračních souborech resp . Htaccess. V případě Apache je výhodnější druhá možnost, pro Nginx - první.

Na Apache serveru, musíte otevřít .htacess soubor a vložte následující kód:

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

Poté povolte Vyprší modul pomocí příkazu:

sudo a2enmod expires

Poté restartujte webový server:

sudo service apache2 restart

A aktivujte modul zadáním:

ExpiresActive On

Na Nginx serveru, stačí do konfiguračního souboru přidat následující kód:

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

A proveďte opětovné načtení služby:

sudo service nginx restart

Všimněte si, že s těmito nastaveními, povolit si Popřít direktivy budou vynechány.

Použití komprese dat

Povolení komprese dat pomocí Gzip na webových serverech Apache a Nginx pomáhá snížit množství dat přenášených mezi serverem a klientem, což zlepšuje výkon a zkracuje dobu načítání webových stránek.

Umožnit Gzip on Apache, musíte aktivovat mod_deflate modul:

sudo a2enmod deflate

Poté restartujte webový server:

sudo service apache2 restart

A nakonec přidejte do konfiguračního souboru nebo .htaccess následující blok:

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

Tato konfigurace povoluje kompresi pro určité typy souborů a zakazuje ji pro obrázky.

V případě Nginx, konfigurace se vyskytuje v http blok konfiguračního souboru. Je třeba přidat následující 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;

Podobně jako u Apache, zde se nastavují parametry komprese pro určité typy souborů. Po provedení změn na kterémkoli z webových serverů je vyžadováno opětovné načtení služby:

sudo service apache2 restart

Or

sudo service nginx restart

DDOS útok na server

Vysoké zatížení serveru může nastat v důsledku DDoS útoku. Identifikaci přítomnosti DDoS útoku lze provést monitorováním náhlého nárůstu provozu, abnormálních požadavků a poklesu výkonu serveru. Kontrola protokolů pro opakované požadavky z jedné IP adresy nebo skenování portů může také naznačovat možný DDoS útok. Ochranných opatření je mnoho, ale probereme jen základní.

Použití sítě CDN (Content Delivery Network). CDN může sloužit jako prostředník mezi vaším webovým serverem a uživateli, distribuovat provoz a ukládat obsah do mezipaměti, aby zmírnil dopad DDoS útoku. CDN mohou mít také vestavěné mechanismy ochrany DDoS, včetně rozložení zátěže a filtrování provozu.

Konfigurace firewallů a systémů detekce narušení (IDS/IPS). Firewally lze nakonfigurovat tak, aby filtrovaly provoz na základě různých kritérií, jako jsou adresy IP a porty. IDS/IPS dokáže detekovat abnormální chování provozu a blokovat podezřelá připojení. Tyto nástroje mohou být účinné při sledování a blokování potenciálně škodlivého provozu.

Konfigurace webových serverů Apache a Nginx pro zmírnění dopadu DDoS útoků.

Jako řešení pro Apache povolujeme mod_evasive modul. Chcete-li to provést, odkomentujte nebo přidejte následující řádek httpd.conf or apache2.conf konfigurační soubor:

LoadModule evasive20_module modules/mod_evasive.so

Ve stejném souboru musíte přidat 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>

Podobně aktivujeme mod_ratelimit modul:

LoadModule ratelimit_module modules/mod_ratelimit.so

A přidejte konfiguraci:

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

Konfigurace pro Nginx je podobný Apache. V nginx.conf konfiguračního souboru, je třeba použít následující direktivy:

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 provedení změn v každé ze služeb je třeba je znovu načíst:

sudo systemctl restart apache2

nebo:

sudo systemctl restart nginx

Tyto příklady poskytují pouze základní konfiguraci, kterou lze dále upravovat v závislosti na konkrétních požadavcích a povaze útoků.

Optimalizace MySQL dotazů

Optimalizace databázových dotazů MySQL na webovém serveru lze dosáhnout různými způsoby a jedním z nich je správná konfigurace konfiguračního souboru. Obvykle je tento soubor pojmenován my.cnf or my.ini a nachází se v /atd/ or /etc/mysql/ adresář. Musíte jej otevřít a provést následující změny:

[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

Podívejme se také na další doporučení, která mohou usnadnit interakci s databází serveru:

1. Použití VYSVĚTLENÍ příkaz před SQL dotazem k analýze jeho provedení. To vám umožní získat plán provádění pro dotaz a určit, které indexy se používají, které tabulky jsou skenovány atd.
2. Indexy zrychlují vyhledávání dat, takže správně navržené indexy mohou výrazně zlepšit výkon dotazů. Věnujte pozornost sloupcům, které se často používají KDE or REGISTRACE podmínek.
3. Nepoužívejte SELECT *. Místo výběru všech sloupců v tabulce zadejte pouze ty sloupce, které jsou skutečně nezbytné pro váš dotaz.
4. Vyhněte se používání funkcí v KDE podmínky. Pomocí funkcí (např DOLNÍ, HORNÍ, LEFT, PRÁVO) v KDE podmínky mohou způsobit, že indexy nebudou k ničemu. Snažte se vyhnout jejich přímému použití v podmínkách.
5. Použijte INNER JOIN kde je to možné, protože je to obvykle efektivnější. Také se ujistěte, že odpovídající sloupce pro spojení mají indexy.
6. Použijte LIMIT pro omezení počtu vrácených řádků, pokud potřebujete získat pouze určitý počet výsledků.
7. Zvažte ukládání výsledků dotazů do mezipaměti, zejména pokud se zřídka mění, abyste snížili zatížení serveru.

Poštovní server vytváří vysoké zatížení serveru

V této části prozkoumáme, jak zjistit, že poštovní server je velmi zatížen, a jaké kroky lze podniknout k optimalizaci jeho provozu, včetně kontroly fronty zpráv a konfigurace parametrů serveru. Začněte kontrolou fronty zpráv. The mailq s tím může pomoci utilita, pro její aktivaci zadejte do terminálu odpovídající příkaz:

mailq

Zobrazí se seznam zpráv ve frontě, pokud existují. Každá zpráva bude zobrazena se svým jedinečným identifikátorem a informací o stavu odeslání. Podobný výsledek lze získat kontrolou protokolů poštovního klienta.

Ve většině případů dochází k vysokému zatížení v případě kompromitace serveru, když začne odesílat spam. Pokud je však správce po kontrole přesvědčen, že server nebyl napaden zvenčí a uživatelé nezanedbávají spam, je čas přejít k optimalizaci poštovního serveru. Zde jsou kroky, které vám pomohou:

1. Ujistěte se, že jsou záznamy DNS vaší domény správně nakonfigurovány, včetně SPF, rozšíření dkim, a DMARC záznamy pro zlepšení doručování pošty a ochranu před spamem. Správnou konfiguraci parametrů naleznete v článku na diagnostika poštovního serveru.
2. Zkontrolujte nastavení sítě, včetně konfigurace brány firewall a pravidel směrování, abyste zabránili blokování a urychlili doručování pošty.
3. Nakonfigurujte parametry fronty zpráv podle zatížení serveru. To může zahrnovat nastavení maximální velikosti fronty a časových limitů.
4. Zvažte řešení, která jsme diskutovali v tomto článku dříve. Pravidelně optimalizujte databázi poštovního serveru, abyste zlepšili výkon, používejte mechanismy ukládání do mezipaměti pro urychlení vyhledávání a zpracování dat, jako jsou dotazy DNS.
5. Pokud poštovní server stále pravidelně naráží na vysoké zatížení, zvažte možnosti škálování, jako je použití clusteru poštovních serverů nebo cloudových řešení.

Proč investovat do čističky vzduchu?

Zvýšené zatížení serveru přímo ovlivňuje rychlost načítání webových stránek, což v konečném důsledku ovlivňuje uživatelský dojem a reputaci ve vyhledávačích. Efektivní řízení této zátěže tak hraje klíčovou roli v zajištění nepřetržité funkčnosti zdroje a zvýšení jeho dostupnosti pro návštěvníky.