Սերվերի ծանրաբեռնվածության նվազեցում

Այս հոդվածում մենք կխորանանք, թե ինչու է մեծանում սերվերի բեռը և կքննարկենք բարձր բեռնվածության գործընթացները օպտիմալացնելու տարբեր եղանակներ: Հատուկ ուշադրություն է դարձվելու 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 հրահանգները շրջանցվելու են։

Օգտագործելով տվյալների սեղմում

Apache և Nginx վեբ սերվերների վրա Gzip-ի միջոցով տվյալների սեղմման միացումը օգնում է նվազեցնել սերվերի և հաճախորդի միջև փոխանցվող տվյալների քանակը, ինչը բարելավում է աշխատանքի արդյունավետությունը և կրճատում վեբ էջի բեռնման ժամանակը։

Apache- ում Gzip-ը միացնելու համար անհրաժեշտ է ակտիվացնել 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 պաշտպանության մեխանիզմներ, ներառյալ բեռի բաշխումը և երթևեկության զտումը:

Firewall-ների և ներխուժման հայտնաբերման համակարգերի (IDS/IPS) կարգավորում : Firewall-ները կարող են կարգավորվել տարբեր չափանիշների, ինչպիսիք են 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. Խուսափեք գործառույթների օգտագործումից ՈՐՏԵՂ պայմանները. Օգտագործելով գործառույթներ (օրինակ Ավելի ցածր, UPPER, LEFT, RIGHT) ՈՐՏԵՂ պայմանները կարող են անօգուտ դարձնել ինդեքսները: Փորձեք խուսափել դրանց անմիջական օգտագործումից պայմաններում։
5. օգտագործում ՆԵՐՔԻՆ ՄԻԱՑՈՒՄ որտեղ հնարավոր է, քանի որ դա սովորաբար ավելի արդյունավետ է: Նաև համոզվեք, որ միանալու համար համապատասխան սյունակներն ունենան ինդեքսներ:
6. օգտագործում ՍԱՀՄԱՆԸ սահմանափակել վերադարձված տողերի քանակը, եթե անհրաժեշտ է ստանալ միայն որոշակի քանակի արդյունքներ:
7. Հաշվի առեք հարցման արդյունքների քեշավորումը, հատկապես, եթե դրանք հազվադեպ են փոխվում, սերվերի ծանրաբեռնվածությունը նվազեցնելու համար:

Փոստի սերվերը մեծ բեռ է ստեղծում սերվերի վրա

Այս բաժնում մենք կուսումնասիրենք, թե ինչպես որոշել, որ փոստային սերվերը բարձր ծանրաբեռնվածություն ունի, և ինչ քայլեր կարելի է ձեռնարկել դրա աշխատանքը օպտիմալացնելու համար, ներառյալ հաղորդագրությունների հերթի ստուգումը և սերվերի պարամետրերի կարգավորումը: Սկսեք հաղորդագրությունների հերթի ստուգումից: Այս հարցում կարող է օգնել mailq ծրագիրը, այն ակտիվացնելու համար տերմինալում մուտքագրեք համապատասխան հրամանը.

mailq

Սա կցուցադրի հերթում գտնվող հաղորդագրությունների ցանկը, եթե այդպիսիք կան: Յուրաքանչյուր հաղորդագրություն կցուցադրվի իր եզակի նույնացուցիչով և ուղարկման կարգավիճակի մասին տեղեկություններով: Նմանատիպ արդյունք կարելի է ստանալ՝ դիտելով փոստային հաճախորդի տեղեկամատյանները:

Շատ դեպքերում մեծ ծանրաբեռնվածություն է առաջանում սերվերի խախտման դեպքում, երբ այն սկսում է սպամ ուղարկել: Այնուամենայնիվ, եթե ադմինիստրատորը ստուգելուց հետո վստահ է, որ սերվերը դրսից հարձակման չի ենթարկվել, և օգտվողները չեն անտեսում սպամը, ժամանակն է անցնել փոստի սերվերի օպտիմալացմանը: Ահա այն քայլերը, որոնք կօգնեն.

1. Համոզվեք, որ ձեր տիրույթի DNS գրառումները ճիշտ կազմաձևված են, ներառյալ SPF, ԴԿԻՄ, եւ DMARC գրառումներ՝ փոստի առաքումը բարելավելու և սպամից պաշտպանելու համար: Պարամետրերի ճիշտ կազմաձևումը կարելի է գտնել հոդվածում փոստի սերվերի ախտորոշում.
2. Ստուգեք ցանցի կարգավորումները, ներառյալ firewall-ի կազմաձևումը և երթուղային կանոնները՝ արգելափակումից խուսափելու և փոստի առաքումն արագացնելու համար:
3. Կազմաձևեք հաղորդագրությունների հերթի պարամետրերը՝ ըստ սերվերի բեռնվածության: Սա կարող է ներառել առավելագույն հերթի չափի և ժամկետների սահմանում:
4. Քննենք լուծումները, որոնք մենք քննարկել ենք այս հոդվածում ավելի վաղ։ Պարբերաբար օպտիմիզացրեք փոստային սերվերի տվյալների բազան՝ արդյունավետությունը բարելավելու համար, օգտագործեք քեշավորման մեխանիզմներ տվյալների որոնումն ու մշակումն արագացնելու համար, օրինակ՝ DNS հարցումները:
5. Եթե ​​փոստի սերվերը դեռ կանոնավոր կերպով բախվում է մեծ բեռնվածության, հաշվի առեք մասշտաբային տարբերակները, ինչպիսիք են փոստի սերվերների կլաստերի կամ ամպային լուծումների օգտագործումը:

Եզրափակում

Սերվերի ծանրաբեռնվածության ավելացումն ուղղակիորեն ազդում է կայքի բեռնման արագության վրա՝ ի վերջո ազդելով օգտատերերի փորձի և հեղինակության վրա որոնման համակարգերում: Այսպիսով, այս բեռի արդյունավետ կառավարումը առանցքային դեր է խաղում ռեսուրսի շարունակական ֆունկցիոնալության ապահովման և այցելուների համար դրա հասանելիության բարձրացման գործում: