Minska serverbelastningen

I den här artikeln kommer vi att fördjupa oss i varför ökad serverbelastning uppstår och diskutera olika sätt att optimera högbelastningsprocesser. Särskild uppmärksamhet kommer att ägnas åt kodoptimering i Apache/Nginx och MySQL, vi kommer att prata om cachning som ett hjälpverktyg och även överväga möjliga externa hot, såsom DDOS-attacker, och sätt att förhindra dem.

Varför serverbelastning uppstår

Innan du går vidare till serveroptimering är det nödvändigt att göra en grundlig analys av den aktuella belastningen på resurser. Detta inkluderar mätning av CPU-belastning, RAM-användning, nätverksaktivitet och andra nyckelparametrar. Att förstå dynamiken och toppbelastningarna gör det möjligt att identifiera flaskhalsar och optimera resursallokeringen, vilket ökar stabiliteten och prestanda hos serverinfrastrukturen.

För initial felsökning av hög serverbelastning rekommenderar vi att du utför en allmän serverdiagnostik. Om detta är otillräckligt, en mer detaljerad analys av resurser är nödvändigt. Som ett hjälpverktyg kan du utforska loggar för Linux server kan vara till hjälp, eftersom det är här källan till problemet finns i de flesta fall.

Optimera Apache/Nginx Server

Ökad serverbelastning på grund av indexering

Ökad belastning på grund av indexering på servern kan till exempel uppstå när sökmotorer skannar ett stort antal sidor på din webbplats. Detta kan leda till ökad användning av serverresurser och följaktligen sakta ner webbplatsens prestanda. Att identifiera orsaken är relativt enkelt; du måste öppna filen som finns på:

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

När den indexeras av sökmotorer kommer användaren att se poster av följande karaktär:

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

Som en första lösning för att minska belastningen kan du använda inställningen av metataggar "noindex" och "nofollow" på sidor som inte behöver indexeras. Den andra lösningen är .htaccess fil, där poster som motsvarar specifika sökmotorer måste läggas till, till exempel för att dölja från Yandex och Google:

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

På samma sätt måste redigeringar göras för andra sökmotorer. Det bör noteras att funktionerna i .htaccess inte är begränsade till att bara blockera indexering. Vi rekommenderar att du blir mer bekant med dess huvudfunktioner i Artikeln.

Använda cacheinställningar

Felaktiga cacheinställningar på servern kan också leda till hög belastning. För att optimera denna parameter måste motsvarande ändringar göras i konfigurationsfilerna eller .htaccess. När det gäller Apache är det senare alternativet att föredra, för Nginx – det förra.

På en Apache server måste du öppna .htacess fil och infoga följande kod:

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

Aktivera sedan Utgår modul med kommandot:

sudo a2enmod expires

Starta sedan om webbservern:

sudo service apache2 restart

Och aktivera modulen genom att specificera:

ExpiresActive On

På en nginx server, är det tillräckligt att lägga till följande kod till konfigurationsfilen:

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

Och utför en omladdning av tjänsten:

sudo service nginx restart

Observera att med dessa inställningar, Tillåt och Neka direktiv kommer att kringgås.

Använder datakomprimering

Aktiverar datakomprimering med gzip på Apache och Nginx webbservrar hjälper till att minska mängden data som överförs mellan servern och klienten, vilket förbättrar prestandan och minskar webbsidans laddningstid.

Att möjliggöra gzip on Apachemåste du aktivera mod_deflate modul:

sudo a2enmod deflate

Starta sedan om webbservern:

sudo service apache2 restart

Och slutligen, lägg till följande block i konfigurationsfilen eller .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>

Denna konfiguration möjliggör komprimering för vissa typer av filer och inaktiverar den för bilder.

I fallet med nginx, konfiguration sker i http block av konfigurationsfilen. Följande kod måste läggas till:

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;

Liknar Apache, här ställs komprimeringsparametrarna för vissa typer av filer in. Efter att ha gjort ändringar på någon av webbservrarna krävs en omladdning av tjänsten:

sudo service apache2 restart

Or

sudo service nginx restart

DDOS-attack på servern

Hög serverbelastning kan uppstå som ett resultat av en DDoS-attack. Att identifiera förekomsten av en DDoS-attack kan göras genom att övervaka en plötslig ökning av trafiken, onormala förfrågningar och sänkta serverprestanda. Granskning av loggar för upprepade förfrågningar från en IP-adress eller portskanning kan också indikera en möjlig DDoS-attack. Det finns många skyddsåtgärder, men vi kommer bara att diskutera grunderna.

Använda ett CDN (Content Delivery Network). Ett CDN kan fungera som en mellanhand mellan din webbserver och användare, distribuera trafik och cachelagra innehåll för att mildra effekterna av en DDoS-attack. CDN:er kan också ha inbyggda DDoS-skyddsmekanismer, inklusive lastfördelning och trafikfiltrering.

Konfigurera brandväggar och intrångsdetekteringssystem (IDS/IPS). Brandväggar kan konfigureras för att filtrera trafik baserat på olika kriterier, såsom IP-adresser och portar. IDS/IPS kan upptäcka onormalt trafikbeteende och blockera misstänkta anslutningar. Dessa verktyg kan vara effektiva för att spåra och blockera potentiellt skadlig trafik.

Konfigurera Apache- och Nginx-webbservrar för att mildra effekterna av DDoS-attacker.

Som en lösning för Apache, aktiverar vi mod_evasive modul. För att göra detta, avkommentera eller lägg till följande rad i httpd.conf or apache2.conf konfigurationsfil:

LoadModule evasive20_module modules/mod_evasive.so

I samma fil måste du lägga till ett inställningsblock:

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

På samma sätt aktiverar vi mod_ratelimit modul:

LoadModule ratelimit_module modules/mod_ratelimit.so

Och lägg till konfigurationen:

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

Konfigurationen för nginx liknar Apache. I nginx.conf konfigurationsfil, måste följande direktiv användas:

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;

        ...
    }
}

Efter att ha gjort ändringar i var och en av tjänsterna måste de laddas om:

sudo systemctl restart apache2

eller:

sudo systemctl restart nginx

Dessa exempel ger endast en grundläggande konfiguration, som kan anpassas ytterligare beroende på specifika krav och typen av attacker.

Optimera MySQL-frågor

Optimering av MySQL-databasfrågor på en webbserver kan uppnås på olika sätt, och ett av dem är korrekt konfiguration av konfigurationsfilen. Vanligtvis heter den här filen min.cnf or min.ini och ligger i /etc/ or /etc/mysql/ katalog. Du måste öppna den och göra följande ändringar:

[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

Låt oss också överväga ytterligare rekommendationer som kan underlätta interaktion med serverdatabasen:

1. Använd FÖRKLARA kommando före en SQL-fråga för att analysera dess exekvering. Detta gör att du kan få en exekveringsplan för frågan och bestämma vilka index som används, vilka tabeller som skannas etc.
2. Index påskyndar datasökning, så korrekt designade index kan förbättra frågeprestanda avsevärt. Var uppmärksam på kolumner som används ofta i VAR or JOIN förhållanden.
3. Undvik att använda VÄLJ *. Ange bara de kolumner som verkligen är nödvändiga för din fråga, istället för att välja alla kolumner i en tabell.
4. Undvik att använda funktioner i VAR villkor. Använda funktioner (som LÄGRE, ÖVRE, VÄNSTER, RÄTT) i VAR förhållanden kan göra index värdelösa. Försök att undvika direkt användning under förhållanden.
5. Använda INNER JOIN där det är möjligt, eftersom det vanligtvis är mer effektivt. Se också till att motsvarande kolumner för sammanfogning har index.
6. Använda BEGRÄNSA för att begränsa antalet returnerade rader om du bara behöver få ett visst antal resultat.
7. Överväg att cacha frågeresultat, särskilt om de sällan ändras, för att minska serverbelastningen.

E-postservern skapar hög belastning på servern

I det här avsnittet kommer vi att utforska hur man avgör att e-postservern upplever hög belastning och vilka steg som kan tas för att optimera dess funktion, inklusive att kontrollera meddelandekön och konfigurera serverparametrar. Börja med att kolla meddelandekön. De mailq verktyget kan hjälpa till med detta, för att aktivera det, skriv in motsvarande kommando i terminalen:

mailq

Detta kommer att visa en lista över meddelanden i kön, om några. Varje meddelande kommer att visas med sin unika identifierare och information om sändningsstatus. Ett liknande resultat kan erhållas genom att granska e-postklientloggarna.

I de flesta fall uppstår hög belastning i händelse av serverkompromiss när den börjar skicka skräppost. Men om administratören efter att ha kontrollerat är säker på att servern inte har attackerats utifrån och användare inte försummar spam, är det dags att gå vidare till att optimera e-postservern. Här är stegen som hjälper:

1. Se till att din domäns DNS-poster är korrekt konfigurerade, inklusive SPF, dkim förlängningoch DMARC-tillägg register för att förbättra postleveransen och skydda mot skräppost. Den korrekta konfigurationen av parametrar finns i artikeln om e-postserverdiagnostik.
2. Kontrollera nätverksinställningarna, inklusive brandväggskonfiguration och routningsregler, för att undvika blockeringar och påskynda postleveransen.
3. Konfigurera meddelandeköparametrar enligt serverbelastning. Detta kan inkludera att ställa in maximal köstorlek och tidsgränser.
4. Överväg de lösningar som vi diskuterade i den här artikeln tidigare. Optimera regelbundet e-postserverdatabasen för att förbättra prestandan, använd cachningsmekanismer för att påskynda datasökning och bearbetning, såsom DNS-frågor.
5. Om e-postservern fortfarande regelbundet stöter på hög belastning, överväg skalningsalternativ, som att använda ett kluster av e-postservrar eller molnlösningar.

Slutsats

Ökad serverbelastning påverkar direkt webbladdningshastigheten, vilket i slutändan påverkar användarupplevelsen och ryktet i sökmotorerna. Effektiv hantering av denna belastning spelar således en nyckelroll för att säkerställa kontinuerlig funktionalitet hos resursen och öka dess tillgänglighet för besökare.