В данной статье мы разберем почему возникает повышенная нагрузка на сервер и обсудим различные пути по оптимизации высоконагруженных процессов. Уделим особое внимание оптимизации кода в Apache/Nginx и MySQL, поговорим о кэшировании, как вспомогательном инструменте, а также рассмотрим возможные внешние угрозы, такие как DDOS-атаки, и способы их предотвращения.
Почему возникает нагрузка на сервер
Прежде чем приступить к оптимизации сервера, необходимо провести тщательный анализ текущей нагрузки на ресурсы. Он включает в себя измерение загрузки процессора, использование оперативной памяти, сетевой активности и других ключевых параметров. Понимание динамики и пиковых нагрузок позволяет выявить узкие места и оптимизировать ресурсное распределение, повышая стабильность и производительность серверной инфраструктуры.
Для первоначального поиска причины высокой нагрузки на сервер, рекомендуем провести общую диагностику сервера, если этого будет недостаточно, необходимо обратиться к более детальному анализу ресурсов. В качестве вспомогательного инструмента, можно исследовать логи Linux сервера, именно там в большинстве случаев находится информация об источнике проблем.
Оптимизация Apache/Nginx сервера
Повышенная нагрузка на сервер из-за индексации
Повышенная нагрузка из-за индексации на сервере может возникнуть, например, при сканировании поисковыми роботами большого количества страниц на вашем сайте. Это может привести к увеличению использования ресурсов сервера и, как следствие, замедлению работы сайта. Определить причину достаточно просто, нужно открыть файл, который расположен по пути:
/var/www/httpd-logs/sitename.access.log
При индексации поисковыми роботами, пользователь увидит записи следующего характера:
11.22.33.44 - - [Дата и время] "GET /путь-к-вашей-странице 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>
# Настройка сжатия для указанных типов файлов
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript application/x-javascript application/json
# Если браузер соответствует указанному шаблону, применяется сжатие только к текстовым/html файлам
BrowserMatch ^Mozilla/4 gzip-only-text/html
# Если браузер соответствует указанным шаблонам версий Mozilla 4.0.6, 4.0.7, 4.0.8, отключается сжатие
BrowserMatch ^Mozilla/4\.0[678] no-gzip
# Если браузер - MSIE (Internet Explorer), отключается сжатие для всех файлов, кроме текстовых/html
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# Если в запросе содержится указанный паттерн (расширения файлов изображений), отключается сжатие
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip
</IfModule>
Такая конфигурация включает сжатие для определенных типов файлов и отключает его для изображений.
В случае с Nginx, настройка происходит в блоке http файла конфигурации. Необходимо добавить следующий код:
gzip on;
gzip_disable "msie6";
# Добавляет заголовок Vary, указывая, что ответ может измениться в зависимости от значения заголовка Accept-Encoding
gzip_vary on;
# Включает сжатие для любых прокси-серверов
gzip_proxied any;
# Устанавливает уровень сжатия. Значение 6 обеспечивает хороший баланс между эффективностью сжатия и использованием ресурсов
gzip_comp_level 6;
# Задает размер буфера для сжатых данных (16 буферов по 8 килобайт каждый)
gzip_buffers 16 8k;
# Указывает, что сжатие данных должно использоваться только для HTTP версии 1.1 и выше
gzip_http_version 1.1;
# Задает типы файлов, которые могут быть сжаты
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
По аналогии с Apache, здесь устанавливаются параметры сжатия для определенных типов файлов. После внесения изменений в любой из веб-серверов, требуется выполнить перезагрузку сервиса:
sudo service apache2 restart
Или
sudo service nginx restart
DDOS-атака на сервер
Высокая нагрузка на сервер может возникать в следствие DDOS-атаки. Определить наличие DDoS-атаки можно через мониторинг внезапного увеличения трафика, аномальных запросов и падения производительности сервера. Просмотр логов на наличие повторяющихся запросов с одного IP-адреса или сканирования портов также может указать на возможную DDoS-атаку. Существует множество средств защиты, мы рассмотрим лишь основные.
Использование CDN (Content Delivery Network). 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>
# Размер хеш-таблицы для хранения информации о запросах
DOSHashTableSize 3097
# Количество запросов к одной странице перед активацией защиты
DOSPageCount 2
DOSPageInterval 1
# Количество запросов ко всем страницам перед активацией защиты
DOSSiteCount 50
DOSSiteInterval 1
# Период блокировки в секундах для IP-адресов
DOSBlockingPeriod 10
</IfModule>
По аналогии активируем модуль mod_ratelimit:
LoadModule ratelimit_module modules/mod_ratelimit.so
И добавляем конфигурацию:
<IfModule mod_ratelimit.c>
# Установка фильтра вывода для ограничения скорости (Rate Limit)
SetOutputFilter RATE_LIMIT
# Начало блока настройки для местоположения "/login"
<Location "/login">
# Установка переменной окружения rate-limit со значением 1
SetEnv rate-limit 1
# Завершение блока настройки для местоположения "/login"
</Location>
</IfModule>
Настройка для Nginx схожа с Apache. В файле конфигурации nginx.conf необходимо задействовать следующие директивы:
http {
...
# Определение зоны для ограничений соединений
limit_conn_zone $binary_remote_addr zone=addr:10m;
# Определение зоны для ограничений запросов
limit_req_zone $binary_remote_addr zone=req_zone:10m rate=1r/s;
server {
...
# Настройка ограничений соединений
limit_conn addr 10;
# Настройка ограничений запросов
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]
# Местоположение файла для записи медленных запросов. Обязательно замените на свой путь
log-slow-queries = /var/log/mariadb/slow_queries.log
# Пороговое время для считывания медленных запросов (в секундах)
long_query_time = 5
# Включение записи запросов, которые не используют индексы
log-queries-not-using-indexes = 1
# Отключение кэширования запросов
query_cache_size = 0
query_cache_type = 0
query_cache_limit = 1M
# Размер временных таблиц
tmp_table_size = 16M
max_heap_table_size = 16M
# Размер кэша потоков
thread_cache_size = 16
# Отключение резолвинга имен
skip-name-resolve = 1
# Размер буферного пула InnoDB. Устанавливайте 50-70% от доступной оперативной памяти
innodb_buffer_pool_size = 800M
# Размер лог-файла InnoDB
innodb_log_file_size = 200M
Рассмотрим также дополнительные рекомендации, которые способны облегчить взаимодействие с базой данных сервера:
- Воспользуйтесь командой EXPLAIN перед SQL-запросом для анализа его выполнения. Это позволяет получить план выполнения запроса и определить, какие индексы используются, какие таблицы сканируются и т.д.
- Индексы ускоряют поиск данных, поэтому правильно спроектированные индексы могут значительно повысить производительность запросов. Обратите внимание на колонки, по которым часто выполняются условия WHERE или JOIN.
- Избегайте использования SELECT *. Указывайте только те столбцы, которые действительно необходимы для вашего запроса, вместо выбора всех столбцов в таблице.
- Избегайте использования функций в условиях WHERE. Использование функций (например, LOWER, UPPER, LEFT, RIGHT) в условиях WHERE может сделать индексы бесполезными. Постарайтесь избегать их использования напрямую в условиях.
- Используйте INNER JOIN, если это возможно, так как он обычно более эффективен. Также, удостоверьтесь, что соответствующие столбцы для объединения имеют индексы.
- Используйте LIMIT для ограничения количества возвращаемых строк, если вам необходимо получить только определенное количество результатов.
- Рассмотрите возможность кэширования результатов запросов, особенно если они редко изменяются, чтобы уменьшить нагрузку на сервер.
Нагрузка на сервер из-за почтового сервера
В этом разделе мы рассмотрим, как определить, что почтовый сервер испытывает высокую нагрузку, и какие шаги можно предпринять для оптимизации его работы, включая проверку очереди сообщений и настройку параметров сервера. Необходимо начать с проверки очереди сообщений. В этом поможет утилита mailq, для ее активации требуется ввести соответствующую команду в терминале:
mailq
Это выведет список сообщений в очереди, если таковые есть. Каждое сообщение будет отображаться со своим уникальным идентификатором и информацией о состоянии отправки. Аналогичный результат может дать просмотр логов почтового клиента.
В большинстве случаев, высокая нагрузка возникает в случае компрометации сервера, когда с него начинают отправлять спам. Однако, если после проверки администратор уверен, что сервер не подвергался атаке со стороны и пользователи не пренебрегают спамом, следует перейти к оптимизации почтового сервера. Вот шаги, которые в этом помогут:
- Убедитесь, что DNS-записи вашего домена настроены корректно, включая SPF, DKIM и DMARC записи для улучшения доставки почты и защиты от спама. Правильную настройку параметров можно найти в статье диагностика почтового сервера.
- Проверьте сетевые настройки, включая конфигурацию файрвола и правила маршрутизации, чтобы избежать блокировок и ускорить доставку почты.
- Настройте параметры очереди сообщений в соответствии с нагрузкой сервера. Это может включать в себя настройку максимального размера очереди и таймаутов.
- Рассмотрите решения, о которых мы говорили в данной статье ранее. Периодически оптимизируйте базу данных почтового сервера для улучшения производительности, используйте механизмы кэширования для ускорения поиска и обработки данных, таких как DNS-запросы.
- Если почтовый сервер по-прежнему регулярно сталкивается с высокой загрузкой, рассмотрите возможность масштабирования, такого как использование кластера почтовых серверов или облачных решений.
Заключение
Повышенная нагрузка на сервер имеет прямое влияние на скорость загрузки веб-сайта, что в конечном итоге сказывается на пользовательском опыте и репутации в поисковых системах. Таким образом, эффективное регулирование этой нагрузки играет ключевую роль в обеспечении непрерывной функциональности ресурса и повышении его доступности для посетителей.