У цій статті ми розберемося, чому виникає підвищене навантаження на сервер, і обговоримо різні способи оптимізації процесів із високим навантаженням. Особливу увагу буде приділено оптимізації коду в 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 – перший.
На а 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). Брандмауери можна налаштувати для фільтрації трафіку на основі різних критеріїв, таких як 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
Також розглянемо додаткові рекомендації, які можуть полегшити взаємодію з базою даних сервера:
- Ввімкніть кнопку ПОЯСНІТЬ перед запитом SQL, щоб проаналізувати його виконання. Це дозволяє отримати план виконання для запиту та визначити, які індекси використовуються, які таблиці скануються тощо.
- Індекси прискорюють пошук даних, тому правильно розроблені індекси можуть значно покращити продуктивність запитів. Зверніть увагу на колонки, які часто використовуються в ДЕ or РЕЄСТРАЦІЯ умовах.
- Уникайте використання SELECT *. Укажіть лише ті стовпці, які дійсно необхідні для вашого запиту, замість того, щоб вибирати всі стовпці в таблиці.
- Уникайте використання функцій у ДЕ умови. Використання функцій (таких як НИЖНІЙ, ВЕРХНІЙ, ЛІВИЙ, ПРАВОв) ДЕ умови можуть зробити індекси марними. Намагайтеся уникати їх прямого використання в умовах.
- Скористайтеся кнопкою INNER JOIN де можливо, оскільки це зазвичай ефективніше. Також переконайтеся, що відповідні стовпці для об’єднання мають індекси.
- Скористайтеся кнопкою МЕЖА щоб обмежити кількість повернутих рядків, якщо вам потрібно отримати лише певну кількість результатів.
- Розгляньте можливість кешування результатів запитів, особливо якщо вони рідко змінюються, щоб зменшити навантаження на сервер.
Поштовий сервер створює високе навантаження на сервер
У цьому розділі ми розглянемо, як визначити, що поштовий сервер зазнає високого навантаження, і які кроки можна вжити для оптимізації його роботи, включаючи перевірку черги повідомлень і налаштування параметрів сервера. Почніть з перевірки черги повідомлень. The mailq У цьому може допомогти утиліта, для її активації введіть відповідну команду в терміналі:
mailq
Це відобразить список повідомлень у черзі, якщо такі є. Кожне повідомлення відображатиметься зі своїм унікальним ідентифікатором та інформацією про статус надсилання. Аналогічний результат можна отримати, переглянувши журнали поштового клієнта.
У більшості випадків високе навантаження виникає в разі зламу сервера, коли він починає розсилати спам. Однак, якщо після перевірки адміністратор впевнений, що сервер не був атакований ззовні і користувачі не гребують спамом, пора переходити до оптимізації поштового сервера. Ось кроки, які допоможуть:
- Переконайтеся, що DNS-записи вашого домену налаштовано правильно, зокрема SPF, розширення dkim та Розширення DMARC записи для покращення доставки пошти та захисту від спаму. Правильне налаштування параметрів можна знайти в статті на діагностика поштового сервера.
- Перевірте параметри мережі, включаючи конфігурацію брандмауера та правила маршрутизації, щоб уникнути блокувань і прискорити доставку пошти.
- Налаштуйте параметри черги повідомлень відповідно до завантаження сервера. Це може включати встановлення максимального розміру черги та тайм-аутів.
- Розглянемо рішення, які ми обговорювали в цій статті раніше. Періодично оптимізуйте базу даних поштового сервера для підвищення продуктивності, використовуйте механізми кешування для прискорення пошуку й обробки даних, наприклад запитів DNS.
- Якщо поштовий сервер усе ще регулярно стикається з високим навантаженням, розгляньте варіанти масштабування, наприклад використання кластера поштових серверів або хмарних рішень.
Висновок
Збільшене навантаження на сервер безпосередньо впливає на швидкість завантаження веб-сайту, що в кінцевому підсумку впливає на взаємодію з користувачем і репутацію в пошукових системах. Таким чином, ефективне управління цим навантаженням відіграє ключову роль у забезпеченні безперервної роботи ресурсу та підвищенні його доступності для відвідувачів.