Намалување на оптоварувањето на серверот

Во оваа статија, ќе истражуваме зошто се јавува зголемено оптоварување на серверот и ќе разговараме за различни начини за оптимизирање на процесите со големо оптоварување. Посебно внимание ќе се посвети на оптимизацијата на кодот во Apache/Nginx и MySQL, ќе зборуваме за кеширањето како помошна алатка, а исто така ќе ги разгледаме можните надворешни закани, како што се DDOS нападите, и начините за нивно спречување.

Зошто се појавува оптоварување на серверот

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

За почетно решавање проблеми со големо оптоварување на серверот, препорачуваме да се спроведе општа дијагностика на серверот . Доколку ова не е доволно, потребна е подетална анализа на ресурсите . Како помошна алатка, истражувањето на логовите на 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)"

Како прво решение за намалување на оптоварувањето, можете да го користите поставувањето на мета ознаките „noindex“ и „nofollow“ на страниците што не треба да се индексираат. Второто решение е датотеката .htaccess , каде што треба да се додадат записи што одговараат на одредени пребарувачи, на пример, за да се сокријат од Yandex и 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>

Потоа, овозможете го модулот 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

И, конечно, додадете го следниот блок во конфигурациската датотека или .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 (Мрежа за испорака на содржина) . CDN може да послужи како посредник помеѓу вашиот веб-сервер и корисниците, дистрибуирајќи сообраќај и кеширајќи содржина за да го ублажи влијанието на DDoS нападот. CDN-ите исто така можат да имаат вградени механизми за заштита од DDoS, вклучувајќи распределба на оптоварувањето и филтрирање на сообраќајот.

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

Конфигурирање на веб-серверите на Apache и Nginx за да се ублажи влијанието на DDoS нападите.

Како решение за 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 пребарувања

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

Серверот за пошта создава големо оптоварување на серверот

Во овој дел, ќе истражиме како да утврдиме дека поштенскиот сервер е под големо оптоварување и кои чекори можат да се преземат за да се оптимизира неговото работење, вклучително и проверка на редот на пораки и конфигурирање на параметрите на серверот. Започнете со проверка на редот на пораки. Алатката mailq може да помогне во ова, за да ја активирате, внесете ја соодветната команда во терминалот:

mailq

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

Во повеќето случаи, големо оптоварување се јавува во случај на компромис на серверот кога ќе започне да испраќа спам. Меѓутоа, ако по проверката администраторот е уверен дека серверот не е нападнат однадвор и дека корисниците не занемаруваат спам, време е да продолжите со оптимизирање на серверот за пошта. Еве ги чекорите што ќе помогнат:

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

Заклучок

Зголеменото оптоварување на серверот директно влијае на брзината на вчитување на веб-локациите, што на крајот влијае на корисничкото искуство и репутацијата во пребарувачите. Така, ефикасното управување со овој товар игра клучна улога во обезбедувањето континуирана функционалност на ресурсот и зголемување на неговата пристапност за посетителите.