В данной статье мы разберем почему возникает повышенная нагрузка на сервер и обсудим различные пути по оптимизации высоконагруженных процессов. Уделим особое внимание оптимизации кода в 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

Рассмотрим также дополнительные рекомендации, которые способны облегчить взаимодействие с базой данных сервера:

1. Воспользуйтесь командой EXPLAIN перед SQL-запросом для анализа его выполнения. Это позволяет получить план выполнения запроса и определить, какие индексы используются, какие таблицы сканируются и т.д.
2. Индексы ускоряют поиск данных, поэтому правильно спроектированные индексы могут значительно повысить производительность запросов. Обратите внимание на колонки, по которым часто выполняются условия WHERE или JOIN.
3. Избегайте использования SELECT *. Указывайте только те столбцы, которые действительно необходимы для вашего запроса, вместо выбора всех столбцов в таблице.
4. Избегайте использования функций в условиях WHERE. Использование функций (например, LOWER, UPPER, LEFT, RIGHT) в условиях WHERE может сделать индексы бесполезными. Постарайтесь избегать их использования напрямую в условиях.
5. Используйте INNER JOIN, если это возможно, так как он обычно более эффективен. Также, удостоверьтесь, что соответствующие столбцы для объединения имеют индексы.
6. Используйте LIMIT для ограничения количества возвращаемых строк, если вам необходимо получить только определенное количество результатов.
7. Рассмотрите возможность кэширования результатов запросов, особенно если они редко изменяются, чтобы уменьшить нагрузку на сервер.

Нагрузка на сервер из-за почтового сервера

В этом разделе мы рассмотрим, как определить, что почтовый сервер испытывает высокую нагрузку, и какие шаги можно предпринять для оптимизации его работы, включая проверку очереди сообщений и настройку параметров сервера. Необходимо начать с проверки очереди сообщений. В этом поможет утилита mailq, для ее активации требуется ввести соответствующую команду в терминале:

mailq

Это выведет список сообщений в очереди, если таковые есть. Каждое сообщение будет отображаться со своим уникальным идентификатором и информацией о состоянии отправки. Аналогичный результат может дать просмотр логов почтового клиента.

В большинстве случаев, высокая нагрузка возникает в случае компрометации сервера, когда с него начинают отправлять спам. Однако, если после проверки администратор уверен, что сервер не подвергался атаке со стороны и пользователи не пренебрегают спамом, следует перейти к оптимизации почтового сервера. Вот шаги, которые в этом помогут:

1. Убедитесь, что DNS-записи вашего домена настроены корректно, включая SPF, DKIM и DMARC записи для улучшения доставки почты и защиты от спама. Правильную настройку параметров можно найти в статье диагностика почтового сервера.
2. Проверьте сетевые настройки, включая конфигурацию файрвола и правила маршрутизации, чтобы избежать блокировок и ускорить доставку почты.
3. Настройте параметры очереди сообщений в соответствии с нагрузкой сервера. Это может включать в себя настройку максимального размера очереди и таймаутов.
4. Рассмотрите решения, о которых мы говорили в данной статье ранее. Периодически оптимизируйте базу данных почтового сервера для улучшения производительности, используйте механизмы кэширования для ускорения поиска и обработки данных, таких как DNS-запросы.
5. Если почтовый сервер по-прежнему регулярно сталкивается с высокой загрузкой, рассмотрите возможность масштабирования, такого как использование кластера почтовых серверов или облачных решений.

Заключение

Повышенная нагрузка на сервер имеет прямое влияние на скорость загрузки веб-сайта, что в конечном итоге сказывается на пользовательском опыте и репутации в поисковых системах. Таким образом, эффективное регулирование этой нагрузки играет ключевую роль в обеспечении непрерывной функциональности ресурса и повышении его доступности для посетителей.