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

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

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

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

Для першапачатковага пошуку і ліквідацыі непаладак высокай нагрузкі на сервер рэкамендуецца правесці агульную дыягностыку сервера . Калі гэтага недастаткова, неабходны больш падрабязны аналіз рэсурсаў . У якасці дапаможнага інструмента можа быць карысным вывучэнне журналаў сервера 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 , куды трэба дадаць запісы, якія адпавядаюць пэўным пошукавым сістэмам, напрыклад, каб схаваць ад Яндэкса і 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. Выкарыстоўваць INNER JOIN дзе гэта магчыма, бо гэта звычайна больш эфектыўна. Таксама пераканайцеся, што адпаведныя слупкі для аб'яднання маюць індэксы.
6. Выкарыстоўваць мяжа каб абмежаваць колькасць вяртаемых радкоў, калі вам трэба атрымаць толькі пэўную колькасць вынікаў.
7. Разгледзьце магчымасць кэшавання вынікаў запытаў, асабліва калі яны рэдка змяняюцца, каб паменшыць нагрузку на сервер.

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

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

mailq

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

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

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

Conclusion

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