Serverio apkrovos mažinimas

Šiame straipsnyje mes gilinsimės į tai, kodėl padidėja serverio apkrova, ir aptarsime įvairius būdus, kaip optimizuoti didelės apkrovos procesus. Ypatingas dėmesys bus skiriamas kodo optimizavimui Apache/Nginx ir MySQL, kalbėsime apie talpyklą kaip pagalbinį įrankį, taip pat apsvarstysime galimas išorines grėsmes, tokias kaip DDOS atakos, ir būdus joms užkirsti kelią.

Kodėl atsiranda serverio apkrova

Prieš pradedant serverio optimizavimą, būtina atlikti išsamią esamos išteklių apkrovos analizę. Tai apima procesoriaus apkrovos, RAM naudojimo, tinklo veiklos ir kitų pagrindinių parametrų matavimą. Dinamikos ir didžiausios apkrovos supratimas leidžia nustatyti kliūtis ir optimizuoti išteklių paskirstymą, taip padidinant serverio infrastruktūros stabilumą ir našumą.

Pradinei didelės serverio apkrovos trikčių diagnostikai rekomenduojame atlikti bendrąją serverio diagnostiką . Jei to nepakanka, būtina atlikti išsamesnę išteklių analizę . Kaip pagalbinė priemonė gali būti naudinga „Linux“ serverio žurnalų analizė , nes daugeliu atvejų būtent ten slypi problemos šaltinis.

„Apache“ / „Nginx“ serverio optimizavimas

Padidėjusi serverio apkrova dėl indeksavimo

Padidėjusi apkrova dėl indeksavimo serveryje gali atsirasti, pavyzdžiui, kai paieškos sistemos nuskaito daug jūsų svetainės puslapių. Dėl to gali padidėti serverio išteklių naudojimas ir, atitinkamai, sulėtėti svetainės veikimas. Priežastį nustatyti gana paprasta; reikia atidaryti failą, esantį adresu:

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

Kai indeksuoja paieškos sistemos, vartotojas matys tokio pobūdžio įrašus:

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

Kaip pirmąjį sprendimą apkrovai sumažinti, galite naudoti metažymų „noindex“ ir „nofollow“ nustatymą puslapiuose, kurių nereikia indeksuoti. Antrasis sprendimas yra .htaccess failas, kuriame reikia pridėti įrašus, atitinkančius konkrečias paieškos sistemas, pavyzdžiui, norint paslėpti nuo „Yandex“ ir „Google“:

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

Panašiai redagavimus reikia atlikti ir kitoms paieškos sistemoms. Reikėtų atkreipti dėmesį, kad .htaccess galimybės neapsiriboja vien indeksavimo blokavimu. Rekomenduojame išsamiau susipažinti su pagrindinėmis jo funkcijomis straipsnyje.

Talpyklos nustatymų naudojimas

Neteisingi serverio talpyklos nustatymai taip pat gali sukelti didelę apkrovą. Norint optimizuoti šį parametrą, reikia atlikti atitinkamus pakeitimus konfigūracijos failuose arba .htaccess faile . Apache atveju geriau rinktis pastarąjį variantą, o Nginx – pirmąjį.

„Apache“ serveryje reikia atidaryti .htacess failą ir įterpti šį kodą:

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

Tada įjunkite „Expires“ modulį naudodami komandą:

sudo a2enmod expires

Po to iš naujo paleiskite žiniatinklio serverį:

sudo service apache2 restart

Ir suaktyvinkite modulį nurodydami:

ExpiresActive On

„Nginx“ serveryje pakanka į konfigūracijos failą įtraukti šį kodą:

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

Ir atlikite paslaugos perkrovimą:

sudo service nginx restart

Atkreipkite dėmesį, kad naudojant šiuos nustatymus, „ Allow“ ir „Deny“ direktyvos bus apeitos.

Duomenų glaudinimo naudojimas

Duomenų glaudinimo naudojant „Gzip“ įjungimas „Apache“ ir „Nginx“ žiniatinklio serveriuose padeda sumažinti tarp serverio ir kliento perduodamų duomenų kiekį, o tai pagerina našumą ir sutrumpina tinklalapio įkėlimo laiką.

Norėdami įjungti „Gzip“ „Apache“ sistemoje , turite aktyvuoti „mod_deflate“ modulį:

sudo a2enmod deflate

Tada iš naujo paleiskite žiniatinklio serverį:

sudo service apache2 restart

Galiausiai pridėkite šį bloką prie konfigūracijos failo arba .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>

Ši konfigūracija įgalina tam tikrų tipų failų glaudinimą ir išjungia vaizdams.

„Nginx“ atveju konfigūracija atliekama konfigūracijos failo „http“ bloke. Reikia pridėti šį kodą:

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;

Panašiai kaip „Apache“ , čia nustatomi tam tikrų tipų failų glaudinimo parametrai. Atlikus pakeitimus bet kuriame žiniatinklio serveryje, reikia iš naujo įkelti paslaugą:

sudo service apache2 restart

Or

sudo service nginx restart

DDOS ataka serveryje

Didelė serverio apkrova gali atsirasti dėl DDoS atakos. DDoS atakos buvimą galima nustatyti stebint staigų srauto padidėjimą, neįprastas užklausas ir serverio našumo sumažėjimą. Žurnalų peržiūra dėl pakartotinių užklausų iš vieno IP adreso arba prievado nuskaitymo taip pat gali rodyti galimą DDoS ataką. Apsaugos priemonių yra daug, tačiau aptarsime tik pagrindus.

Naudojant CDN (turinio pristatymo tinklą) . CDN gali būti tarpininkas tarp jūsų žiniatinklio serverio ir naudotojų, paskirstydamas srautą ir kaupdamas turinį talpykloje, kad sušvelnintų DDoS atakos poveikį. CDN taip pat gali turėti integruotus DDoS apsaugos mechanizmus, įskaitant apkrovos paskirstymą ir srauto filtravimą.

Užkardų ir įsilaužimų aptikimo sistemų (IDS/IPS) konfigūravimas . Užkardas galima konfigūruoti taip, kad jos filtruotų srautą pagal įvairius kriterijus, pvz., IP adresus ir prievadus. IDS/IPS gali aptikti neįprastą srauto elgseną ir blokuoti įtartinus ryšius. Šios priemonės gali būti veiksmingos stebint ir blokuojant potencialiai kenkėjišką srautą.

„Apache“ ir „Nginx“ žiniatinklio serverių konfigūravimas, siekiant sumažinti DDoS atakų poveikį.

Kaip sprendimą „Apache“ serveriui, įjungiame „mod_evasive“ modulį. Norėdami tai padaryti, panaikinkite komentarą arba pridėkite šią eilutę konfigūracijos faile httpd.conf arba apache2.conf :

LoadModule evasive20_module modules/mod_evasive.so

Tame pačiame faile turite pridėti nustatymų bloką:

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

Panašiai aktyvuojame „mod_ratelimit“ modulį:

LoadModule ratelimit_module modules/mod_ratelimit.so

Ir pridėkite konfigūraciją:

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

„Nginx“ konfigūracija yra panaši į „Apache“ . „nginx.conf“ konfigūracijos faile reikia naudoti šias direktyvas:

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;

        ...
    }
}

Atlikus kiekvienos paslaugos pakeitimus, jas reikia įkelti iš naujo:

sudo systemctl restart apache2

arba:

sudo systemctl restart nginx

Šiuose pavyzdžiuose pateikiama tik pagrindinė konfigūracija, kurią galima toliau pritaikyti atsižvelgiant į konkrečius reikalavimus ir atakų pobūdį.

MySQL užklausų optimizavimas

„MySQL“ duomenų bazės užklausų optimizavimas žiniatinklio serveryje gali būti atliekamas įvairiais būdais, o vienas iš jų yra tinkama konfigūracijos failo konfigūracija. Paprastai šis failas vadinamas „my.cnf“ arba „my.ini“ ir yra kataloge /etc/ arba /etc/mysql/ . Jums reikia jį atidaryti ir atlikti šiuos pakeitimus:

[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

Taip pat apsvarstykime papildomas rekomendacijas, kurios gali palengvinti sąveiką su serverio duomenų baze:

1. Naudokite AIŠKINTI komandą prieš SQL užklausą, kad būtų galima analizuoti jos vykdymą. Tai leidžia gauti užklausos vykdymo planą ir nustatyti, kurie indeksai naudojami, kurios lentelės nuskaitomos ir pan.
2. Indeksai pagreitina duomenų paiešką, todėl tinkamai sukurti indeksai gali žymiai pagerinti užklausos našumą. Atkreipkite dėmesį į stulpelius, kurie dažnai naudojami KUR or PRISIJUNK sąlygos.
3. Venkite naudoti SELECT *. Užuot pasirinkę visus lentelės stulpelius, nurodykite tik tuos stulpelius, kurie tikrai reikalingi jūsų užklausai.
4. Venkite naudoti funkcijas KUR sąlygomis. Naudojant funkcijas (pvz ŽEMIAU, VIRŠUTINIS, LEFT, TEISĖ) in KUR dėl sąlygų indeksai gali būti nenaudingi. Stenkitės vengti tiesioginio jų naudojimo sąlygomis.
5. Paskirtis VIDINIS PRISIJUNGTI kur įmanoma, nes tai paprastai yra efektyvesnė. Taip pat įsitikinkite, kad atitinkamuose sujungimo stulpeliuose yra indeksai.
6. Paskirtis RIBINĖS apriboti grąžinamų eilučių skaičių, jei reikia gauti tik tam tikrą rezultatų skaičių.
7. Apsvarstykite galimybę išsaugoti užklausų rezultatus, ypač jei jie retai keičiasi, kad sumažintumėte serverio apkrovą.

Pašto serveris sukuria didelę serverio apkrovą

Šiame skyriuje nagrinėsime, kaip nustatyti, kad pašto serveris patiria didelę apkrovą, ir kokių veiksmų galima imtis siekiant optimizuoti jo veikimą, įskaitant pranešimų eilės patikrinimą ir serverio parametrų konfigūravimą. Pradėkite nuo pranešimų eilės patikrinimo. Tam gali padėti „mailq“ programa. Norėdami ją suaktyvinti, terminale įveskite atitinkamą komandą:

mailq

Bus rodomas eilėje esančių pranešimų sąrašas, jei tokių yra. Kiekvienas pranešimas bus rodomas su unikaliu identifikatoriumi ir informacija apie siuntimo būseną. Panašų rezultatą galima gauti peržiūrėjus pašto programos žurnalus.

Daugeliu atvejų didelė apkrova atsiranda, kai serveris pažeidžiamas, kai jis pradeda siųsti šlamštą. Tačiau jei patikrinęs administratorius įsitikinęs, kad serveris nebuvo užpultas iš išorės, o vartotojai neapleidžia šiukšlių, laikas pereiti prie pašto serverio optimizavimo. Štai žingsniai, kurie padės:

1. Įsitikinkite, kad domeno DNS įrašai yra tinkamai sukonfigūruoti, įskaitant SPF, dkim plėtinysir DMARC plėtinys įrašus, kad pagerintų laiškų pristatymą ir apsaugotų nuo šiukšlių. Teisingą parametrų konfigūraciją rasite straipsnyje pašto serverio diagnostika.
2. Patikrinkite tinklo nustatymus, įskaitant ugniasienės konfigūraciją ir maršruto taisykles, kad išvengtumėte blokavimų ir pagreitintumėte laiškų pristatymą.
3. Konfigūruokite pranešimų eilės parametrus pagal serverio apkrovą. Tai gali apimti didžiausio eilės dydžio ir skirtojo laiko nustatymą.
4. Apsvarstykite sprendimus, kuriuos aptarėme šiame straipsnyje anksčiau. Periodiškai optimizuokite pašto serverio duomenų bazę, kad pagerintumėte našumą, naudokite talpyklos mechanizmus, kad pagreitintumėte duomenų paiešką ir apdorojimą, pvz., DNS užklausas.
5. Jei pašto serveris vis tiek reguliariai susiduria su didele apkrova, apsvarstykite mastelio keitimo parinktis, pvz., pašto serverių grupės arba debesies sprendimų naudojimą.

Išvada

Padidėjusi serverio apkrova daro tiesioginę įtaką svetainės įkėlimo greičiui, galiausiai paveikiant vartotojų patirtį ir reputaciją paieškos sistemose. Taigi efektyvus šios apkrovos valdymas vaidina pagrindinį vaidmenį užtikrinant nuolatinį resurso funkcionalumą ir didinant jo prieinamumą lankytojams.