Добавлен: 05.12.2023
Просмотров: 24
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Содержание
| Введение…………………….............................................................................. | 5 |
| Глава 1. Модель Nginx процессов……..……………………………………… | 7 |
| 1.1. Принцип работы Nginx ………………………….………………………. | 9 |
| 1.2. Внутреннее устройство рабочего процесса ….………………………… | 10 |
| 1.3. Nginx в роли гроссмейстера..……………………….…………………… | 11 |
| 1.4. Настройка Nginx с уклоном повышенной производительности ..……. 1.4.1 Очередь невыполненных работ …………………..…………………… | 13 13 |
| 1.4.2 Файловые дескрипторы ……...………………………………………… | 14 |
| 1.4.3 Рабочие процессы ..…………………………………………………….. | 14 |
| 1.4.4 Поддержание связи ……….……………………………………………. | 15 |
| 1.4.5 Ведение журнала доступа ……………………………………………… | 16 |
| 1.4.6 Пределы …………………………………………………………………. | 16 |
| 1.5 Обновление конфигурации и исполняемого кода ……………………… | 17 |
| Выводы по теоретической части …………………………………………….. | 20 |
| Глава 2. Настройка и установка Nginx ……………..……………………….. | 21 |
| 2.1 Как установить Nginx …………………………………………………….. | 21 |
| 2.2 Расположение файлов Nginx …………….………………………………. | 21 |
| 2.3 Установка и настройка системы мониторинга Nginx ……..…………… | 22 |
| 2.3.1 Установка системы Monit ……………………………………………… | 22 |
| 2.3.2 Настройка Monit в Debian 9……………….……………………………. | 23 |
| 2.3.3 Настройка мониторинга Nginx …………………………………………. | 24 |
| 2.4 Настройка отладки в Nginx ……………...………………………………. | 25 |
| 2.5 Настройка производительности Nginx ………………………………...… | 26 |
| 2.5.1 Workers…………………………………………………………………... | 27 |
| 2.5.2 Чтение\запись диска……………………………………………………. | 28 |
| 2.5.3 Сетевой уровень………………………………………………………… | 29 |
| 2.5.4 Буфер…………………………………………………………………….. | 30 |
| | |
| | |
| 2.5.5 Сжатие…………………………………………………………………… | 31 |
| 2.5.6 Кеширование…………………………………………………………….. | 33 |
| 2.5.7 Время ожидания…………………………………………………………. | 34 |
| 2.6 Настройки безопасности Nginx…………………………………………... | 34 |
| 2.6.1 Ограничение доступа к файлам и каталогам…………………………... | 35 |
| 2.6.2 Настройка журналирования подозрительных действий……………… | 36 |
| 2.6.3 Отключение вывода списка директорий………………………………. | 37 |
| 2.7 Добавление модулей Nginx в Linux (Debian/Centos/Ubuntu)…………... | 38 |
| 2.8 Основные ошибки Nginx и их устранение………………………………. | 43 |
| 2.8.1 304 Not modified не устанавливается………………………………….. | 43 |
| 2.8.2 Client intended to send too large body…………………………………… | 43 |
| 2.8.3 02 Bad gateway…………………………………………………………... | 44 |
| 2.8.4 504 gateway time-out…………………………………………………….. | 44 |
| 2.8.5 Upstream timed out (110: connection timed out) while reading response header from upstream………………………………………………………….. | 45 |
| 2.8.6 413 Request entity too large……………………………………………… | 45 |
| Настройка веб-сервера в сети int.demo.wsr………………………………….. | 46 |
| Выводы по практической части……………………………………………… | 49 |
| Заключение……………………………………………………………………. | 50 |
| Список литературы…………………………………………………………… | 51 |
| | |
Введение
Nginx считается наилучшим по производительности объектом, благодаря собственному внутреннему устройству. В то время, как почти все веб-серверы и серверы приложений используют несложную многопоточную модель, предмет выделяется из общей массы своей необычной событийной архитектурой, которая позволяет ему с масштабироваться до сотен тыс. параллельных соединений.
Цель исследования: Настройка веб-сервера Nginx повышенной производительности без потери качества обработки данных в корпоративной сети предприятия.
Необходимо изучить следующие задачи для наиболее эффективного выполнения цели исследования:
-
Модель процессов и принцип работы веб-сервера -
Внутреннее устройство рабочего процесса -
Стандартизированная настройка nginx -
Влияние изменений изначальной конфигурации на работу сервера
Глава 1. Модель Nginx процессов
Д Рисунок 1‑1Модель NGINX процессов
ля дальнейшего улучшения понимания устройства, в соответствии с рис 1-1 необходимо понять, как происходит запуск веб-сервера Nginx.
У
# service nginx restart
* Restarting nginx
# ps -ef --forest | grep nginx
root 32475 1 0 13:36 ? 00:00:00 nginx: master process /usr/sbin/nginx \
-c /etc/nginx/nginx.conf
nginx 32476 32475 0 13:36 ? 00:00:00 \_ nginx: worker process
nginx 32477 32475 0 13:36 ? 00:00:00 \_ nginx: worker process
nginx 32479 32475 0 13:36 ? 00:00:00 \_ nginx: worker process
nginx 32480 32475 0 13:36 ? 00:00:00 \_ nginx: worker process
nginx 32481 32475 0 13:36 ? 00:00:00 \_ nginx: cache manager process
nginx 32482 32475 0 13:36 ? 00:00:00 \_ nginx: cache loader process
Рисунок 1‑2 Рабочие и вспомогательные кеш-процессы
Nginx существует мастер-процесс, исполняющий от имени суперпользователя такие операции, как чтение конфигурации, открытие портов, а также некоторое количество рабочих и вспомогательных процессов.
На 4-х ядерном сервере мастер-процесс Nginx формирует 4 рабочих и пару вспомогательных кэш-процессов, которые распоряжаются содержимым кэша на жестком диске в соответствии с рис 1-2.
Почему архитектура всё же важна?
Одна из первоначальных основ любого Unix-приложения — это процесс или поток, хотя с точки зрения ядра Linux процессы и потоки практически одно и то же — вся разница в делении адресного пространства.
Процесс или поток — это самодостаточный комплект инструкций, который ОС имеет возможность наметить для выполнения на ядре процессора. Основная масса приложений параллельно запускают множество процессов или потоков по двум причинам:
-
Для одновременного задействования большего количества вычислительных ядер; -
Процессы и потоки дают возможность легче исполнять параллельные операции.
Процессы и потоки используют дополнительные ресурсы, каждый из которых потребляет определенное количество памяти, а не считая того они периодически заменяют друг друга на процессоре (т. н. переключение контекста).
Новейшие серверы способны использовать тысячи активных процессов и потоков, но при активной работе производительность падает, как только заканчивается память или большая численность операций ввода-вывода приводит к излишней интенсивности смены контекста.
На данный момент наиболее популярным подходом к проектированию сетевого приложения является выделение каждому соединению отдельный процесс или поток.
Данная систематизация потоков достаточно легка для понимания и реализации, но при данных условиях страдает масштабируемость самого приложения.
1.1 Принцип работы Nginx
Nginx реализует модель с фиксированным количеством процессов, которая максимально эффективно использует разрешенные ресурсы системы:
-
Мастер-процесс исполняет операции, требующие повышенных прав, такие, как чтение конфигурации и открытие портов, конфигурируя нужное количество дочерних процессов (последующие типы). -
Загрузчик кэша используется при старте системы для выгрузки данных кэша, расположенных на диске, в ОЗУ, а затем завершается. Эффективность данного процесса спланирована с максимальной пользой. -
Кэш-менеджер используется с заданной периодичностью для удаления объектов кэша с жесткого диска с целью поддержания его объема в рамках заданного ограничения. -
Рабочие процессы исполняют остальные функции: обрабатывают сетевые соединения, читают данные с диска и пишут на диск, общаются с бэкенд-серверами.
Документация Nginx советует настраивать количество рабочих процессов равное числу ядер процессора, что разрешает применить системные ресурсы максимально эффективно. Данный режим задается при помощи директивы worker_processes auto в конфигурационном файле: worker_processes auto;
При нахождении Nginx под нагрузкой в основном заняты рабочие процессы. Каждый из них обрабатывает максимальное количество соединений в неблокирующемся режиме, минимизируя количество переключений контекста.
Каждый однопоточный рабочий процесс работает независимо, принимая новые соединения и обрабатывая их. Процессы взаимодействуют, друг с другом используя разделяемую память для данных кэша, сессий и других общих ресурсов.
1.2 Внутреннее устройство рабочего процесса
Р Рисунок 1‑3 Рабочий процесс
абочий процесс (Рис 1-3) Nginx инициализируется с заданной конфигурацией и набором сокетов, унаследованных от мастер-процесса. Они начинают с ожидания событий на слушающих сокетах, события которых извещают о новых соединениях.
Соединения попадают в конечный автомат — наиболее часто используемый предназначен для обработки Http, но Nginx также содержит конечные автоматы для обработки потоков tcp трафика (модуль stream) и целого ряда протоколов электронной почты (smtp, imap и pop3).
К Рисунок 1‑4Конечный автомат
онечный автомат в Nginx состоит из набора инструкций для обработки запроса, что обозначено в Рис 1-4. Большая часть веб-серверов выполняют данную функцию, но их отличие скрывается в реализации.
1.3 Nginx в роли Гроссмейстера
Каждый слышал о сеансах одновременной игры, когда один гроссмейстер играет на множестве шахматных полей сразу с десятками противников.
Таким же образом рабочий процесс Nginx «играет в шахматы». Каждый рабочий процесс, по рекомендациям одно вычислительное ядро, является гроссмейстером, способным играть сотни тысяч партий одновременно, как указано на рис 1-5.
Рисунок 1-5 Рабочий процесс Nginx
-
Рабочий процесс ожидает событий на слушающих сокетах и сокетах соединений. -
На сокетах происходят события и процесс их обрабатывает:
-
Событие на слушающем сокете означает, что пришел новый клиент для начала игры. Рабочий процесс создает новый сокет соединения. -
Событие на сокете соединений сигнализирует, что клиент сделал ход. Рабочий процесс ему мгновенно отвечает.
Рабочий процесс, обрабатывая сетевой трафик, никогда не блокируется, ожидая очередного хода от оппонента (клиента). После того как процесс сделал свой ход, он немедленно переходит к другим доскам, на
которых игроки ожидают хода, или встречает новых у двери.
Почему так получается быстрее, чем блокирующаяся многопоточная архитектура?
Каждое новое соединение создает файловый дескриптор и потребляет небольшой объем памяти в рабочем процессе, создавая наименьшие накладные расходы на соединение. Процессы Nginx могут оставаться привязанными к конкретным ядрам процессора. Переключения контекста происходят достаточно редко и в основном, когда не осталось больше работы.
В блокирующемся подходе, с отдельным процессом на каждое соединение, требуется сравнительно большой объем дополнительных ресурсов, и переключения контекста с одного процесса на другой происходят гораздо чаще.
При помощи сбалансированной настройки системы, Nginx успешно масштабируется до многих сотен тысяч параллельных http соединений на каждый рабочий процесс и уверенно поглощает всплески трафика.
1.4 Настройка Nginx с уклоном повышенной производительности
В большинстве случаев настройки Nginx и Linux по умолчанию работают хорошо, но для достижения оптимальной производительности иногда требуется небольшая настройка.
1.4.1 Очередь невыполненных работ
Рассмотрим некоторые параметры, используемые для подключения и способу постановки их в очередь:
-
net.core.somaxconn – Максимальное количество подключений, которые могут быть поставлены в очередь для принятия Nginx. Значение по умолчанию часто очень низкое, и это обычно приемлемо, потому что Nginx очень быстро принимает соединения, но его может стоить увеличить, если ваш сайт испытывает большой трафик. Если сообщения об ошибках в журнале ядра указывают на то, что значение слишком мало, увеличивайте его до тех пор, пока ошибки не прекратятся. -
net.core.netdev_max_backlog – Скорость, с которой пакеты буферизуются сетевой картой перед передачей процессору. Увеличение этого значения может повысить производительность на машинах с высокой пропускной способностью. Проверьте журнал ядра на наличие ошибок, связанных с этим параметром, и обратитесь к документации по сетевой карте для получения рекомендаций по его изменению.
1.4.2 Файловые дескрипторы
Файловые дескрипторы — это ресурсы операционной системы, используемые, среди прочего, для представления соединений и открытия файлов. Nginx может использовать до двух файловых дескрипторов для каждого подключения.