სერვერის დატვირთვის შემცირება

ამ სტატიაში ჩვენ განვიხილავთ, თუ რატომ ხდება სერვერის დატვირთვის გაზრდა და განვიხილავთ სხვადასხვა გზებს მაღალი დატვირთვის პროცესების ოპტიმიზაციისთვის. განსაკუთრებული ყურადღება დაეთმობა კოდების ოპტიმიზაციას Apache/Nginx-სა და MySQL-ში, ვისაუბრებთ ქეშირებაზე, როგორც დამხმარე ინსტრუმენტზე, ასევე განვიხილავთ შესაძლო გარე საფრთხეებს, როგორიცაა DDOS შეტევები და მათი თავიდან აცილების გზებს.

რატომ ხდება სერვერის დატვირთვა

სერვერის ოპტიმიზაციაზე გადასვლამდე აუცილებელია რესურსებზე მიმდინარე დატვირთვის საფუძვლიანი ანალიზი. ეს მოიცავს CPU დატვირთვის გაზომვას, ოპერატიული მეხსიერების მოხმარებას, ქსელის აქტივობას და სხვა ძირითად პარამეტრებს. დინამიკისა და პიკური დატვირთვის გააზრება საშუალებას გაძლევთ ამოიცნოთ შეფერხებები და გააუმჯობესოთ რესურსების განაწილება, რითაც გაზარდეთ სერვერის ინფრასტრუქტურის სტაბილურობა და შესრულება.

სერვერის მაღალი დატვირთვის საწყისი პრობლემების აღმოსაფხვრელად, ჩვენ გირჩევთ ჩაატაროთ ა სერვერის ზოგადი დიაგნოსტიკა. თუ ეს არასაკმარისია, უფრო დეტალურად რესურსების ანალიზი აუცილებელია. როგორც დამხმარე ინსტრუმენტი, შეისწავლის 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" გვერდებზე, რომლებსაც არ სჭირდებათ ინდექსირება. მეორე გამოსავალი არის . გადასინჯეთ php.ini ფაილი, სადაც უნდა დაემატოს ჩანაწერები, რომლებიც შეესაბამება კონკრეტულ საძიებო სისტემებს, მაგალითად, 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-ის შესაძლებლობები არ შემოიფარგლება მხოლოდ ინდექსირების დაბლოკვით. ჩვენ გირჩევთ გაეცნოთ მის ძირითად მახასიათებლებს მუხლი.

ქეშირების პარამეტრების გამოყენება

სერვერზე ქეშირების არასწორმა პარამეტრებმა ასევე შეიძლება გამოიწვიოს მაღალი დატვირთვა. ამ პარამეტრის ოპტიმიზაციისთვის საჭიროა შესაბამისი ცვლილებების შეტანა კონფიგურაციის ფაილებში ან . გადასინჯეთ php.ini. 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

წლის ნინიქსი სერვერზე, საკმარისია კონფიგურაციის ფაილში შემდეგი კოდის დამატება:

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>

ეს კონფიგურაცია საშუალებას აძლევს შეკუმშვას გარკვეული ტიპის ფაილებისთვის და გამორთავს მას სურათებისთვის.

იმ შემთხვევაში, თუ ნინიქსი, კონფიგურაცია ხდება 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 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>

კონფიგურაცია ამისთვის ნინიქსი მსგავსი 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 მონაცემთა ბაზის მოთხოვნების ოპტიმიზაცია ვებ სერვერზე შეიძლება მიღწეული იყოს სხვადასხვა გზით და ერთ-ერთი მათგანია კონფიგურაციის ფაილის სწორი კონფიგურაცია. როგორც წესი, ეს ფაილი სახელდება ჩემი. cnf or ჩემი.ინი და მდებარეობს ქ / და ა.შ. / 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. ინდექსები აჩქარებს მონაცემთა ძიებას, ამიტომ სწორად შემუშავებულ ინდექსებს შეუძლიათ მნიშვნელოვნად გააუმჯობესონ მოთხოვნის შესრულება. ყურადღება მიაქციეთ სვეტებს, რომლებიც ხშირად გამოიყენება WHERE or შემოგვიერთდით პირობები.
3. მოერიდეთ გამოყენებას SELECT *. ცხრილის ყველა სვეტის არჩევის ნაცვლად, მიუთითეთ მხოლოდ ის სვეტები, რომლებიც ნამდვილად აუცილებელია თქვენი მოთხოვნისთვის.
4. მოერიდეთ ფუნქციების გამოყენებას WHERE პირობები. ფუნქციების გამოყენება (როგორიცაა ქვედა, UPPER, მარცხენა, RIGHT) WHERE პირობებმა შეიძლება ინდექსები გამოუსადეგარი გახადოს. შეეცადეთ თავიდან აიცილოთ მათი პირდაპირი გამოყენება პირობებში.
5. გამოყენება შიდა შემოგვიერთდით სადაც შესაძლებელია, რადგან ეს ჩვეულებრივ უფრო ეფექტურია. ასევე, დარწმუნდით, რომ შეერთების შესაბამის სვეტებს აქვთ ინდექსები.
6. გამოყენება LIMIT შეზღუდოს დაბრუნებული რიგების რაოდენობა, თუ საჭიროა მხოლოდ გარკვეული რაოდენობის შედეგების მიღება.
7. განიხილეთ შეკითხვის შედეგების ქეშირება, განსაკუთრებით თუ ისინი იშვიათად იცვლება, სერვერის დატვირთვის შესამცირებლად.

ფოსტის სერვერი ქმნის სერვერზე მაღალ დატვირთვას

ამ განყოფილებაში განვიხილავთ, თუ როგორ უნდა დადგინდეს, რომ ფოსტის სერვერი განიცდის მაღალ დატვირთვას და რა ნაბიჯების გადადგმა შეიძლება მისი მუშაობის ოპტიმიზაციისთვის, მათ შორის შეტყობინებების რიგის შემოწმება და სერვერის პარამეტრების კონფიგურაცია. დაიწყეთ შეტყობინებების რიგის შემოწმებით. The mailq კომუნალური პროგრამა დაგეხმარებათ ამაში, მის გასააქტიურებლად, შეიყვანეთ შესაბამისი ბრძანება ტერმინალში:

mailq

ეს აჩვენებს შეტყობინებების სიას რიგში, ასეთის არსებობის შემთხვევაში. თითოეული შეტყობინება გამოჩნდება თავისი უნიკალური იდენტიფიკატორით და ინფორმაციის გაგზავნის სტატუსის შესახებ. მსგავსი შედეგის მიღება შესაძლებელია ფოსტის კლიენტის ჟურნალების გადახედვით.

უმეტეს შემთხვევაში, მაღალი დატვირთვა ხდება სერვერის კომპრომისის შემთხვევაში, როდესაც ის იწყებს სპამის გაგზავნას. თუმცა, თუ შემოწმების შემდეგ ადმინისტრატორი დარწმუნებულია, რომ სერვერზე გარედან თავდასხმა არ მომხდარა და მომხმარებლები არ უგულებელყოფენ სპამს, დროა გადავიდეთ ფოსტის სერვერის ოპტიმიზაციაზე. აქ არის ნაბიჯები, რომლებიც დაგეხმარებათ:

1. დარწმუნდით, რომ თქვენი დომენის DNS ჩანაწერები სწორად არის კონფიგურირებული, მათ შორის SPF, დკიმდა DMARC გაფართოება ჩანაწერები ფოსტის მიწოდების გასაუმჯობესებლად და სპამისგან დასაცავად. პარამეტრების სწორი კონფიგურაცია შეგიძლიათ იხილოთ სტატიაში ფოსტის სერვერის დიაგნოსტიკა.
2. შეამოწმეთ ქსელის პარამეტრები, მათ შორის firewall-ის კონფიგურაცია და მარშრუტიზაციის წესები, რათა თავიდან აიცილოთ ბლოკები და დააჩქაროთ ფოსტის მიწოდება.
3. შეტყობინებების რიგის პარამეტრების კონფიგურაცია სერვერის დატვირთვის მიხედვით. ეს შეიძლება მოიცავდეს რიგის მაქსიმალური ზომისა და დროის ამოწურვის დაყენებას.
4. განვიხილოთ გადაწყვეტილებები, რომლებიც ადრე განვიხილეთ ამ სტატიაში. პერიოდულად მოახდინეთ ფოსტის სერვერის მონაცემთა ბაზის ოპტიმიზაცია მუშაობის გასაუმჯობესებლად, გამოიყენეთ ქეშირების მექანიზმები მონაცემთა ძიებისა და დამუშავების დასაჩქარებლად, როგორიცაა DNS მოთხოვნები.
5. თუ ფოსტის სერვერი კვლავ რეგულარულად ხვდება დიდ დატვირთვას, განიხილეთ სკალირების ვარიანტები, როგორიცაა ფოსტის სერვერების კლასტერის ან ღრუბლოვანი გადაწყვეტილებების გამოყენება.

დასკვნა

სერვერის გაზრდილი დატვირთვა პირდაპირ გავლენას ახდენს ვებსაიტის ჩატვირთვის სიჩქარეზე, რაც საბოლოოდ გავლენას ახდენს მომხმარებლის გამოცდილებაზე და რეპუტაციაზე საძიებო სისტემებში. ამრიგად, ამ დატვირთვის ეფექტურად მართვა მნიშვნელოვან როლს ასრულებს რესურსის უწყვეტი ფუნქციონირების უზრუნველსაყოფად და ვიზიტორებისთვის მის ხელმისაწვდომობის გაზრდაში.