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 mēs iesakām veikt a vispārējā servera diagnostika. Ja tas nav pietiekami, sīkāk resursu analīze ir nepieciešams. Kā palīgrīku, izpētot Linux žurnāli serveris var būt noderīgs, jo šeit vairumā gadījumu tiek atrasts 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 metatagu iestatījumu "noindex" un "nofollow" lapās, kuras nav jāindeksē. Otrais risinājums ir Htaccess failu, kurā ir jāpievieno ieraksti, kas atbilst noteiktā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

Tāpat ir jāveic labojumi citām meklētājprogrammām. Jāpiebilst, ka .htaccess iespējas neaprobežojas tikai ar indeksēšanas bloķēšanu. Mēs iesakām iepazīties ar tā galvenajām funkcijām vietnē raksts.

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, ir jāveic atbilstošas ​​izmaiņas konfigurācijas failos vai Htaccess. Apache gadījumā priekšroka dodama pēdējam variantam, bet Nginx – pirmajam.

Uz a Apache serveri, jums ir jāatver .htacess failu un ievietojiet šādu kodu:

<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 beidzas modulis, 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

Gada Nginx serveri, konfigurācijas failam ir pietiekami pievienot šā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 Atļaut un Noliegt direktīvas tiks apietas.

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 lapu ielādes laiku.

Lai iespējotu Gzip on Apache, jums ir jāaktivizē mod_deflate modulis:

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.

Gadījumā, ja Nginx, konfigurācija notiek http konfigurācijas faila bloks. 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īgs Apache, šeit ir iestatīti saspiešanas parametri noteikta veida failiem. Pēc izmaiņu veikšanas jebkurā tīmekļa serverī 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.

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

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

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

Kā risinājumu Apache mēs iespējojam mod_evasive modulis. Lai to izdarītu, atceliet komentāru vai pievienojiet tālāk norādīto rindiņu httpd.conf or apache2.conf konfigurācijas fails:

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 mod_ratelimit modulis:

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>

Konfigurācija priekš Nginx ir līdzīgs Apache. Iekš nginx.conf konfigurācijas failu, ir 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 datu bāzes vaicājumu optimizēšanu tīmekļa serverī var panākt dažādos veidos, un viens no tiem ir pareiza konfigurācijas faila konfigurācija. Parasti šim failam ir nosaukums my.cnf or my.ini un atrodas / etc / or /etc/mysql/ direktoriju. 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, vai pasta serveris ir ļoti noslogots, un kādas darbības var veikt, lai optimizētu tā darbību, tostarp pārbaudīt ziņojumu rindu un konfigurēt servera parametrus. Sāciet ar ziņojumu rindas pārbaudi. The mailq utilīta var palīdzēt ar to, 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.