Servera slodzes samazināšana

Šajā rakstā mēs iedziļināsimies, kāpēc palielinās servera slodze, un apspriedīsim dažādus veidus, kā optimizēt augstas slodzes procesus. Īpaša uzmanība tiks pievērsta koda optimizācijai Apache/Nginx un MySQL, runāsim par kešatmiņu kā palīgrīku, kā arī apsvērsim iespējamos ārējos draudus, piemēram, DDOS uzbrukumus, un to novēršanas veidus.

Kāpēc notiek servera slodze

Pirms turpināt servera optimizāciju, ir jāveic rūpīga pašreizējās resursu slodzes analīze. Tas ietver CPU slodzes, RAM lietojuma, tīkla darbības un citu galveno parametru mērīšanu. Izpratne par dinamiku un maksimālo slodzi ļauj identificēt vājās vietas un optimizēt resursu sadali, tādējādi palielinot servera infrastruktūras stabilitāti un veiktspēju.

Sākotnējai augstas servera slodzes problēmu novēršanai iesakām veikt vispārēju servera diagnostiku . Ja ar to nepietiek, nepieciešama detalizētāka resursu analīze . Kā palīglīdzeklis var būt noderīga Linux servera žurnālu izpēte , jo vairumā gadījumu tieši tur atrodams problēmas avots.

Apache/Nginx servera optimizēšana

Paaugstināta servera slodze indeksēšanas dēļ

Palielināta slodze servera indeksēšanas dēļ var rasties, piemēram, ja meklētājprogrammas skenē lielu skaitu jūsu vietnes lapu. Tas var palielināt servera resursu izmantošanu un līdz ar to palēnināt vietnes veiktspēju. Cēloņa identificēšana ir samērā vienkārša; jums ir jāatver fails, kas atrodas šeit:

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

Ja meklētājprogrammas indeksē, lietotājs redzēs šāda veida ierakstus:

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

Kā pirmo risinājumu slodzes samazināšanai varat izmantot meta tagu "noindex" un "nofollow" iestatīšanu lapās, kuras nav nepieciešams indeksēt. Otrais risinājums ir .htaccess fails, kurā jāpievieno ieraksti, kas atbilst konkrētām meklētājprogrammām, piemēram, lai paslēptu no Yandex un Google:

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

Līdzīgi labojumi jāveic arī citām meklētājprogrammām. Jāatzīmē, ka .htaccess iespējas neaprobežojas tikai ar indeksēšanas bloķēšanu. Iesakām iepazīties ar tā galvenajām funkcijām rakstā.

Kešatmiņas iestatījumu izmantošana

Nepareizi kešatmiņas iestatījumi serverī var izraisīt arī lielu slodzi. Lai optimizētu šo parametru, atbilstošas ​​izmaiņas jāveic konfigurācijas failos vai .htaccess failā . Apache gadījumā vēlams izmantot pēdējo opciju, bet Nginx gadījumā — pirmo.

Apache serverī ir jāatver .htacess fails un jāievieto šāds kods:

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

Pēc tam iespējojiet moduli Expires , izmantojot komandu:

sudo a2enmod expires

Pēc tam restartējiet tīmekļa serveri:

sudo service apache2 restart

Un aktivizējiet moduli, norādot:

ExpiresActive On

Nginx serverī pietiek pievienot konfigurācijas failam šādu kodu:

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

Un veiciet pakalpojuma atkārtotu ielādi:

sudo service nginx restart

Ņemiet vērā, ka ar šiem iestatījumiem tiks apietas direktīvas “Allow” un “Deny” .

Izmantojot datu saspiešanu

Datu saspiešanas iespējošana, izmantojot Gzip Apache un Nginx tīmekļa serveros, palīdz samazināt starp serveri un klientu pārsūtīto datu apjomu, kas uzlabo veiktspēju un samazina tīmekļa lapas ielādes laiku.

Lai iespējotu Gzip pakalpojumā Apache , jāaktivizē modulis mod_deflate :

sudo a2enmod deflate

Pēc tam restartējiet tīmekļa serveri:

sudo service apache2 restart

Visbeidzot, konfigurācijas failam vai .htaccess pievienojiet šādu bloku:

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

Šī konfigurācija nodrošina noteiktu failu tipu saspiešanu un atspējo to attēliem.

Nginx gadījumā konfigurācija notiek konfigurācijas faila http blokā. Ir jāpievieno šāds kods:

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;

Līdzīgi kā Apache , šeit tiek iestatīti saspiešanas parametri noteiktiem failu tipiem. Pēc izmaiņu veikšanas jebkurā no tīmekļa serveriem ir nepieciešama pakalpojuma atkārtota ielāde:

sudo service apache2 restart

Or

sudo service nginx restart

DDOS uzbrukums serverim

DDoS uzbrukuma rezultātā var rasties liela servera noslodze. DDoS uzbrukuma esamību var identificēt, uzraugot pēkšņu trafika pieaugumu, neparastus pieprasījumus un servera veiktspējas kritumus. Pārskatot žurnālus atkārtotiem pieprasījumiem no vienas IP adreses vai portu skenēšanas, var norādīt arī uz iespējamu DDoS uzbrukumu. Ir daudz aizsardzības pasākumu, bet mēs apspriedīsim tikai pamatus.

Izmantojot CDN (satura piegādes tīklu) . CDN var kalpot kā starpnieks starp jūsu tīmekļa serveri un lietotājiem, sadalot datplūsmu un kešatmiņā saglabājot saturu, lai mazinātu DDoS uzbrukuma ietekmi. CDN var būt arī iebūvēti DDoS aizsardzības mehānismi, tostarp slodzes sadale un datplūsmas filtrēšana.

Ugunsmūru un ielaušanās atklāšanas sistēmu (IDS/IPS) konfigurēšana . Ugunsmūrus var konfigurēt, lai filtrētu datplūsmu, pamatojoties uz dažādiem kritērijiem, piemēram, IP adresēm un portiem. IDS/IPS var noteikt neparastu datplūsmas darbību un bloķēt aizdomīgus savienojumus. Šie rīki var efektīvi izsekot un bloķēt potenciāli ļaunprātīgu datplūsmu.

Apache un Nginx tīmekļa serveru konfigurēšana, lai mazinātu DDoS uzbrukumu ietekmi.

Kā risinājumu Apache serverim mēs iespējojam mod_evasive moduli. Lai to izdarītu, noņemiet komentāru vai pievienojiet šādu rindu konfigurācijas failā httpd.conf vai apache2.conf :

LoadModule evasive20_module modules/mod_evasive.so

Tajā pašā failā jums jāpievieno iestatījumu bloks:

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

Līdzīgi mēs aktivizējam moduli mod_ratelimit :

LoadModule ratelimit_module modules/mod_ratelimit.so

Un pievienojiet konfigurāciju:

<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 konfigurācija ir līdzīga Apache konfigurācijai . Nginx.conf konfigurācijas failā jāizmanto šādas direktīvas:

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ēc izmaiņu veikšanas katrā pakalpojumā tie ir atkārtoti jāielādē:

sudo systemctl restart apache2

Vai:

sudo systemctl restart nginx

Šie piemēri nodrošina tikai pamata konfigurāciju, ko var tālāk pielāgot atkarībā no īpašām prasībām un uzbrukumu rakstura.

MySQL vaicājumu optimizēšana

MySQL datubāzes vaicājumu optimizāciju tīmekļa serverī var panākt dažādos veidos, un viens no tiem ir pareiza konfigurācijas faila konfigurēšana. Parasti šī faila nosaukums ir my.cnf vai my.ini , un tas atrodas direktorijā /etc/ vai /etc/mysql/ . Jums tas ir jāatver un jāveic šādas izmaiņas:

[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

Apsvērsim arī papildu ieteikumus, kas var atvieglot mijiedarbību ar servera datu bāzi:

1. Izmantot PASKAIDROJIET komandu pirms SQL vaicājuma, lai analizētu tā izpildi. Tas ļauj iegūt vaicājuma izpildes plānu un noteikt, kuri indeksi tiek izmantoti, kuras tabulas tiek skenētas utt.
2. Indeksi paātrina datu meklēšanu, tāpēc pareizi izstrādāti indeksi var ievērojami uzlabot vaicājuma veiktspēju. Pievērsiet uzmanību kolonnām, kuras bieži tiek izmantotas KUR or PIEVIENOJIES apstākļiem.
3. Izvairieties no lietošanas SELECT *. Norādiet tikai tās kolonnas, kas patiešām ir nepieciešamas jūsu vaicājumam, nevis atlasiet visas tabulas kolonnas.
4. Izvairieties no funkciju izmantošanas KUR nosacījumiem. Izmantojot funkcijas (piemēram, ZEMĀK, UPPER, LEFT, TIESĪBAS) iekšā KUR apstākļi var padarīt indeksus nederīgus. Centieties izvairīties no to tiešas izmantošanas apstākļos.
5. lietošana INNER JOIN ja iespējams, jo tas parasti ir efektīvāks. Nodrošiniet arī, lai attiecīgajām pievienošanas kolonnām būtu indeksi.
6. lietošana LIMIT lai ierobežotu atgriezto rindu skaitu, ja nepieciešams iegūt tikai noteiktu rezultātu skaitu.
7. Apsveriet vaicājumu rezultātu saglabāšanu kešatmiņā, īpaši, ja tie mainās reti, lai samazinātu servera slodzi.

Pasta serveris rada lielu slodzi serverī

Šajā sadaļā mēs izpētīsim, kā noteikt, ka pasta serverim ir liela slodze, un kādus pasākumus var veikt, lai optimizētu tā darbību, tostarp pārbaudot ziņojumu rindu un konfigurējot servera parametrus. Sāciet ar ziņojumu rindas pārbaudi. mailq utilīta var palīdzēt šajā jautājumā; lai to aktivizētu, terminālī ievadiet atbilstošo komandu:

mailq

Tiks parādīts rindā esošo ziņojumu saraksts, ja tāds ir. Katrs ziņojums tiks parādīts ar tā unikālo identifikatoru un informāciju par sūtīšanas statusu. Līdzīgu rezultātu var iegūt, pārskatot pasta klienta žurnālus.

Vairumā gadījumu liela slodze notiek servera kompromitēšanas gadījumā, kad tas sāk sūtīt surogātpastu. Tomēr, ja pēc pārbaudes administrators ir pārliecināts, ka serverim nav uzbrukts no ārpuses un lietotāji nav ignorējuši surogātpastu, ir pienācis laiks pāriet uz pasta servera optimizāciju. Tālāk ir norādītas darbības, kas palīdzēs:

1. Pārliecinieties, vai jūsu domēna DNS ieraksti ir pareizi konfigurēti, tostarp SPF, dkim paplašinājums, un dMarc ierakstus, lai uzlabotu pasta piegādi un aizsargātu pret surogātpastu. Pareizo parametru konfigurāciju var atrast rakstā par pasta servera diagnostika.
2. Pārbaudiet tīkla iestatījumus, tostarp ugunsmūra konfigurāciju un maršrutēšanas noteikumus, lai izvairītos no bloķēšanas un paātrinātu pasta piegādi.
3. Konfigurējiet ziņojumu rindas parametrus atbilstoši servera slodzei. Tas var ietvert maksimālā rindas lieluma un taimautu iestatīšanu.
4. Apsveriet risinājumus, par kuriem mēs runājām iepriekš šajā rakstā. Periodiski optimizējiet pasta servera datu bāzi, lai uzlabotu veiktspēju, izmantojiet kešatmiņas mehānismus, lai paātrinātu datu meklēšanu un apstrādi, piemēram, DNS vaicājumus.
5. Ja pasta serveris joprojām regulāri saskaras ar lielu slodzi, apsveriet mērogošanas iespējas, piemēram, pasta serveru kopas vai mākoņa risinājumu izmantošanu.

Secinājumi

Palielināta servera noslodze tieši ietekmē vietņu ielādes ātrumu, galu galā ietekmējot lietotāju pieredzi un reputāciju meklētājprogrammās. Tādējādi šīs slodzes efektīvai pārvaldībai ir galvenā loma nepārtrauktas resursa funkcionalitātes nodrošināšanā un tā pieejamības palielināšanā apmeklētājiem.