Serveri koormuse vähendamine

Selles artiklis uurime, miks serveri koormus suureneb, ja käsitleme erinevaid võimalusi suure koormusega protsesside optimeerimiseks. Erilist tähelepanu pööratakse koodi optimeerimisele Apache/Nginxis ja MySQL-is, räägime vahemällu salvestamisest kui abitööriistast ning vaatleme ka võimalikke väliseid ohte, nagu DDOS-i rünnakud, ja nende vältimise viise.

Miks serveri koormus toimub

Enne serveri optimeerimise juurde asumist on vaja põhjalikult analüüsida ressursside praegust koormust. See hõlmab protsessori koormuse, RAM-i kasutuse, võrgutegevuse ja muude oluliste parameetrite mõõtmist. Dünaamika ja tippkoormuse mõistmine võimaldab tuvastada kitsaskohti ja optimeerida ressursside jaotust, suurendades seeläbi serveri infrastruktuuri stabiilsust ja jõudlust.

Suure serverikoormuse esmaseks tõrkeotsinguks soovitame läbi viia a üldine serveri diagnostika. Kui sellest ei piisa, siis üksikasjalikum ressursside analüüs on vajalik. Abivahendina uurides Linuxi logid server võib abiks olla, sest enamikul juhtudel leitakse sealt probleemi allikas.

Apache/Nginxi serveri optimeerimine

Indekseerimise tõttu suurenenud serverikoormus

Serveris indekseerimisest tulenev suurem koormus võib tekkida näiteks siis, kui otsingumootorid skannivad teie saidil palju lehti. See võib kaasa tuua serveriressursside suurema kasutamise ja sellest tulenevalt aeglustada saidi jõudlust. Põhjuse tuvastamine on suhteliselt lihtne; peate avama faili, mis asub aadressil:

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

Otsingumootorite indekseerimisel näeb kasutaja järgmist laadi kirjeid:

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

Esimese lahendusena koormuse vähendamiseks võite kasutada metasiltide seadistust "noindex" ja "nofollow" lehtedel, mida pole vaja indekseerida. Teine lahendus on .htaccess faili, kuhu tuleb lisada konkreetsetele otsingumootoritele vastavad kirjed, näiteks Yandexi ja Google'i eest peitmiseks:

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

Samamoodi tuleb muudatusi teha ka teiste otsingumootorite jaoks. Tuleb märkida, et .htaccess'i võimalused ei piirdu ainult indekseerimise blokeerimisega. Soovitame selle põhifunktsioonidega lähemalt tutvuda artikkel.

Vahemälu seadete kasutamine

Valed vahemällu salvestamise sätted serveris võivad samuti põhjustada suure koormuse. Selle parameetri optimeerimiseks tuleb teha vastavad muudatused konfiguratsioonifailides või .htaccess. Apache puhul on eelistatud viimane variant, Nginxi puhul esimene.

Sisse Apache server, peate avama .htacess faili ja sisestage järgmine kood:

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

Seejärel lubage Aegub moodul käsuga:

sudo a2enmod expires

Pärast seda taaskäivitage veebiserver:

sudo service apache2 restart

Ja aktiveerige moodul, määrates:

ExpiresActive On

Kohta nginx server, piisab järgmise koodi lisamisest konfiguratsioonifaili:

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

Ja tehke teenuse uuesti laadimine:

sudo service nginx restart

Pange tähele, et nende seadistustega lubama ja eitama direktiividest eiratakse.

Andmete tihendamise kasutamine

Andmete tihendamise lubamine kasutades Gzip Apache ja Nginxi veebiserverites aitab vähendada serveri ja kliendi vahel edastatavate andmete hulka, mis parandab jõudlust ja vähendab veebilehe laadimisaega.

Võimaldada Gzip on Apache, peate aktiveerima mod_deflate moodul:

sudo a2enmod deflate

Seejärel taaskäivitage veebiserver:

sudo service apache2 restart

Ja lõpuks lisage konfiguratsioonifaili või .htaccessile järgmine plokk:

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

See konfiguratsioon võimaldab teatud tüüpi failide tihendamist ja keelab selle piltide puhul.

Juhul kui nginx, konfiguratsioon toimub rakenduses http konfiguratsioonifaili plokk. Tuleb lisada järgmine kood:

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;

Sarnaselt Apache, siin määratakse teatud tüüpi failide tihendamise parameetrid. Pärast mis tahes veebiserveris muudatuste tegemist on vajalik teenuse uuesti laadimine:

sudo service apache2 restart

Or

sudo service nginx restart

DDOS-i rünnak serverile

DDoS-i rünnaku tagajärjel võib tekkida serveri suur koormus. DDoS-i rünnaku olemasolu saab tuvastada liikluse äkilise suurenemise, ebatavaliste päringute ja serveri jõudluse languse jälgimise kaudu. Ühe IP-aadressi korduvate päringute logide ülevaatamine või pordi skaneerimine võib samuti viidata võimalikule DDoS-i rünnakule. Kaitsemeetmeid on palju, kuid me käsitleme ainult põhitõdesid.

CDN-i (sisu edastamise võrgu) kasutamine. CDN võib olla vahendaja teie veebiserveri ja kasutajate vahel, jaotades liiklust ja salvestades sisu vahemällu, et leevendada DDoS-i rünnaku mõju. CDN-idel võivad olla ka sisseehitatud DDoS-i kaitsemehhanismid, sealhulgas koormuse jaotus ja liikluse filtreerimine.

Tulemüüride ja sissetungimise tuvastamise süsteemide (IDS/IPS) konfigureerimine. Tulemüüre saab konfigureerida filtreerima liiklust erinevate kriteeriumide alusel, nagu IP-aadressid ja pordid. IDS/IPS suudab tuvastada ebanormaalset liikluskäitumist ja blokeerida kahtlased ühendused. Need tööriistad võivad olla tõhusad potentsiaalselt pahatahtliku liikluse jälgimisel ja blokeerimisel.

Apache ja Nginxi veebiserverite konfigureerimine DDoS-i rünnakute mõju leevendamiseks.

Apache'i lahendusena lubame mod_evasive moodul. Selleks tühjendage kommentaarid või lisage järgmine rida httpd.conf or apache2.conf konfiguratsioonifail:

LoadModule evasive20_module modules/mod_evasive.so

Samas failis peate lisama seadete ploki:

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

Samamoodi aktiveerime mod_ratelimit moodul:

LoadModule ratelimit_module modules/mod_ratelimit.so

Ja lisage konfiguratsioon:

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

Konfiguratsioon jaoks nginx on sarnane Apache. Aasta nginx.conf konfiguratsioonifaili, tuleb kasutada järgmisi direktiive:

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;

        ...
    }
}

Pärast igas teenuses muudatuste tegemist tuleb need uuesti laadida:

sudo systemctl restart apache2

Või:

sudo systemctl restart nginx

Need näited pakuvad ainult põhikonfiguratsiooni, mida saab täiendavalt kohandada sõltuvalt konkreetsetest nõuetest ja rünnakute olemusest.

MySQL päringute optimeerimine

MySQL-i andmebaasipäringuid veebiserveris saab optimeerida mitmel viisil ja üks neist on konfiguratsioonifaili õige konfigureerimine. Tavaliselt antakse sellele failile nimi minu.cnf or my.ini ja asub /jne/ or /etc/mysql/ kataloog. Peate selle avama ja tegema järgmised muudatused:

[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

Mõelgem ka täiendavatele soovitustele, mis hõlbustavad suhtlemist serveri andmebaasiga:

1. Kasuta SELGIDA käsk enne SQL-päringut selle täitmise analüüsimiseks. See võimaldab teil saada päringu täitmisplaani ja määrata, milliseid indekseid kasutatakse, milliseid tabeleid kontrollitakse jne.
2. Indeksid kiirendavad andmete otsimist, nii et õigesti kavandatud indeksid võivad päringu jõudlust oluliselt parandada. Pöörake tähelepanu veergudele, mida sageli kasutatakse KUS or LIITU tingimustel.
3. Vältige kasutamist SELECT *. Määrake ainult need veerud, mis on teie päringu jaoks tõeliselt vajalikud, selle asemel, et valida tabeli kõik veerud.
4. Vältige funktsioonide kasutamist KUS tingimused. Funktsioonide kasutamine (nt MADALAM, Ülemine, LEFT, PAREM) sisse KUS tingimused võivad muuta indeksid kasutuks. Püüdke vältida nende otsest kasutamist tingimustes.
5. Kasutama INNER JOIN võimaluse korral, kuna see on tavaliselt tõhusam. Samuti veenduge, et vastavatel liitumisveergudel on indeksid.
6. Kasutama LIMIT tagastatavate ridade arvu piiramiseks, kui soovite saada ainult teatud arvu tulemusi.
7. Kaaluge päringutulemuste vahemällu salvestamist, eriti kui need muutuvad harva, et vähendada serveri koormust.

Meiliserver tekitab serverile suure koormuse

Selles jaotises uurime, kuidas teha kindlaks, et meiliserver on suure koormuse all ja milliseid samme saab selle töö optimeerimiseks võtta, sealhulgas kontrollida sõnumijärjekorda ja seadistada serveri parameetreid. Alustage sõnumite järjekorra kontrollimisega. The mailq utiliit saab selles aidata, selle aktiveerimiseks sisestage terminali vastav käsk:

mailq

See kuvab järjekorras olevate sõnumite loendi, kui neid on. Iga sõnum kuvatakse koos selle kordumatu identifikaatori ja teabega saatmisoleku kohta. Sarnase tulemuse võib saada ka meiliklientide logide ülevaatamisel.

Enamikul juhtudel tekib suur koormus serveri ohu korral, kui see hakkab rämpsposti saatma. Kui aga administraator on pärast kontrollimist kindel, et serverit ei ole väljastpoolt rünnatud ja kasutajad ei jäta rämpsposti tähelepanuta, on aeg liikuda edasi meiliserveri optimeerimise juurde. Siin on sammud, mis aitavad.

1. Veenduge, et teie domeeni DNS-kirjed on õigesti konfigureeritud, sealhulgas SPF, dkim laiendusja DMARC laiendus kirjed, et parandada kirjade kohaletoimetamist ja kaitsta rämpsposti eest. Parameetrite õige konfiguratsiooni leiate artiklist meiliserveri diagnostika.
2. Kontrollige võrgusätteid, sealhulgas tulemüüri konfiguratsiooni ja marsruutimise reegleid, et vältida blokeeringuid ja kiirendada kirjade kohaletoimetamist.
3. Seadistage sõnumijärjekorra parameetrid vastavalt serveri koormusele. See võib hõlmata maksimaalse järjekorra suuruse ja ajalõppude määramist.
4. Mõelge lahendustele, mida me selles artiklis varem käsitlesime. Perioodiliselt optimeerige meiliserveri andmebaasi jõudluse parandamiseks, kasutage vahemällu salvestamise mehhanisme, et kiirendada andmete otsimist ja töötlemist, näiteks DNS-päringuid.
5. Kui meiliserver on ikka veel regulaarselt koormatud, kaaluge skaleerimisvalikuid, näiteks meiliserverite klastri või pilvelahenduste kasutamist.

Järeldus

Suurenenud serverikoormus mõjutab otseselt veebisaidi laadimiskiirust, mõjutades lõpuks kasutajakogemust ja mainet otsingumootorites. Seega on selle koormuse tõhusal haldamisel võtmeroll ressursi pideva funktsionaalsuse tagamisel ja külastajatele juurdepääsetavuse suurendamisel.