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

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

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

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

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

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

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

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

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

Као прво решење за смањење оптерећења, можете користити подешавање мета ознака „noindex“ и „nofollow“ на страницама које не треба индексирати. Друго решење је датотека .htaccess , где треба додати уносе који одговарају одређеним претраживачима, на пример, да би се сакрили од Јандекса и Гугла:

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>

Затим, омогућите модул Expires помоћу команде:

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

Имајте на уму да ће се са овим подешавањима заобићи директиве Allow и Deny .

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

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

Да бисте омогућили Gzip на Apache-у , потребно је да активирате модул mod_deflate :

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>

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

У случају 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

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

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

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

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

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

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

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

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

mailq

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

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

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

Закључак

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