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

Այս հոդվածում մենք կխորանանք, թե ինչու է մեծանում սերվերի բեռը և կքննարկենք բարձր բեռնվածության գործընթացները օպտիմալացնելու տարբեր եղանակներ: Հատուկ ուշադրություն է դարձվելու Apache/Nginx-ում և MySQL-ում կոդերի օպտիմալացմանը, կխոսենք քեշավորման մասին՝ որպես օժանդակ գործիք, ինչպես նաև կդիտարկենք հնարավոր արտաքին սպառնալիքները, ինչպիսիք են DDOS հարձակումները, և դրանց կանխարգելման ուղիները։

Ինչու է առաջանում սերվերի բեռնվածությունը

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

Սերվերի բարձր ծանրաբեռնվածության սկզբնական խնդիրների լուծման համար խորհուրդ ենք տալիս իրականացնել 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 ֆայլ, որտեղ պետք է ավելացվեն հատուկ որոնման համակարգերին համապատասխան գրառումներ, օրինակ՝ 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>

Այնուհետև միացրեք Սպառվում է մոդուլ, օգտագործելով հրամանը.

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

Նշենք, որ այս կարգավորումներով, Թույլ տալ և Ընդունել հրահանգները կշրջանցվեն.

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

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

Հնարավորություն տալու համար Gzip on 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). Firewall-ները կարող են կազմաձևվել, որպեսզի զտեն տրաֆիկը տարբեր չափանիշների հիման վրա, ինչպիսիք են IP հասցեները և նավահանգիստները: IDS/IPS-ը կարող է հայտնաբերել երթևեկության աննորմալ վարքագիծը և արգելափակել կասկածելի կապերը: Այս գործիքները կարող են արդյունավետ լինել պոտենցիալ վնասակար երթևեկությունը հետևելու և արգելափակելու համար:

Apache և Nginx վեբ սերվերների կարգավորում՝ DDoS հարձակումների ազդեցությունը մեղմելու համար:

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

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

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

mailq

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

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

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

Եզրափակում

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