Redusere serverbelastning

I denne artikkelen skal vi fordype oss i hvorfor økt serverbelastning oppstår og diskutere ulike måter å optimalisere høybelastningsprosesser på. Spesiell oppmerksomhet vil bli gitt til kodeoptimalisering i Apache/Nginx og MySQL, vi vil snakke om caching som et hjelpeverktøy, og også vurdere mulige eksterne trusler, som DDOS-angrep, og måter å forhindre dem på.

Hvorfor serverbelastning oppstår

Før du går videre til serveroptimalisering, er det nødvendig å gjennomføre en grundig analyse av gjeldende ressursbelastning. Dette inkluderer måling av CPU-belastning, RAM-bruk, nettverksaktivitet og andre nøkkelparametere. Å forstå dynamikken og toppbelastningene gjør det mulig å identifisere flaskehalser og optimalisere ressursallokering, og dermed øke stabiliteten og ytelsen til serverinfrastrukturen.

For innledende feilsøking av høy serverbelastning anbefaler vi å utføre en generell serverdiagnostikk . Hvis dette ikke er tilstrekkelig, er en mer detaljert analyse av ressursene nødvendig. Som et hjelpeverktøy kan det være nyttig å utforske loggene til Linux- serveren, da det er her kilden til problemet finnes i de fleste tilfeller.

Optimalisering av Apache/Nginx Server

Økt serverbelastning på grunn av indeksering

Økt belastning på grunn av indeksering på serveren kan for eksempel oppstå når søkemotorer skanner et stort antall sider på nettstedet ditt. Dette kan føre til økt bruk av serverressurser og følgelig redusere nettstedets ytelse. Å identifisere årsaken er relativt enkel; du må åpne filen som ligger på:

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

Når indeksert av søkemotorer, vil brukeren se oppføringer av følgende art:

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ørste løsning for å redusere belastningen, kan du bruke innstillingen av metataggene «noindex» og «nofollow» på sider som ikke trenger å indekseres. Den andre løsningen er .htaccess- filen, hvor oppføringer som tilsvarer spesifikke søkemotorer må legges til, for eksempel for å skjule seg fra Yandex og 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å samme måte må det gjøres endringer for andre søkemotorer. Det bør bemerkes at mulighetene til .htaccess ikke er begrenset til bare å blokkere indeksering. Vi anbefaler at du blir mer kjent med hovedfunksjonene i artikkelen.

Bruke cacheinnstillinger

Feil mellomlagringsinnstillinger på serveren kan også føre til høy belastning. For å optimalisere denne parameteren må tilsvarende endringer gjøres i konfigurasjonsfilene eller .htaccess . For Apache er det siste alternativet å foretrekke, for Nginx det første.

På en Apache- server må du åpne .htacess- filen og sette inn følgende kode:

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

Aktiver deretter Expires- modulen ved å bruke kommandoen:

sudo a2enmod expires

Start deretter webserveren på nytt:

sudo service apache2 restart

Og aktiver modulen ved å spesifisere:

ExpiresActive On

På en Nginx- server er det tilstrekkelig å legge til følgende kode i konfigurasjonsfilen:

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

Og utfør en tjenesteinnlasting:

sudo service nginx restart

Merk at med disse innstillingene vil Tillat- og Avslå -direktivene bli omgått.

Bruke datakomprimering

Å aktivere datakomprimering med Gzip på Apache- og Nginx-webservere bidrar til å redusere mengden data som overføres mellom serveren og klienten, noe som forbedrer ytelsen og reduserer lastetiden for nettsider.

For å aktivere Gzip på Apache , må du aktivere mod_deflate- modulen:

sudo a2enmod deflate

Start deretter webserveren på nytt:

sudo service apache2 restart

Og til slutt, legg til følgende blokk i konfigurasjonsfilen 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>

Denne konfigurasjonen aktiverer komprimering for visse typer filer og deaktiverer den for bilder.

Når det gjelder Nginx , skjer konfigurasjonen i http- blokken i konfigurasjonsfilen. Følgende kode må legges til:

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;

I likhet med Apache angis komprimeringsparametrene for bestemte filtyper her. Etter at du har gjort endringer på en av webserverne, kreves det en ny innlasting av tjenesten:

sudo service apache2 restart

Or

sudo service nginx restart

DDOS-angrep på serveren

Høy serverbelastning kan oppstå som et resultat av et DDoS-angrep. Å identifisere tilstedeværelsen av et DDoS-angrep kan gjøres ved å overvåke en plutselig økning i trafikk, unormale forespørsler og nedsatt serverytelse. Gjennomgang av logger for gjentatte forespørsler fra én IP-adresse eller portskanning kan også indikere et mulig DDoS-angrep. Det er mange beskyttelsestiltak, men vi skal bare diskutere det grunnleggende.

Bruk av et CDN (Content Delivery Network) . Et CDN kan fungere som en mellomledd mellom webserveren din og brukerne, distribuere trafikk og mellomlagre innhold for å redusere virkningen av et DDoS-angrep. CDN-er kan også ha innebygde DDoS-beskyttelsesmekanismer, inkludert lastfordeling og trafikkfiltrering.

Konfigurering av brannmurer og inntrengingsdeteksjonssystemer (IDS/IPS) . Brannmurer kan konfigureres til å filtrere trafikk basert på ulike kriterier, for eksempel IP-adresser og porter. IDS/IPS kan oppdage unormal trafikkatferd og blokkere mistenkelige tilkoblinger. Disse verktøyene kan være effektive for å spore og blokkere potensielt ondsinnet trafikk.

Konfigurering av Apache- og Nginx-nettservere for å redusere virkningen av DDoS-angrep.

Som en løsning for Apache aktiverer vi mod_evasive -modulen. For å gjøre dette, fjern kommenteringen eller legg til følgende linje i konfigurasjonsfilen httpd.conf eller apache2.conf :

LoadModule evasive20_module modules/mod_evasive.so

I samme fil må du legge til en innstillingsblokk:

<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å samme måte aktiverer vi mod_ratelimit- modulen:

LoadModule ratelimit_module modules/mod_ratelimit.so

Og legg til konfigurasjonen:

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

Konfigurasjonen for Nginx ligner på Apache . I konfigurasjonsfilen nginx.conf må følgende direktiver brukes:

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;

        ...
    }
}

Etter å ha gjort endringer i hver av tjenestene, må de lastes inn på nytt:

sudo systemctl restart apache2

Eller:

sudo systemctl restart nginx

Disse eksemplene gir bare en grunnleggende konfigurasjon, som kan tilpasses ytterligere avhengig av spesifikke krav og typen angrep.

Optimalisering av MySQL-spørringer

Optimalisering av MySQL-databasespørringer på en webserver kan oppnås på flere måter, og en av dem er riktig konfigurasjon av konfigurasjonsfilen. Vanligvis heter denne filen my.cnf eller my.ini og ligger i /etc/- eller /etc/mysql/ -katalogen. Du må åpne den og gjøre følgende endringer:

[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

La oss også vurdere ytterligere anbefalinger som kan lette interaksjon med serverdatabasen:

1. Bruke FORKLARE kommando før en SQL-spørring for å analysere utførelsen av den. Dette lar deg få en utførelsesplan for spørringen og bestemme hvilke indekser som brukes, hvilke tabeller som skannes osv.
2. Indekser øker hastigheten på datasøk, så riktig utformede indekser kan forbedre søkeytelsen betydelig. Vær oppmerksom på kolonner som brukes ofte i HVOR or BLI forhold.
3. Unngå bruk PLUKKE UT *. Spesifiser bare de kolonnene som virkelig er nødvendige for søket ditt, i stedet for å velge alle kolonnene i en tabell.
4. Unngå å bruke funksjoner i HVOR forhold. Bruke funksjoner (som f NEDRE, ØVRE, VENSTRE, HØYRE) i HVOR forhold kan gjøre indekser ubrukelige. Prøv å unngå direkte bruk under forhold.
5. Bruk INNER JOIN der det er mulig, da det vanligvis er mer effektivt. Sørg også for at de tilsvarende kolonnene for sammenføyning har indekser.
6. Bruk BEGRENSE for å begrense antall returnerte rader hvis du bare trenger å få et visst antall resultater.
7. Vurder å bufre spørringsresultater, spesielt hvis de sjelden endres, for å redusere serverbelastningen.

E-postserveren skaper høy belastning på serveren

I denne delen skal vi utforske hvordan vi kan fastslå om e-postserveren opplever høy belastning, og hvilke tiltak som kan iverksettes for å optimalisere driften, inkludert å sjekke meldingskøen og konfigurere serverparametere. Start med å sjekke meldingskøen. Mailq- verktøyet kan hjelpe med dette. For å aktivere det, skriv inn den tilsvarende kommandoen i terminalen:

mailq

Dette vil vise en liste over meldinger i køen, hvis noen. Hver melding vil vises med sin unike identifikator og informasjon om sendestatus. Et lignende resultat kan oppnås ved å gå gjennom e-postklientloggene.

I de fleste tilfeller oppstår høy belastning i tilfelle serverkompromittering når den begynner å sende spam. Men hvis administratoren etter å ha sjekket er sikker på at serveren ikke har blitt angrepet fra utsiden og brukere ikke overser spam, er det på tide å gå videre til å optimalisere e-postserveren. Her er trinnene som vil hjelpe:

1. Sørg for at domenets DNS-poster er riktig konfigurert, inkludert SPF, DKIMog DMARC poster for å forbedre postlevering og beskytte mot spam. Riktig konfigurasjon av parametere finner du i artikkelen om e-postserverdiagnostikk.
2. Sjekk nettverksinnstillingene, inkludert brannmurkonfigurasjon og rutingsregler, for å unngå blokkeringer og øke hastigheten på postlevering.
3. Konfigurer meldingskøparametere i henhold til serverbelastning. Dette kan inkludere å angi maksimal køstørrelse og tidsavbrudd.
4. Vurder løsningene vi diskuterte i denne artikkelen tidligere. Optimaliser e-postserverdatabasen med jevne mellomrom for å forbedre ytelsen, bruk hurtigbuffermekanismer for å øke hastigheten på datasøk og -behandling, for eksempel DNS-spørringer.
5. Hvis e-postserveren fortsatt opplever høy belastning regelmessig, bør du vurdere skaleringsalternativer, for eksempel å bruke en klynge med e-postservere eller skyløsninger.

Konklusjon

Økt serverbelastning påvirker lastehastigheten på nettstedet direkte, og påvirker til slutt brukeropplevelsen og omdømmet i søkemotorene. Effektiv håndtering av denne belastningen spiller derfor en nøkkelrolle for å sikre kontinuerlig funksjonalitet til ressursen og øke tilgjengeligheten for besøkende.