Serverbelasting verminderen

In dit artikel gaan we dieper in op de redenen waarom er een verhoogde serverbelasting optreedt en bespreken we verschillende manieren om processen met een hoge belasting te optimaliseren. Er wordt speciale aandacht besteed aan code-optimalisatie in Apache/Nginx en MySQL, we bespreken caching als hulpmiddel en we bespreken mogelijke externe bedreigingen, zoals DDOS-aanvallen, en manieren om deze te voorkomen.

Waarom serverbelasting optreedt

Voordat u doorgaat met serveroptimalisatie, is het noodzakelijk om een ​​grondige analyse uit te voeren van de huidige belasting van resources. Dit omvat het meten van CPU-belasting, RAM-gebruik, netwerkactiviteit en andere belangrijke parameters. Inzicht in de dynamiek en piekbelastingen maakt het mogelijk om knelpunten te identificeren en de toewijzing van resources te optimaliseren, waardoor de stabiliteit en prestaties van de serverinfrastructuur worden verbeterd.

Voor de eerste probleemoplossing bij een hoge serverbelasting raden wij aan een algemene serverdiagnostiek. Indien dit niet voldoende is, kan een meer gedetailleerde analyse van hulpbronnen is noodzakelijk. Als hulpmiddel is het verkennen van de logs van Linux server kan nuttig zijn, omdat daar in de meeste gevallen de oorzaak van het probleem ligt.

Apache/Nginx-server optimaliseren

Verhoogde serverbelasting door indexering

Verhoogde belasting door indexering op de server kan bijvoorbeeld optreden wanneer zoekmachines een groot aantal pagina's op uw site scannen. Dit kan leiden tot een verhoogd gebruik van serverbronnen en bijgevolg de prestaties van de site vertragen. Het identificeren van de oorzaak is relatief eenvoudig; u moet het bestand openen dat zich bevindt op:

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

Wanneer de zoekopdracht door zoekmachines wordt geïndexeerd, ziet de gebruiker vermeldingen van de volgende aard:

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

Als eerste oplossing om de belasting te verminderen, kunt u de instelling van metatags gebruiken "geen index" en "niet volgen" op pagina's die niet geïndexeerd hoeven te worden. De tweede oplossing is de .htaccess bestand, waar vermeldingen die overeenkomen met specifieke zoekmachines moeten worden toegevoegd, bijvoorbeeld om te verbergen voor Yandex en Google:

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

Op dezelfde manier moeten er bewerkingen worden uitgevoerd voor andere zoekmachines. Het moet worden opgemerkt dat de mogelijkheden van .htaccess niet beperkt zijn tot het blokkeren van indexering. We raden aan om meer vertrouwd te raken met de belangrijkste functies in de dit artikel.

Cache-instellingen gebruiken

Onjuiste cache-instellingen op de server kunnen ook leiden tot een hoge belasting. Om deze parameter te optimaliseren, moeten overeenkomstige wijzigingen worden aangebracht in de configuratiebestanden of .htaccessIn het geval van Apache is de laatste optie te verkiezen, voor Nginx de eerste.

Op een apache server, moet u de .htatoegang bestand en voeg de volgende code in:

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

Schakel vervolgens de Verloopt module met behulp van de opdracht:

sudo a2enmod expires

Start daarna de webserver opnieuw op:

sudo service apache2 restart

En activeer de module door het volgende op te geven:

ExpiresActive On

Op Nginx server, is het voldoende om de volgende code aan het configuratiebestand toe te voegen:

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

En voer een service reload uit:

sudo service nginx restart

Houd er rekening mee dat met deze instellingen de Allow en Weigeren richtlijnen worden omzeild.

Gegevenscompressie gebruiken

Gegevenscompressie inschakelen met behulp van gzip op Apache- en Nginx-webservers helpt de hoeveelheid gegevens die tussen de server en de client wordt verzonden, te verminderen. Dit verbetert de prestaties en verkort de laadtijd van webpagina's.

Inschakelen gzip on apache, moet u het mod_deflate module:

sudo a2enmod deflate

Start vervolgens de webserver opnieuw op:

sudo service apache2 restart

Voeg ten slotte het volgende blok toe aan het configuratiebestand of .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>

Met deze configuratie wordt compressie ingeschakeld voor bepaalde bestandstypen en uitgeschakeld voor afbeeldingen.

Bij Nginx, configuratie vindt plaats in de http blok van het configuratiebestand. De volgende code moet worden toegevoegd:

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;

Soortgelijke apache, hier worden de compressieparameters voor bepaalde typen bestanden ingesteld. Na het maken van wijzigingen op een van de webservers is een service reload vereist:

sudo service apache2 restart

Or

sudo service nginx restart

DDOS-aanval op de server

Een hoge serverbelasting kan optreden als gevolg van een DDoS-aanval. De aanwezigheid van een DDoS-aanval kan worden geïdentificeerd door een plotselinge toename in verkeer, abnormale verzoeken en serverprestatiedalingen te monitoren. Het controleren van logs op herhaalde verzoeken van één IP-adres of poortscanning kan ook duiden op een mogelijke DDoS-aanval. Er zijn veel beschermingsmaatregelen, maar we zullen alleen de basis bespreken.

Een CDN (Content Delivery Network) gebruiken. Een CDN kan dienen als tussenpersoon tussen uw webserver en gebruikers, door verkeer te distribueren en content te cachen om de impact van een DDoS-aanval te beperken. CDN's kunnen ook ingebouwde DDoS-beschermingsmechanismen hebben, waaronder load distribution en traffic filtering.

Firewalls en inbraakdetectiesystemen (IDS/IPS) configureren. Firewalls kunnen worden geconfigureerd om verkeer te filteren op basis van verschillende criteria, zoals IP-adressen en poorten. IDS/IPS kunnen abnormaal verkeersgedrag detecteren en verdachte verbindingen blokkeren. Deze tools kunnen effectief zijn bij het traceren en blokkeren van potentieel kwaadaardig verkeer.

Apache- en Nginx-webservers configureren om de impact van DDoS-aanvallen te beperken.

Als oplossing voor Apache maken we het mogelijk mod_evasive module. Om dit te doen, verwijdert u de volgende regel uit de commentaarregel of voegt u deze toe in de httpd.conf or apache2.conf configuratiebestand:

LoadModule evasive20_module modules/mod_evasive.so

In hetzelfde bestand moet u een instellingenblok toevoegen:

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

Op dezelfde manier activeren we de mod_snelheidslimiet module:

LoadModule ratelimit_module modules/mod_ratelimit.so

En voeg de configuratie toe:

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

De configuratie voor Nginx is gelijk aan apache. In de nginx.conf configuratiebestand moeten de volgende richtlijnen worden gebruikt:

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;

        ...
    }
}

Nadat u wijzigingen in de services hebt aangebracht, moeten deze opnieuw worden geladen:

sudo systemctl restart apache2

Of:

sudo systemctl restart nginx

Deze voorbeelden bieden slechts een basisconfiguratie. Deze kan verder worden aangepast, afhankelijk van de specifieke vereisten en de aard van de aanvallen.

MySQL-query's optimaliseren

Het optimaliseren van MySQL-databasequery's op een webserver kan op verschillende manieren worden bereikt, en een daarvan is de juiste configuratie van het configuratiebestand. Meestal heet dit bestand mijn.cnf or mijn.ini en is gelegen in de /enz/ or /etc/mysql/ directory. U moet deze openen en de volgende wijzigingen aanbrengen:

[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

Laten we ook nog eens kijken naar aanvullende aanbevelingen die de interactie met de serverdatabase kunnen vergemakkelijken:

1. Gebruik de uitleggen opdracht voor een SQL-query om de uitvoering ervan te analyseren. Hiermee kunt u een uitvoeringsplan voor de query krijgen en bepalen welke indexen worden gebruikt, welke tabellen worden gescand, etc.
2. Indexen versnellen het zoeken naar gegevens, dus goed ontworpen indexen kunnen de queryprestaties aanzienlijk verbeteren. Let op kolommen die vaak worden gebruikt in WAAR or AANMELDEN voorwaarden.
3. Vermijd te gebruiken SELECT *Geef alleen de kolommen op die echt nodig zijn voor uw query, in plaats van alle kolommen in een tabel te selecteren.
4. Vermijd het gebruik van functies in WAAR voorwaarden. Met behulp van functies (zoals LAGER, UPPER, LINKS, RECHTS) in WAAR voorwaarden kunnen indexen nutteloos maken. Probeer hun directe gebruik in voorwaarden te vermijden.
5. Gebruik INNER JOIN waar mogelijk, omdat het meestal efficiënter is. Zorg er ook voor dat de corresponderende kolommen voor joining indexen hebben.
6. Gebruik LIMIT om het aantal geretourneerde rijen te beperken als u slechts een bepaald aantal resultaten nodig hebt.
7. Overweeg om queryresultaten te cachen, vooral als ze zelden veranderen, om de serverbelasting te verminderen.

De mailserver zorgt voor een hoge belasting van de server

In deze sectie zullen we onderzoeken hoe we kunnen vaststellen dat de mailserver een hoge belasting ervaart en welke stappen er kunnen worden genomen om de werking ervan te optimaliseren, inclusief het controleren van de berichtenwachtrij en het configureren van serverparameters. Begin met het controleren van de berichtenwachtrij. De mailq hulpprogramma kan hierbij helpen, om het te activeren, voer de overeenkomstige opdracht in de terminal in:

mailq

Dit zal een lijst van berichten in de wachtrij weergeven, indien aanwezig. Elk bericht zal worden weergegeven met zijn unieke identificatie en informatie over de verzendstatus. Een soortgelijk resultaat kan worden verkregen door de mailclientlogs te bekijken.

In de meeste gevallen treedt er een hoge belasting op in het geval van een servercompromis wanneer deze spam begint te versturen. Als de beheerder echter na controle zeker weet dat de server niet van buitenaf is aangevallen en gebruikers spam niet verwaarlozen, is het tijd om de mailserver te optimaliseren. Hier zijn de stappen die zullen helpen:

1. Zorg ervoor dat de DNS-records van uw domein correct zijn geconfigureerd, inclusief SPF, DKIMen DMARC records om de bezorging van e-mail te verbeteren en te beschermen tegen spam. De juiste configuratie van parameters is te vinden in het artikel over mailserver diagnostiek.
2. Controleer de netwerkinstellingen, waaronder de firewallconfiguratie en routeringsregels, om blokkades te voorkomen en de bezorging van e-mail te versnellen.
3. Configureer berichtwachtrijparameters volgens serverbelasting. Dit kan het instellen van de maximale wachtrijgrootte en time-outs omvatten.
4. Denk aan de oplossingen die we eerder in dit artikel hebben besproken. Optimaliseer de mailserverdatabase periodiek om de prestaties te verbeteren, gebruik cachingmechanismen om het zoeken naar en verwerken van gegevens te versnellen, zoals DNS-query's.
5. Als de mailserver nog steeds regelmatig een hoge belasting ondervindt, kunt u schaalopties overwegen, zoals het gebruik van een cluster van mailservers of cloudoplossingen.

Conclusie

Verhoogde serverbelasting heeft direct invloed op de laadsnelheid van de website, wat uiteindelijk van invloed is op de gebruikerservaring en reputatie in zoekmachines. Het effectief beheren van deze belasting speelt dus een belangrijke rol bij het waarborgen van de continue functionaliteit van de bron en het vergroten van de toegankelijkheid ervan voor bezoekers.