Зніжэнне нагрузкі на сервер

У гэтым артыкуле мы паглыбімся ў тое, чаму адбываецца павелічэнне нагрузкі на сервер, і абмяркуем розныя спосабы аптымізацыі працэсаў з высокай нагрузкай. Асаблівая ўвага будзе нададзена аптымізацыі кода ў Apache/Nginx і MySQL, мы пагаворым аб кэшаванні як дапаможным інструменце, а таксама разгледзім магчымыя знешнія пагрозы, такія як DDOS-атакі, і спосабы іх прадухілення.

Чаму адбываецца загрузка сервера

Перш чым прыступіць да аптымізацыі сервера, неабходна правесці дбайны аналіз бягучай нагрузкі на рэсурсы. Гэта ўключае ў сябе вымярэнне загрузкі працэсара, выкарыстання аператыўнай памяці, сеткавай актыўнасці і іншых ключавых параметраў. Разуменне дынамікі і пікавых нагрузак дазваляе выявіць вузкія месцы і аптымізаваць размеркаванне рэсурсаў, тым самым павысіўшы стабільнасць і прадукцыйнасць сервернай інфраструктуры.

Для першапачатковага ліквідацыі непаладак высокай загрузкі сервера мы рэкамендуем правесці 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)"

У якасці першага рашэння для зніжэння нагрузкі можна выкарыстоўваць наладу мета-тэгаў "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 - першы.

аб адным Апач сервер, вам трэба адкрыць .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

Звярніце ўвагу, што з гэтымі параметрамі, the Дазваляць і Адмаўляць дырэктывы будуць абыдзены.

Выкарыстанне сціску даных

Уключэнне сціску дадзеных з дапамогай Gzip на вэб-серверах Apache і Nginx дапамагае паменшыць аб'ём даных, якія перадаюцца паміж серверам і кліентам, што павышае прадукцыйнасць і скарачае час загрузкі вэб-старонкі.

Для таго, каб Gzip on Апач, вам трэба актываваць 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;

Як і ў Апач, тут задаюцца параметры сціску для пэўных тыпаў файлаў. Пасля ўнясення змяненняў у любы з вэб-сервераў патрабуецца перазагрузка службы:

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 мы ўключаем мод_ухіленне модуль. Каб зрабіць гэта, раскаментуйце або дадайце наступны радок у 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 аналагічна Апач, ў 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 на вэб-серверы можа быць дасягнута рознымі спосабамі, і адзін з іх - правільная канфігурацыя файла канфігурацыі. Як правіла, гэты файл называецца мой.cnf or мой.ini і знаходзіцца ў / і г.д. / 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. Пазбягайце выкарыстання функцый у ДЗЕ умовы. Выкарыстанне функцый (напрыклад НІЖНІ, Верхняга, Левы, ПРАВА) у ДЗЕ умовы могуць зрабіць індэксы бескарыснымі. Старайцеся пазбягаць іх прамога выкарыстання ва ўмовах.
5. Выкарыстоўваць INNER JOIN дзе гэта магчыма, бо гэта звычайна больш эфектыўна. Таксама пераканайцеся, што адпаведныя слупкі для аб'яднання маюць індэксы.
6. Выкарыстоўваць мяжа каб абмежаваць колькасць вяртаемых радкоў, калі вам трэба атрымаць толькі пэўную колькасць вынікаў.
7. Разгледзьце магчымасць кэшавання вынікаў запытаў, асабліва калі яны рэдка змяняюцца, каб паменшыць нагрузку на сервер.

Паштовы сервер стварае вялікую нагрузку на сервер

У гэтым раздзеле мы вывучым, як вызначыць, што паштовы сервер адчувае вялікую нагрузку, і якія крокі можна зрабіць для аптымізацыі яго працы, уключаючы праверку чаргі паведамленняў і канфігурацыю параметраў сервера. Пачніце з праверкі чаргі паведамленняў. The mailq У гэтым можа дапамагчы ўтыліта, для яе актывацыі увядзіце ў тэрмінале адпаведную каманду:

mailq

Гэта адлюструе спіс паведамленняў у чарзе, калі такія маюцца. Кожнае паведамленне будзе адлюстроўвацца з унікальным ідэнтыфікатарам і інфармацыяй аб статусе адпраўкі. Аналагічны вынік можна атрымаць, прагледзеўшы логі паштовага кліента.

У большасці выпадкаў высокая нагрузка ўзнікае ў выпадку ўзлому сервера, калі ён пачынае рассылаць спам. Аднак калі пасля праверкі адміністратар упэўнены, што сервер не быў атакаваны звонку і карыстальнікі не грэбуюць спамам, самы час пераходзіць да аптымізацыі паштовага сервера. Вось крокі, якія дапамогуць:

1. Пераканайцеся, што запісы DNS вашага дамена настроены правільна, у тым ліку SPF, ДКІМ, і DMARC запісы для паляпшэння дастаўкі пошты і абароны ад спаму. Правільную наладу параметраў можна знайсці ў артыкуле па Дыягностыка паштовага сервера.
2. Праверце налады сеткі, уключаючы канфігурацыю брандмаўэра і правілы маршрутызацыі, каб пазбегнуць блакіроўкі і паскорыць дастаўку пошты.
3. Наладзьце параметры чаргі паведамленняў у адпаведнасці з загрузкай сервера. Гэта можа ўключаць у сябе ўстаноўку максімальнага памеру чаргі і тайм-аўтаў.
4. Разгледзім рашэнні, якія мы абмяркоўвалі ў гэтым артыкуле раней. Перыядычна аптымізуйце базу дадзеных паштовага сервера для павышэння прадукцыйнасці, выкарыстоўвайце механізмы кэшавання для паскарэння пошуку і апрацоўкі даных, напрыклад DNS-запытаў.
5. Калі паштовы сервер па-ранейшаму рэгулярна сутыкаецца з высокай нагрузкай, разгледзьце варыянты маштабавання, такія як выкарыстанне кластара паштовых сервераў або воблачных рашэнняў.

Conclusion

Павелічэнне нагрузкі на сервер непасрэдна ўплывае на хуткасць загрузкі вэб-сайта, што ў канчатковым выніку ўплывае на карыстацкі досвед і рэпутацыю ў пошукавых сістэмах. Такім чынам, эфектыўнае кіраванне гэтай нагрузкай адыгрывае ключавую ролю ў забеспячэнні бесперапыннай функцыянальнасці рэсурсу і павышэнні яго даступнасці для наведвальнікаў.