Смањење оптерећења сервера

У овом чланку ћемо проучити зашто долази до повећаног оптерећења сервера и размотрићемо различите начине оптимизације процеса високог оптерећења. Посебна пажња биће посвећена оптимизацији кода у Апацхе/Нгинк и МиСКЛ-у, говорићемо о кеширању као помоћном алату, а такође ћемо размотрити могуће спољне претње, као што су ДДОС напади, и начине за њихово спречавање.

Зашто долази до оптерећења сервера

Пре него што пређете на оптимизацију сервера, потребно је извршити детаљну анализу тренутног оптерећења ресурса. Ово укључује мерење оптерећења ЦПУ-а, коришћења РАМ-а, мрежне активности и других кључних параметара. Разумевање динамике и вршног оптерећења омогућава идентификацију уских грла и оптимизацију алокације ресурса, чиме се повећава стабилност и перформансе серверске инфраструктуре.

За почетно решавање проблема великог оптерећења сервера, препоручујемо да извршите а општа дијагностика сервера. Ако је ово недовољно, детаљније анализа ресурса је неопходно. Као помоћно средство, истраживање дневнике Линук-а сервер може бити од помоћи, јер се ту у већини случајева налази извор проблема.

Оптимизација Апацхе/Нгинк сервера

Повећано оптерећење сервера због индексирања

До повећаног оптерећења због индексирања на серверу може доћи, на пример, када претраживачи скенирају велики број страница на вашем сајту. Ово може довести до повећаног коришћења ресурса сервера и, последично, успорити перформансе сајта. Идентификовање узрока је релативно једноставно; потребно је да отворите датотеку која се налази на:

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

Као прво решење за смањење оптерећења, можете користити подешавање мета ознака "ноиндек" "нофоллов" на страницама које не треба индексирати. Друго решење је .хтаццесс датотеку, где треба додати уносе који одговарају одређеним претраживачима, на пример, да бисте их сакрили од Иандек-а и Гоогле-а:

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

Слично, потребно је извршити измене за друге претраживаче. Треба напоменути да могућности .хтаццесс-а нису ограничене само на блокирање индексирања. Препоручујемо да се боље упознате са његовим главним карактеристикама у чланак.

Коришћење подешавања кеширања

Нетачна подешавања кеширања на серверу такође могу довести до великог оптерећења. Да бисте оптимизовали овај параметар, потребно је извршити одговарајуће промене у конфигурационим датотекама или .хтаццесс. У случају Апацхе-а, друга опција је пожељнија, за Нгинк – прва.

По принципу апацхе сервер, потребно је да отворите .хтацесс датотеку и убаците следећи код:

<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

На Нгинк серверу, довољно је додати следећи код у конфигурациони фајл:

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

И извршите поновно учитавање услуге:

sudo service nginx restart

Имајте на уму да са овим подешавањима, Дозволити Порећи директиве ће бити заобиђене.

Коришћење компресије података

Омогућавање компресије података помоћу Гзип на Апацхе и Нгинк веб серверима помаже у смањењу количине података који се преносе између сервера и клијента, што побољшава перформансе и смањује време учитавања веб странице.

Да омогући Гзип on апацхе, потребно је да активирате мод_дефлате модул:

sudo a2enmod deflate

Затим поново покрените веб сервер:

sudo service apache2 restart

И на крају, додајте следећи блок у конфигурациону датотеку или .хтаццесс:

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

Ова конфигурација омогућава компресију за одређене типове датотека и онемогућава је за слике.

У случају Нгинк, конфигурација се јавља у хттп блок конфигурационе датотеке. Потребно је додати следећи код:

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;

Слично апацхе, овде се подешавају параметри компресије за одређене типове датотека. Након што извршите измене на било ком од веб сервера, потребно је поновно учитавање услуге:

sudo service apache2 restart

Or

sudo service nginx restart

ДДОС напад на сервер

Високо оптерећење сервера може настати као резултат ДДоС напада. Идентификовање присуства ДДоС напада може се обавити праћењем наглог повећања саобраћаја, абнормалних захтева и пада перформанси сервера. Прегледање евиденције за поновљене захтеве са једне ИП адресе или скенирање портова такође може указати на могући ДДоС напад. Постоје многе мере заштите, али ћемо разговарати само о основним.

Коришћење ЦДН-а (мрежа за испоруку садржаја). ЦДН може послужити као посредник између вашег веб сервера и корисника, дистрибуирајући саобраћај и кеширајући садржај како би се ублажио утицај ДДоС напада. ЦДН-ови такође могу имати уграђене ДДоС заштитне механизме, укључујући расподелу оптерећења и филтрирање саобраћаја.

Конфигурисање заштитних зидова и система за откривање упада (ИДС/ИПС). Заштитни зидови се могу конфигурисати да филтрирају саобраћај на основу различитих критеријума, као што су ИП адресе и портови. ИДС/ИПС може открити ненормално понашање у саобраћају и блокирати сумњиве везе. Ови алати могу бити ефикасни у праћењу и блокирању потенцијално злонамерног саобраћаја.

Конфигурисање Апацхе и Нгинк веб сервера за ублажавање утицаја ДДоС напада.

Као решење за Апацхе, омогућавамо мод_евасиве модул. Да бисте то урадили, уклоните коментар или додајте следећи ред у хттпд.цонф or апацхеКСНУМКС.цонф конфигурациони фајл:

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>

Слично томе, активирамо мод_рателимит модул:

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>

Конфигурација за Нгинк је слична апацхе. у нгинк.цонф конфигурациону датотеку, следеће директиве треба да се користе:

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

Ови примери пружају само основну конфигурацију, која се може даље прилагођавати у зависности од специфичних захтева и природе напада.

Оптимизација МиСКЛ упита

Оптимизација упита МиСКЛ базе података на веб серверу може се постићи на различите начине, а један од њих је и одговарајућа конфигурација конфигурационог фајла. Обично је ова датотека именована ми.цнф or ми.ини и налази се у / етц / or /етц/мискл/ именик. Морате да га отворите и извршите следеће промене:

[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. Употребите ОБРАЗЛОЖИТЕ команду пре СКЛ упита за анализу његовог извршења. Ово вам омогућава да добијете план извршења за упит и одредите који се индекси користе, које табеле се скенирају итд.
2. Индекси убрзавају претрагу података, тако да правилно дизајнирани индекси могу значајно побољшати перформансе упита. Обратите пажњу на колоне које се често користе у ГДЕ or ЈОИН Услови.
3. Избегавајте употребу ОДАБИР *. Наведите само оне колоне које су заиста неопходне за ваш упит, уместо да изаберете све колоне у табели.
4. Избегавајте коришћење функција у ГДЕ условима. Коришћење функција (нпр ЛОВЕР, УППЕР, ЛЕФТ, ПРАВО) ин ГДЕ услови могу учинити индексе бескорисним. Покушајте да избегнете њихову директну употребу у условима.
5. употреба ИННЕР ЈОИН где је то могуће, јер је обично ефикасније. Такође, уверите се да одговарајуће колоне за спајање имају индексе.
6. употреба ОГРАНИЧЕЊЕ да ограничите број враћених редова ако треба да добијете само одређени број резултата.
7. Размислите о кеширању резултата упита, посебно ако се ретко мењају, да бисте смањили оптерећење сервера.

Маил сервер ствара велико оптерећење на серверу

У овом одељку ћемо истражити како да утврдимо да је сервер поште под великим оптерећењем и који кораци се могу предузети да се оптимизује његов рад, укључујући проверу реда порука и конфигурисање параметара сервера. Почните са провером реда порука. Тхе маилк услужни програм може помоћи у томе, да бисте га активирали, унесите одговарајућу команду у терминал:

mailq

Ово ће приказати листу порука у реду, ако их има. Свака порука ће бити приказана са својим јединственим идентификатором и информацијама о статусу слања. Сличан резултат се може добити прегледом дневника клијента поште.

У већини случајева, велико оптерећење се јавља у случају компромитовања сервера када почне да шаље нежељену пошту. Међутим, ако је након провере администратор уверен да сервер није нападнут споља и да корисници не занемарују нежељену пошту, време је да пређемо на оптимизацију сервера поште. Ево корака који ће помоћи:

1. Уверите се да су ДНС записи вашег домена исправно конфигурисани, укључујући заштитни фактор, ДКИМ, i ДМАРЦ евиденције за побољшање испоруке поште и заштиту од нежељене поште. Исправна конфигурација параметара може се наћи у чланку о дијагностика сервера поште.
2. Проверите подешавања мреже, укључујући конфигурацију заштитног зида и правила рутирања, да бисте избегли блокаде и убрзали испоруку поште.
3. Конфигуришите параметре реда порука према оптерећењу сервера. Ово може укључивати постављање максималне величине реда и временских ограничења.
4. Размотрите решења о којима смо раније говорили у овом чланку. Периодично оптимизујте базу података сервера поште да бисте побољшали перформансе, користите механизме кеширања да бисте убрзали претрагу и обраду података, као што су ДНС упити.
5. Ако се сервер поште и даље редовно суочава са великим оптерећењем, размислите о опцијама скалирања, као што је коришћење кластера сервера поште или решења у облаку.

Закључак

Повећано оптерећење сервера директно утиче на брзину учитавања веб локације, што на крају утиче на корисничко искуство и репутацију у претраживачима. Стога, ефикасно управљање овим оптерећењем игра кључну улогу у обезбеђивању континуиране функционалности ресурса и повећању његове доступности посетиоцима.