Сервер жүктемесін азайту

Бұл мақалада біз сервер жүктемесінің жоғарылауының себебін қарастырамыз және жоғары жүктеме процестерін оңтайландырудың әртүрлі жолдарын талқылаймыз. Apache/Nginx және MySQL-де кодты оңтайландыруға ерекше назар аударылады, біз көмекші құрал ретінде кэштеу туралы сөйлесеміз, сонымен қатар DDOS шабуылдары сияқты ықтимал сыртқы қауіптерді және олардың алдын алу жолдарын қарастырамыз.

Неліктен сервер жүктемесі пайда болады

Серверді оңтайландыруға кіріспес бұрын, ресурстарға ағымдағы жүктемені мұқият талдау қажет. Бұған CPU жүктемесін, ЖЖҚ пайдалануын, желі белсенділігін және басқа негізгі параметрлерді өлшеу кіреді. Динамика мен ең жоғары жүктемені түсіну кедергілерді анықтауға және ресурстарды бөлуді оңтайландыруға мүмкіндік береді, осылайша сервер инфрақұрылымының тұрақтылығы мен өнімділігін арттырады.

Жоғары сервер жүктемесінің бастапқы ақаулықтарын жою үшін a жалпы сервер диагностикасы. Бұл жеткіліксіз болса, толығырақ ресурстарды талдау қажет. Көмекші құрал ретінде зерттеу Linux журналдары сервер пайдалы болуы мүмкін, себебі мәселенің көзі көп жағдайда осы жерден табылады.

Apache/Nginx серверін оңтайландыру

Индекстеуге байланысты сервер жүктемесінің артуы

Серверде индекстеуге байланысты жүктеменің артуы, мысалы, іздеу жүйелері сайтыңыздағы көптеген беттерді сканерлеген кезде орын алуы мүмкін. Бұл сервер ресурстарын пайдаланудың артуына және, тиісінше, сайттың жұмысын баяулатуы мүмкін. Себебін анықтау салыстырмалы түрде қарапайым; мына жерде орналасқан файлды ашу керек:

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

Іздеу жүйелері арқылы индекстелген кезде пайдаланушы келесі сипаттағы жазбаларды көреді:

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

Жүктемені азайтудың бірінші шешімі ретінде мета тегтер параметрін пайдалануға болады «жоқ индекс» және "nofollow" индекстеуді қажет етпейтін беттерде. Екінші шешім - бұл .htaccess файл, мұнда нақты іздеу жүйелеріне сәйкес жазбаларды қосу қажет, мысалы, Яндекс пен Google-дан жасыру үшін:

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

Сол сияқты, басқа іздеу жүйелеріне де түзетулер енгізу қажет. Айта кету керек, .htaccess мүмкіндіктері тек индекстеуді блоктаумен шектелмейді. Оның негізгі мүмкіндіктерімен толығырақ танысуды ұсынамыз мақала.

Кэштеу параметрлерін пайдалану

Сервердегі дұрыс емес кэштеу параметрлері де жоғары жүктемеге әкелуі мүмкін. Бұл параметрді оңтайландыру үшін конфигурация файлдарында немесе .htaccess. Apache жағдайында соңғы нұсқа қолайлы, Nginx үшін – біріншісі.

Бірде Apache серверді ашу керек .htacess файлды және келесі кодты енгізіңіз:

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

Содан кейін қосыңыз Мерзімі аяқталады пәрменді пайдаланып модуль:

sudo a2enmod expires

Осыдан кейін веб-серверді қайта іске қосыңыз:

sudo service apache2 restart

Және мыналарды көрсету арқылы модульді іске қосыңыз:

ExpiresActive On

Үстінде Nginx серверде конфигурация файлына келесі кодты қосу жеткілікті:

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

Және қызметті қайта жүктеуді орындаңыз:

sudo service nginx restart

Назар аударыңыз, бұл параметрлермен бірге рұқсат ету және Қабылдамау директивалар айналып өтеді.

Деректерді қысуды пайдалану

көмегімен деректерді қысуды қосу Gzip Apache және Nginx веб-серверлерінде сервер мен клиент арасында жіберілетін деректер көлемін азайтуға көмектеседі, бұл өнімділікті жақсартады және веб-беттің жүктелу уақытын азайтады.

Қосу Gzip on Apache, белсендіру керек mod_deflate модуль:

sudo a2enmod deflate

Содан кейін веб-серверді қайта іске қосыңыз:

sudo service apache2 restart

Соңында конфигурация файлына немесе .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>

Бұл конфигурация файлдардың белгілі бір түрлері үшін қысуды қосады және кескіндер үшін оны өшіреді.

Жағдайда Nginx, конфигурацияда орын алады HTTP конфигурация файлының блогы. Келесі кодты қосу керек:

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;

Ұқсас Apache, мұнда файлдардың белгілі бір түрлері үшін қысу параметрлері орнатылады. Кез келген веб-серверге өзгертулер енгізілгеннен кейін қызметті қайта жүктеу қажет:

sudo service apache2 restart

Or

sudo service nginx restart

Серверге DDOS шабуылы

Жоғары сервер жүктемесі DDoS шабуылының нәтижесінде пайда болуы мүмкін. DDoS шабуылының болуын анықтау трафиктің кенеттен өсуін, қалыптан тыс сұрауларды және сервер өнімділігінің төмендеуін бақылау арқылы жүзеге асырылуы мүмкін. Бір IP мекенжайынан немесе портты сканерлеуден қайталанатын сұрауларға арналған журналдарды қарау ықтимал DDoS шабуылын көрсетуі мүмкін. Көптеген қорғаныс шаралары бар, бірақ біз тек негізгілерді талқылаймыз.

CDN (Content Delivery Network) пайдалану. CDN DDoS шабуылының әсерін азайту үшін трафикті таратып және мазмұнды кэштей отырып, веб-серверіңіз бен пайдаланушылар арасында делдал ретінде қызмет ете алады. CDN-де жүктемені бөлу және трафикті сүзуді қоса алғанда, кірістірілген DDoS қорғау механизмдері болуы мүмкін.

Брандмауэрлерді және басып кіруді анықтау жүйелерін конфигурациялау (IDS/IPS). Брандмауэрлерді IP мекенжайлары мен порттар сияқты әртүрлі критерийлерге негізделген трафикті сүзу үшін конфигурациялауға болады. IDS/IPS әдеттен тыс трафик әрекетін анықтап, күдікті қосылымдарды блоктай алады. Бұл құралдар ықтимал зиянды трафикті бақылауда және бұғаттауда тиімді болуы мүмкін.

DDoS шабуылдарының әсерін азайту үшін Apache және Nginx веб-серверлерін конфигурациялау.

Apache үшін шешім ретінде біз оны қосамыз mod_evasive модуль. Ол үшін түсініктемені алып тастаңыз немесе келесі жолды қосыңыз httpd.conf or apache2.conf конфигурациялық файл:

LoadModule evasive20_module modules/mod_evasive.so

Сол файлға параметрлер блогын қосу керек:

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

Сол сияқты біз белсендіреміз mod_ratelimit модуль:

LoadModule ratelimit_module modules/mod_ratelimit.so

Және конфигурацияны қосыңыз:

<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 ұқсас Apache. Ішінде nginx.conf конфигурация файлында келесі директиваларды пайдалану қажет:

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;

        ...
    }
}

Қызметтердің әрқайсысына өзгерістер енгізгеннен кейін оларды қайта жүктеу қажет:

sudo systemctl restart apache2

Немесе:

sudo systemctl restart nginx

Бұл мысалдар нақты талаптарға және шабуылдардың сипатына байланысты әрі қарай бейімделуі мүмкін негізгі конфигурацияны ғана қамтамасыз етеді.

MySQL сұрауларын оңтайландыру

Веб-серверде MySQL дерекқор сұрауларын оңтайландыруға әртүрлі жолдармен қол жеткізуге болады, олардың бірі конфигурация файлының дұрыс конфигурациясы болып табылады. Әдетте, бұл файл аталды my.cnf or my.ini және орналасқан / etc / or /etc/mysql/ каталог. Оны ашып, келесі өзгерістерді енгізу керек:

[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

Сондай-ақ сервер дерекқорымен өзара әрекеттесуді жеңілдететін қосымша ұсыныстарды қарастырайық:

1. пайдаланыңыз Түсініктеме оның орындалуын талдау үшін SQL сұрауының алдындағы пәрмен. Бұл сұраудың орындалу жоспарын алуға және қандай индекстер пайдаланылатынын, қандай кестелер сканерленгенін және т.б. анықтауға мүмкіндік береді.
2. Индекстер деректерді іздеуді жылдамдатады, сондықтан дұрыс құрастырылған индекстер сұрау өнімділігін айтарлықтай жақсартады. Жиі қолданылатын бағандарға назар аударыңыз ҚАЙДА or ЖОЛ шарттары.
3. Пайдаланудан аулақ болыңыз ТАҢДАУ *. Кестедегі барлық бағандарды таңдаудың орнына сұрауыңызға шынымен қажет бағандарды ғана көрсетіңіз.
4. ішінде функцияларды пайдаланудан аулақ болыңыз ҚАЙДА шарттар. Функцияларды пайдалану (мысалы ТӨМЕН, ЖҰМЫС, СОЛ, RIGHT) ҚАЙДА жағдайлар индекстерді пайдасыз етуі мүмкін. Жағдайларда оларды тікелей пайдаланудан аулақ болуға тырысыңыз.
5. пайдалану ІШКІ КІРУ мүмкін болса, өйткені ол әдетте тиімдірек. Сондай-ақ, қосылуға арналған сәйкес бағандарда индекстер бар екеніне көз жеткізіңіз.
6. пайдалану LIMIT нәтижелердің белгілі бір санын ғана алу қажет болса, қайтарылған жолдардың санын шектеу үшін.
7. Сұрау нәтижелерін кэштеуді қарастырыңыз, әсіресе олар сирек өзгерсе, сервер жүктемесін азайту үшін.

Пошта сервері серверде жоғары жүктеме жасайды

Бұл бөлімде біз пошта сервері жоғары жүктемені бастан өткеріп жатқанын қалай анықтау керектігін және оның жұмысын оңтайландыру үшін қандай қадамдар жасауға болатынын, соның ішінде хабарлама кезегін тексеру және сервер параметрлерін конфигурациялауды қарастырамыз. Хабарлама кезегін тексеруден бастаңыз. The mailq утилита осыған көмектесе алады, оны іске қосу үшін терминалға сәйкес пәрменді енгізіңіз:

mailq

Бұл, егер бар болса, кезекте тұрған хабарлардың тізімін көрсетеді. Әрбір хабарлама өзінің бірегей идентификаторымен және жіберу күйі туралы ақпаратпен көрсетіледі. Ұқсас нәтижені пошта клиентінің журналдарын қарап шығу арқылы алуға болады.

Көп жағдайда сервер спам жібере бастағанда бұзылған жағдайда жоғары жүктеме орын алады. Дегенмен, егер әкімші тексергеннен кейін серверге сырттан шабуыл жасалмағанына сенімді болса және пайдаланушылар спамды елемейтін болса, пошта серверін оңтайландыруға көшудің уақыты келді. Мұнда көмектесетін қадамдар:

1. Доменіңіздің DNS жазбалары дұрыс конфигурацияланғанына көз жеткізіңіз, соның ішінде SPF, ДКИМ, және DMARC кеңейтімі поштаны жеткізуді жақсарту және спамнан қорғау үшін жазбалар. Параметрлердің дұрыс конфигурациясын мақалада табуға болады пошта серверінің диагностикасы.
2. Блоктарды болдырмау және поштаны жеткізуді жылдамдату үшін желі параметрлерін, соның ішінде брандмауэр конфигурациясын және маршруттау ережелерін тексеріңіз.
3. Хабарлама кезегі параметрлерін сервер жүктемесіне сәйкес конфигурациялаңыз. Бұл ең үлкен кезек өлшемін және күту уақытын орнатуды қамтуы мүмкін.
4. Осы мақалада бұрын талқылаған шешімдерді қарастырыңыз. Өнімділікті жақсарту үшін пошта серверінің дерекқорын кезеңді түрде оңтайландырыңыз, деректерді іздеу мен өңдеуді жылдамдату үшін кэштеу механизмдерін пайдаланыңыз, мысалы, DNS сұраулары.
5. Пошта сервері әлі де жоғары жүктемеге тап болса, пошта серверлерінің кластерін немесе бұлттық шешімдерді пайдалану сияқты масштабтау опцияларын қарастырыңыз.

қорытынды

Сервер жүктемесінің артуы веб-сайтты жүктеу жылдамдығына тікелей әсер етеді, сайып келгенде, іздеу жүйелеріндегі пайдаланушы тәжірибесі мен беделіне әсер етеді. Осылайша, бұл жүктемені тиімді басқару ресурстың үздіксіз функционалдығын қамтамасыз етуде және келушілер үшін оның қолжетімділігін арттыруда шешуші рөл атқарады.