Добавлен: 05.12.2023
Просмотров: 90
Скачиваний: 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‑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.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 – Скорость, с которой пакеты буферизуются сетевой картой перед передачей процессору. Увеличение этого значения может повысить производительность на машинах с высокой пропускной способностью. Проверьте журнал ядра на наличие ошибок, связанных с этим параметром, и обратитесь к документации по сетевой карте для получения рекомендаций по его изменению.