Основной модуль#
Модуль предоставляет основную функциональность и директивы конфигурации, необходимые для базовой работы сервера, а также решает важные задачи, такие как управление рабочими процессами, настройка событийно-ориентированных моделей и обработка входящих соединений и запросов. Он включает ключевые директивы для настройки основного процесса, ведения журналов ошибок и контроля поведения сервера на низком уровне.
Пример конфигурации#
user www www;
worker_processes 2;
error_log /var/log/error.log info;
events {
use kqueue; worker_connections 2048;
}
Директивы#
accept_mutex#
Когда accept_mutex включен,
рабочие процессы будут принимать новые соединения поочередно.
Иначе уведомления о новых соединениях получают все рабочие процессы,
что может привести к неэффективному использованию системных ресурсов,
если количество новых соединений невелико.
Примечание
Нет необходимости включать accept_mutex на системах,
которые поддерживают флаг EPOLLEXCLUSIVE,
или при использовании директивы reuseport.
accept_mutex_delay#
Если accept_mutex включен, эта директива указывает максимальное время, в течение которого рабочий процесс ждет, чтобы продолжить принимать новые соединения, если другой рабочий процесс уже обрабатывает новые соединения.
daemon#
Определяет, будет ли Angie запускаться в режиме демона. Используется в основном для разработки.
debug_connection#
Включает отладочный лог для отдельных клиентских соединений.
Для остальных соединений используется уровень лога,
заданный директивой error_log.
Указывать соединения можно по IPv4- или IPv6-адресу, сети или имени хоста.
Используйте параметр unix:, чтобы включить отладочный лог
для соединений через UNIX-сокеты.
events {
debug_connection 127.0.0.1;
debug_connection localhost;
debug_connection 192.0.2.0/24;
debug_connection ::1;
debug_connection 2001:0db8::/32;
debug_connection unix:;
# ...
}
Важно
Чтобы эта директива работала, в сборке Angie должен быть включен отладочный лог.
debug_points#
Эта директива используется для отладки.
В случае обнаружения внутренней ошибки,
например, утечки сокетов в момент перезапуска рабочих процессов,
включение debug_points либо создаст файл дампа памяти (abort),
либо остановит процесс (stop) для анализа с помощью отладчика.
env#
По умолчанию Angie удаляет все переменные окружения,
унаследованные от родительского процесса,
кроме переменной TZ.
Эта директива позволяет сохранить часть унаследованных переменных,
поменять их значения или создать новые переменные окружения.
Эти переменные затем:
наследуются во время обновления исполняемого файла на лету;
используются модулем Perl;
доступны рабочими процессами.
Обратите внимание, что управление системными библиотеками таким образом
может быть не всегда эффективным, поскольку библиотеки часто проверяют переменные
только во время инициализации, которая происходит до срабатывания этой директивы.
Переменная TZ всегда наследуется
и доступна модулю Perl,
если не задано явно иное поведение.
Пример:
env MALLOC_OPTIONS;
env PERL5LIB=/data/site/modules;
env OPENSSL_ALLOW_PROXY_CERTS=1;
Примечание
Переменная окружения ANGIE используется внутри Angie
и не должна задаваться напрямую пользователем.
error_log#
|
|
По умолчанию |
|
main, http, mail, stream, server, location |
Настраивает логирование,
позволяя указывать несколько логов на одном уровне конфигурации.
Если файл лога не указан явно на уровне конфигурации main,
будет использоваться файл по умолчанию.
Первый параметр указывает файл для хранения лога.
Специальное значение stderr задает стандартный поток ошибок.
Для настройки логирования в syslog
используйте префикс "syslog:".
Для логирования в циклический буфер памяти
используйте префикс "memory:", за которым следует размер буфера;
обычно он используется для отладки.
Второй параметр задает уровень логирования одним из следующих значений:
debug, info, notice, warn, error,
crit, alert или emerg.
Уровни перечислены в порядке возрастания серьезности.
При задании уровня будут логироваться сообщения равного и более высокого уровня:
Настройка |
Уровни записи |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
emerg |
Если этот параметр не задан,
по умолчанию используется уровень логирования error.
Важно
Чтобы эта директива работала, в сборке Angie должен быть включен отладочный лог.
events#
Предоставляет контекст конфигурационного файла для директив, влияющих на обработку соединений.
include#
Включает в конфигурацию другой файл или файлы, подходящие под заданную маску. Включаемые файлы должны содержать синтаксически верные директивы и блоки.
Пример:
include mime.types;
include vhosts/*.conf;
load_module#
Загружает динамический модуль из указанного файла.
Относительные пути задаются от параметра сборки
--prefix, уточнить который можно так:
$ sudo angie -V
Пример:
load_module modules/ngx_mail_module.so;
lock_file#
Angie использует механизм блокировок для реализации accept_mutex и сериализации доступа к разделяемой памяти. На большинстве систем блокировки управляются с помощью атомарных операций, что делает эту директиву ненужной. Однако на некоторых системах используется альтернативный механизм lock file. Эта директива устанавливает префикс для имен файлов блокировок.
master_process#
Определяет, будут ли запускаться рабочие процессы. Эта директива предназначена для разработчиков Angie.
multi_accept#
|
Рабочий процесс будет принимать сразу все новые соединения. |
|
Рабочий процесс будет принимать только одно новое соединение за раз. |
Примечание
Директива игнорируется при использовании метода обработки соединений kqueue, так как он сам задает число новых соединений, ожидающих приема.
pcre_jit#
Разрешает или запрещает использование JIT-компиляции (PCRE JIT) для регулярных выражений, известных на момент парсинга конфигурации.
Использование PCRE JIT заметно ускоряет обработку регулярных выражений.
Важно
Для работы JIT необходима библиотека PCRE версии 8.20 или выше,
собранная с параметром сборки --enable-jit.
Если Angie собирается с библиотекой PCRE (--with-pcre=),
поддержка JIT включается с помощью параметра --with-pcre-jit.
pid#
Указывает файл, где будет храниться идентификатор главного процесса Angie.
Файл создается атомарно, что обеспечивает корректность его содержимого.
Настройка off отключает создание этого файла.
Примечание
Если значение file изменяется при переконфигурации, но указывает на симлинк предыдущего PID-файла, файл не будет создан заново.
ssl_engine#
Задает название аппаратного SSL-акселератора.
thread_pool#
|
|
По умолчанию |
|
main |
Задает имя и параметры пула потоков, используемого для многопоточной обработки операций чтения и отправки файлов без блокирования рабочих процессов.
Параметр threads задает число потоков в пуле.
Если все потоки в пуле заняты выполнением заданий, новые задания ждут в очереди.
Параметр max_queue ограничивает число заданий,
ожидающих своего выполнения в очереди.
По умолчанию в очереди может находиться до 65536 заданий.
Если очередь переполнена, новые задания завершаются с ошибкой.
timer_resolution#
Уменьшает разрешение таймеров времени в рабочих процессах,
за счет чего уменьшается число системных вызовов gettimeofday().
По умолчанию gettimeofday() вызывается при каждом получении событий из ядра.
При уменьшении разрешения функция вызывается только раз за указанный интервал.
Пример:
timer_resolution 100ms;
Внутренняя реализация интервала зависит от используемого метода:
use#
Задает метод, используемый для обработки соединений. Обычно нет необходимости задавать его явно, поскольку по умолчанию Angie выбирает наиболее эффективный метод.
user#
|
|
По умолчанию |
|
main |
Задает пользователя и группу для рабочих процессов (см. также параметры сборки). Если задан только пользователь, для группы также задается указанное имя пользователя.
worker_aio_requests#
При использовании aio с методом обработки соединений epoll задает максимум операций асинхронного ввода-вывода, ожидающих обработки, для одного рабочего процесса.
worker_connections#
Задает максимум соединений, которые одновременно может открыть рабочий процесс.
Обратите внимание, что это число включает все соединения, такие как соединения с проксируемыми серверами, а не только клиентские. Кроме того, фактическое количество одновременных соединений не может превышать системный лимит на открытые файлы, который можно настроить с помощью worker_rlimit_nofile.
worker_cpu_affinity#
|
|
|
По умолчанию |
— |
main |
Привязывает рабочие процессы к группам процессоров. Каждая группа процессоров задается битовой маской разрешенных процессоров. Для каждого рабочего процесса должна быть задана отдельная группа. По умолчанию рабочие процессы не привязаны к конкретным процессорам.
Пример:
worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;
Эта конфигурация привязывает каждый рабочий процесс к отдельному процессору.
В качестве альтернативы:
worker_processes 2;
worker_cpu_affinity 0101 1010;
Это привязывает первый рабочий процесс к CPU0 и CPU2, а второй рабочий процесс к CPU1 и CPU3. Такая настройка подходит для гипертрединга.
Специальное значение auto
позволяет автоматически привязывать рабочие процессы к доступным процессорам:
worker_processes auto;
worker_cpu_affinity auto;
С помощью необязательной маски можно ограничить процессоры, доступные для автоматической привязки:
worker_cpu_affinity auto 01010101;
Важно
Директива доступна только на FreeBSD и Linux.
worker_priority#
Задает приоритет планирования рабочих процессов подобно тому, как это делается командой nice: отрицательное число означает более высокий приоритет. Диапазон возможных значений — от -20 до 20.
Пример:
worker_priority -10;
worker_processes#
Задает число рабочих процессов.
Оптимальное значение зависит от разных факторов, включая число ядер процессора,
количество жестких дисков и характер нагрузки.
Если вы не уверены, рекомендуется начать с числа доступных ядер процессора.
Значение auto пытается автоматически определить оптимальное количество.
worker_rlimit_core#
Меняет ограничение на наибольший размер дампа памяти (RLIMIT_CORE)
для рабочих процессов.
Используется для увеличения ограничения без перезапуска главного процесса.
worker_rlimit_nofile#
Меняет ограничение на максимальное число открытых файлов (RLIMIT_NOFILE)
для рабочих процессов.
Используется для увеличения ограничения без перезапуска главного процесса.
worker_shutdown_timeout#
Задает таймаут в секундах для постепенного завершения рабочих процессов. По истечении указанного времени Angie попытается закрыть все открытые сейчас соединения, чтобы ускорить завершение работы.
Постепенное завершение работы инициируется отправкой сигнала QUIT главному процессу, который приказывает рабочим процессам
прекратить принимать новые подключения, позволяя завершить уже существующие.
Рабочие процессы продолжают обрабатывать активные запросы до их завершения,
после чего корректно завершают свою работу. Если соединения остаются открытыми
дольше worker_shutdown_timeout, Angie принудительно закроет эти
соединения для завершения работы.
working_directory#
Задает каталог, который будет текущим для рабочего процесса. Основное применение — запись дампа памяти, поэтому рабочий процесс должен иметь права на запись в этот каталог.