Baza znanja Jednostavna uputstva za rad sa uslugom Profitserver
glavni Baza znanja Smanjenje opterećenja servera

Smanjenje opterećenja servera


U ovom članku ćemo proučiti zašto dolazi do povećanog opterećenja servera i razmotriti različite načine optimizacije procesa visokog opterećenja. Posebna pažnja će biti posvećena optimizaciji koda u Apache/Nginx i MySQL, govorićemo o keširanju kao pomoćnom alatu, a takođe ćemo razmotriti moguće spoljne pretnje, kao što su DDOS napadi, i načine za njihovo sprečavanje.

Zašto dolazi do opterećenja servera

Prije nego što pređete na optimizaciju servera, potrebno je izvršiti detaljnu analizu trenutnog opterećenja resursa. Ovo uključuje mjerenje opterećenja CPU-a, korištenje RAM-a, mrežne aktivnosti i druge ključne parametre. Razumijevanje dinamike i vršnog opterećenja omogućava identifikaciju uskih grla i optimizaciju alokacije resursa, čime se povećava stabilnost i performanse serverske infrastrukture.

Za početno rješavanje problema velikog opterećenja servera, preporučujemo da izvršite a opšta dijagnostika servera. Ako je to nedovoljno, detaljnije analiza resursa je neophodno. Kao pomoćno sredstvo, istraživanje dnevnike Linuxa server može biti od pomoći, jer se tu u većini slučajeva nalazi izvor problema.

Optimizacija Apache/Nginx servera

Povećano opterećenje servera zbog indeksiranja

Do povećanog opterećenja zbog indeksiranja na serveru može doći, na primjer, kada pretraživači skeniraju veliki broj stranica na vašoj web stranici. To može dovesti do povećane upotrebe serverskih resursa i, posljedično, usporiti performanse stranice. Identifikacija uzroka je relativno jednostavna; potrebno je da otvorite fajl koji se nalazi na:

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

Kada ga pretraživači indeksiraju, korisnik će vidjeti unose sljedeće prirode:

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

Kao prvo rješenje za smanjenje opterećenja, možete koristiti postavljanje meta oznaka "noindex" i "nofollow" na stranicama koje ne treba indeksirati. Drugo rješenje je .htaccess datoteku, gdje je potrebno dodati unose koji odgovaraju određenim pretraživačima, na primjer, da se sakriju od Yandexa i Googlea:

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

Slično, potrebno je izvršiti izmjene i za druge pretraživače. Treba napomenuti da mogućnosti .htaccess-a nisu ograničene samo na blokiranje indeksiranja. Preporučujemo da se bolje upoznate sa njegovim glavnim karakteristikama u članak.

Korištenje postavki keširanja

Neispravne postavke keširanja na serveru također mogu dovesti do velikog opterećenja. Za optimizaciju ovog parametra potrebno je izvršiti odgovarajuće promjene u konfiguracijskim datotekama ili .htaccess. U slučaju Apachea, druga opcija je poželjnija, za Nginx – prva.

Na an apaš server, potrebno je da otvorite .htacess datoteku i ubacite sljedeći kod:

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

Zatim omogućite ističe modul koristeći naredbu:

sudo a2enmod expires

Nakon toga ponovo pokrenite web server:

sudo service apache2 restart

I aktivirajte modul navodeći:

ExpiresActive On

Na Nginx serveru, dovoljno je dodati sljedeći kod u konfiguracijski fajl:

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

I izvršite ponovno učitavanje usluge:

sudo service nginx restart

Imajte na umu da sa ovim postavkama, dopustiti i Odbij direktive će biti zaobiđene.

Korištenje kompresije podataka

Omogućavanje kompresije podataka pomoću Gzip na Apache i Nginx web serverima pomaže u smanjenju količine podataka koji se prenose između servera i klijenta, što poboljšava performanse i smanjuje vrijeme učitavanja web stranice.

Kako bi se omogućilo Gzip on apaš, potrebno je da aktivirate mod_deflate modul:

sudo a2enmod deflate

Zatim ponovo pokrenite web server:

sudo service apache2 restart

I na kraju, dodajte sljedeći blok u konfiguracijski fajl ili .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>

Ova konfiguracija omogućava kompresiju za određene tipove datoteka i onemogućuje je za slike.

U slucaju da Nginx, konfiguracija se događa u http blok konfiguracijske datoteke. Potrebno je dodati sljedeći 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;

Slicno apaš, ovdje se postavljaju parametri kompresije za određene tipove datoteka. Nakon izmjene bilo kojeg od web servera, potrebno je ponovno učitavanje usluge:

sudo service apache2 restart

Or

sudo service nginx restart

DDOS napad na server

Visoko opterećenje servera može nastati kao rezultat DDoS napada. Identifikacija prisustva DDoS napada može se obaviti praćenjem naglog povećanja prometa, abnormalnih zahtjeva i pada performansi servera. Pregledavanje dnevnika za ponovljene zahtjeve s jedne IP adrese ili skeniranje portova također može ukazivati ​​na mogući DDoS napad. Postoje mnoge mjere zaštite, ali ćemo razgovarati samo o osnovnim.

Korištenje CDN (mreža za isporuku sadržaja). CDN može poslužiti kao posrednik između vašeg web servera i korisnika, distribuirajući promet i keširajući sadržaj kako bi se ublažio utjecaj DDoS napada. CDN-ovi takođe mogu imati ugrađene DDoS zaštitne mehanizme, uključujući distribuciju opterećenja i filtriranje saobraćaja.

Konfiguriranje zaštitnog zida i sistema za detekciju upada (IDS/IPS). Vatrozidovi se mogu konfigurisati da filtriraju saobraćaj na osnovu različitih kriterijuma, kao što su IP adrese i portovi. IDS/IPS može otkriti abnormalno ponašanje u prometu i blokirati sumnjive veze. Ovi alati mogu biti efikasni u praćenju i blokiranju potencijalno zlonamjernog prometa.

Konfiguriranje Apache i Nginx web servera za ublažavanje utjecaja DDoS napada.

Kao rješenje za Apache, omogućavamo mod_evasive modul. Da biste to učinili, uklonite komentar ili dodajte sljedeći red u httpd.conf or apache2.conf konfiguraciona datoteka:

LoadModule evasive20_module modules/mod_evasive.so

U istoj datoteci morate dodati blok postavki:

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

Slično, aktiviramo mod_ratelimit modul:

LoadModule ratelimit_module modules/mod_ratelimit.so

I dodajte konfiguraciju:

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

Konfiguracija za Nginx Slično je apaš. U nginx.conf konfiguracijske datoteke, potrebno je koristiti sljedeće direktive:

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;

        ...
    }
}

Nakon izmjena svake od usluga, potrebno ih je ponovo učitati:

sudo systemctl restart apache2

Ili:

sudo systemctl restart nginx

Ovi primjeri pružaju samo osnovnu konfiguraciju, koja se može dalje prilagođavati ovisno o specifičnim zahtjevima i prirodi napada.

Optimizacija MySQL upita

Optimizacija upita MySQL baze podataka na web serveru može se postići na različite načine, a jedan od njih je ispravna konfiguracija konfiguracijskog fajla. Obično je ova datoteka imenovana my.cnf or my.ini i nalazi se u / etc / or /etc/mysql/ imenik. Morate ga otvoriti i izvršiti sljedeće promjene:

[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

Razmotrimo i dodatne preporuke koje mogu olakšati interakciju sa serverskom bazom podataka:

  1. Koristiti OBRAZLOŽITE naredba prije SQL upita za analizu njegovog izvršenja. Ovo vam omogućava da dobijete plan izvršenja za upit i odredite koji se indeksi koriste, koje tabele se skeniraju itd.
  2. Indeksi ubrzavaju pretragu podataka, tako da pravilno dizajnirani indeksi mogu značajno poboljšati performanse upita. Obratite pažnju na kolone koje se često koriste u GDJE or JOIN uvjetima.
  3. Izbjegavajte upotrebu ODABIR *. Navedite samo one kolone koje su zaista neophodne za vaš upit, umjesto da odaberete sve kolone u tabeli.
  4. Izbjegavajte korištenje funkcija u GDJE uslovima. Korištenje funkcija (npr NIŽE, GORNJI, LEVO, PRAVO) in GDJE uslovi mogu učiniti indekse beskorisnim. Pokušajte izbjeći njihovu direktnu upotrebu u uslovima.
  5. upotreba UNUTAR PRIDRUŽITE SE gdje je to moguće, jer je obično efikasnije. Također, osigurajte da odgovarajuće kolone za spajanje imaju indekse.
  6. upotreba LIMIT da ograničite broj vraćenih redova ako trebate dobiti samo određeni broj rezultata.
  7. Razmislite o keširanju rezultata upita, posebno ako se rijetko mijenjaju, kako biste smanjili opterećenje servera.

Mail Server stvara veliko opterećenje na serveru

U ovom odeljku ćemo istražiti kako da utvrdimo da je server pošte pod velikim opterećenjem i koji koraci se mogu preduzeti da se optimizuje njegov rad, uključujući proveru reda poruka i konfigurisanje parametara servera. Počnite s provjerom reda poruka. The mailq uslužni program može pomoći u tome, da biste ga aktivirali, unesite odgovarajuću naredbu u terminal:

mailq

Ovo će prikazati listu poruka u redu čekanja, ako ih ima. Svaka poruka će biti prikazana sa svojim jedinstvenim identifikatorom i informacijama o statusu slanja. Sličan rezultat se može dobiti pregledom dnevnika mail klijenta.

U većini slučajeva, veliko opterećenje se javlja u slučaju kompromitacije servera kada počne da šalje neželjenu poštu. Međutim, ako je nakon provjere administrator siguran da server nije napadnut izvana i da korisnici ne zanemaruju neželjenu poštu, vrijeme je da se pređe na optimizaciju mail servera. Evo koraka koji će vam pomoći:

  1. Uvjerite se da su DNS zapisi vaše domene ispravno konfigurirani, uključujući zaštitni faktor, dkim ekstenzija, I DMARC ekstenzija evidencije za poboljšanje isporuke pošte i zaštitu od neželjene pošte. Ispravnu konfiguraciju parametara možete pronaći u članku o dijagnostika mail servera.
  2. Provjerite mrežne postavke, uključujući konfiguraciju zaštitnog zida i pravila rutiranja, kako biste izbjegli blokade i ubrzali isporuku pošte.
  3. Konfigurirajte parametre reda poruka prema opterećenju servera. Ovo može uključivati ​​postavljanje maksimalne veličine reda čekanja i vremenskih ograničenja.
  4. Razmotrite rješenja o kojima smo ranije govorili u ovom članku. Periodično optimizujte bazu podataka servera pošte da biste poboljšali performanse, koristite mehanizme keširanja da biste ubrzali pretragu i obradu podataka, kao što su DNS upiti.
  5. Ako se server e-pošte i dalje redovno susreće sa velikim opterećenjem, razmislite o opcijama skaliranja, kao što je korištenje klastera mail servera ili rješenja u oblaku.

zaključak

Povećano opterećenje servera direktno utječe na brzinu učitavanja web stranice, što u konačnici utiče na korisničko iskustvo i reputaciju u pretraživačima. Stoga, efikasno upravljanje ovim opterećenjem igra ključnu ulogu u osiguravanju kontinuirane funkcionalnosti resursa i povećanju njegove dostupnosti posjetiteljima.

❮ Prethodni članak Certbot: Instaliranje Let's Encrypt certifikata
Sljedeći članak ❯ Dijagnostika opterećenja servera

Pitajte nas za VPS

Uvek smo spremni da odgovorimo na vaša pitanja u bilo koje doba dana i noći.