Re: Тест nginx -- сколько сообщений в log syslog без потерь?
On 05.02.2024 23:21, Evgeniy Berdnikov wrote: Если у вас уже есть такое рабочее решение - поделитесь опытом, буду рад вас выслушать. Создание нормального рабочего решения должно начинаться с внимательного чтения документации и исходников nginx. Насчёт чтения исходников -- выглядит примерно таким же экстремизмом, как требование знания ассемблера для прикладного программиста... :) Слово "должно" здесь означает SHOULD а не MUST, то есть - это рекомендация, а не требование. Исходники - это тоже документация, причем максимально точно и максимально подробно рассказывающая о поведении программы. По крайней мере, это часто экономит время, если ответа нет в документации - то мне обычно проще и быстрее посмотреть в исходниках - документации №2, или провести эксперимент. При чем тут ассемблер - не совсем понятно, nginx ведь на C написан, как и большая часть операционной системы и всего системного софта. Какую именно существующую проблему Вы пытаетесь решить с помощью ротации лог-файлов с интервалом в 30 секунд? Товарищ отвечал на этот вопрос: https://mailman.nginx.org/pipermail/nginx-ru/2024-January/MD45SEEP573DPPEQYAFT26MPMUK5646B.html почему не подходит вариант делать ротацию логов с помощью USR1 ? Потому что если программа, которая читает данные из unix socket`а отвалится - тогда произойдет переполенение буфера и nginx тогда заблокируется на операции записи в unix socket, и как следствие этого - перестанет выполнять свою основную функцию - перестанет отвечать на запросы клиентов по http / https протоколу. Если так, и без вариантов, то это скорее недостаток nginx-а. Нужно делать запись в сислог через неблокирующийся сокет, и дропать записи если отправлять их не удаётся. Потому что в подавляющем большинстве случаев факт работоспобности сервиса ВАЖНЕЕ правильности его работы и отсутствия разных недостатков, вроде пропуска записей в логах. А ещё лучше дать юзеру ручку, управляющую поведением программы при блокировке записи в лог. Возможно, я что-то напутали и помню или старое поведение nginx, или путаю сейчас nginx с другой программой, или вообще - путаю unix socket`ы с пайпами. Но текущее поведение nginx можно легко узнать с помощью эксперимента. Мне обычных логов вполне хватает, поэтому записью логов nginx в unix socket никогда не занимался. По мне так пример разумного подхода -- сквидовский logfile-daemon. Сейчас логи каждый воркер пишет в файл напрямую, а если писать логи через какой-то дополнительный процесс - это увеличит накладные расходы на IPC и сложность, не принося при этом никакой пользы и ценности, IMHO. -- Best regards, Gena ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Тест nginx -- сколько сообщений в log syslog без потерь?
Hello! On Mon, Feb 05, 2024 at 09:56:54PM +0200, Gena Makhomed wrote: [...] > Потому что если программа, которая читает данные из unix socket`а > отвалится - тогда произойдет переполенение буфера и nginx тогда > заблокируется на операции записи в unix socket, и как следствие > этого - перестанет выполнять свою основную функцию - перестанет > отвечать на запросы клиентов по http / https протоколу. Нет, если в сокет syslog'а не получается писать - nginx [логгирует ошибку в error log и] дропает сообщение. Я об этом, собственно, писал в начале треда - судя по всему, исходная проблема была именно в том, что syslog-сервер не успевал выгребать сообщения, и они осыпались на пол. (А если вернуться к основам, то в syslog через стандартную библиотеку nginx не пишет именно потому, что там запись в сокет в случае чего блокируется, и так, конечно, жить нельзя.) [...] > Так же не понятно, в чем для Вас проблема переименовать > log-файл и отправить сигнал USR1 мастер-процессу nginx, > для того, чтобы он переоткрыл log-файл и продолжил запись. > > Особенно, если учесть, что директива https://nginx.org/r/access_log > имеет дополнительные параметры [buffer=size] [flush=time] [if=condition] +1 Нет никаких проблем вращать файловые логи в nginx'е, переоткрытие логов по USR1 - дешёвая и быстрая операция. При этом запись в файловые логи, во-первых, куда эффективнее записи в syslog, в силу отсутствия лишних context switch'ей, а во-вторых, позволяет дополнительно и существенно снизить затраты за счёт буферизации и даже gzip-сжатия на лету. Если на выходе всё равно файлы - совершенно непонятно, зачем нужна вся эта запись в python-скрипты, изображающие из себя syslog-сервера. [...] -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Тест nginx -- сколько сообщений в log syslog без потерь?
On Mon, Feb 05, 2024 at 09:56:54PM +0200, Gena Makhomed wrote: > On 05.02.2024 15:21, Anatoliy Melnik via nginx-ru wrote: > > Если у вас уже есть такое рабочее решение - поделитесь опытом, буду рад вас > > выслушать. > > Создание нормального рабочего решения должно начинаться > с внимательного чтения документации и исходников nginx. Насчёт чтения исходников -- выглядит примерно таким же экстремизмом, как требование знания ассемблера для прикладного программиста... :) > Какую именно существующую проблему Вы пытаетесь решить > с помощью ротации лог-файлов с интервалом в 30 секунд? Товарищ отвечал на этот вопрос: https://mailman.nginx.org/pipermail/nginx-ru/2024-January/MD45SEEP573DPPEQYAFT26MPMUK5646B.html > Потому что если программа, которая читает данные из unix socket`а > отвалится - тогда произойдет переполенение буфера и nginx тогда > заблокируется на операции записи в unix socket, и как следствие > этого - перестанет выполнять свою основную функцию - перестанет > отвечать на запросы клиентов по http / https протоколу. Если так, и без вариантов, то это скорее недостаток nginx-а. Нужно делать запись в сислог через неблокирующийся сокет, и дропать записи если отправлять их не удаётся. Потому что в подавляющем большинстве случаев факт работоспобности сервиса ВАЖНЕЕ правильности его работы и отсутствия разных недостатков, вроде пропуска записей в логах. А ещё лучше дать юзеру ручку, управляющую поведением программы при блокировке записи в лог. По мне так пример разумного подхода -- сквидовский logfile-daemon. -- Eugene Berdnikov ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Тест nginx -- сколько сообщений в log syslog без потерь?
пн, 5 февр. 2024 г. в 20:57, Gena Makhomed : > On 05.02.2024 15:21, Anatoliy Melnik via nginx-ru wrote: > >> какую именно проблему Вы пытаетесь решить с помощью записи логов > >> в unix socket, чтения данных из unix socket`а питоновским скриптом > >> и потом записи данных этим питоновским скриптом в текстовой файл? > > > Если вы предлагаете писать напрямую с nginx-а в файл -- сделайте у себя > ротацию файлов с интервалом 30 сек при 200-250 тыс подключений/сек... > > Если у вас уже есть такое рабочее решение - поделитесь опытом, буду рад > вас выслушать. > > Создание нормального рабочего решения должно начинаться > с внимательного чтения документации и исходников nginx. > > Какую именно существующую проблему Вы пытаетесь решить > с помощью ротации лог-файлов с интервалом в 30 секунд? > > > А на текущем отрезке времени: > > Спасибо, я уже все решил :) > > Нет. Вы просто создали себе еще большую проблему на ровном месте. > > Потому что если программа, которая читает данные из unix socket`а > отвалится - тогда произойдет переполенение буфера и nginx тогда > заблокируется на операции записи в unix socket, и как следствие > этого - перестанет выполнять свою основную функцию - перестанет > отвечать на запросы клиентов по http / https протоколу. > > То есть, то что Вы сделали - это достаточно хрупкое > и ненадежное "решение", особенно в условиях высоких нагрузок. > > Не всегда нужно все подряд писать в лог, например, > можно ограничиться записью в лог только ответов с 4хх и 5хх статусами, > в таком случае - не будет той проблемы, которую Вы пытаетесь > решить таким способом с помощью unix-socket`а и python. > > Так же не понятно, в чем для Вас проблема переименовать > log-файл и отправить сигнал USR1 мастер-процессу nginx, > для того, чтобы он переоткрыл log-файл и продолжил запись. > > Особенно, если учесть, что директива https://nginx.org/r/access_log > имеет дополнительные параметры [buffer=size] [flush=time] [if=condition] > > Вместо этого - какие-то жуткие костыли - то syslog, то unix socket и > питоновские скрипты, читающие данные из этого unix-socket`а пишущие > текстовые файлы, то еще что-то. > > Вы так и не ответили на мой вопрос, какую именно проблему > Вы пытаетесь решить таким вот нетривиальным способом? > проблему трудоустройства )) ? положа руку на сердце, с ротацией логов есть несколько, честно скажем, решений, с которыми выглядит как компромисс 1) переменные (позволяющие создавать новый лог, скажем по map-у раз в 30 сек). вроде норм, но буферизации в этом случае не будет. но на nvme возможно норм 2) copytruncate режим 3) описанный режим с USR1 > > https://habr.com/ru/companies/dododev/articles/467047/ > Феномен XY: как избежать «неправильных» проблем > > -- > Best regards, > Gena > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru > ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Тест nginx -- сколько сообщений в log syslog без потерь?
On 05.02.2024 15:21, Anatoliy Melnik via nginx-ru wrote: какую именно проблему Вы пытаетесь решить с помощью записи логов в unix socket, чтения данных из unix socket`а питоновским скриптом и потом записи данных этим питоновским скриптом в текстовой файл? Если вы предлагаете писать напрямую с nginx-а в файл -- сделайте у себя ротацию файлов с интервалом 30 сек при 200-250 тыс подключений/сек... Если у вас уже есть такое рабочее решение - поделитесь опытом, буду рад вас выслушать. Создание нормального рабочего решения должно начинаться с внимательного чтения документации и исходников nginx. Какую именно существующую проблему Вы пытаетесь решить с помощью ротации лог-файлов с интервалом в 30 секунд? А на текущем отрезке времени: Спасибо, я уже все решил :) Нет. Вы просто создали себе еще большую проблему на ровном месте. Потому что если программа, которая читает данные из unix socket`а отвалится - тогда произойдет переполенение буфера и nginx тогда заблокируется на операции записи в unix socket, и как следствие этого - перестанет выполнять свою основную функцию - перестанет отвечать на запросы клиентов по http / https протоколу. То есть, то что Вы сделали - это достаточно хрупкое и ненадежное "решение", особенно в условиях высоких нагрузок. Не всегда нужно все подряд писать в лог, например, можно ограничиться записью в лог только ответов с 4хх и 5хх статусами, в таком случае - не будет той проблемы, которую Вы пытаетесь решить таким способом с помощью unix-socket`а и python. Так же не понятно, в чем для Вас проблема переименовать log-файл и отправить сигнал USR1 мастер-процессу nginx, для того, чтобы он переоткрыл log-файл и продолжил запись. Особенно, если учесть, что директива https://nginx.org/r/access_log имеет дополнительные параметры [buffer=size] [flush=time] [if=condition] Вместо этого - какие-то жуткие костыли - то syslog, то unix socket и питоновские скрипты, читающие данные из этого unix-socket`а пишущие текстовые файлы, то еще что-то. Вы так и не ответили на мой вопрос, какую именно проблему Вы пытаетесь решить таким вот нетривиальным способом? https://habr.com/ru/companies/dododev/articles/467047/ Феномен XY: как избежать «неправильных» проблем -- Best regards, Gena ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Тест nginx -- сколько сообщений в log syslog без потерь?
Gena Makhomed >какую именно проблему Вы пытаетесь решить с помощью записи логов >в unix socket, чтения данных из unix socket`а питоновским скриптом >и потом записи данных этим питоновским скриптом в текстовой файл? Если вы предлагаете писать напрямую с nginx-а в файл -- сделайте у себя ротацию файлов с интервалом 30 сек при 200-250 тыс подключений/сек... Если у вас уже есть такое рабочее решение - поделитесь опытом, буду рад вас выслушать. А на текущем отрезке времени: Спасибо, я уже все решил :) ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Тест nginx -- сколько сообщений в log syslog без потерь?
On 05.02.2024 13:40, Anatoliy Melnik via nginx-ru wrote: Итак конечный вариант решения: Данные почти равномерно расходятся по 10-ти файлам, которые пишутся на tmpfs в RAM. Отказался и от rsyslog и от syslog-ng В качестве принимающей стороны выступает пока python скрипт В нем стартую 10 процессов, каждый слушает свой сокет и вся его задача -- сложить в файл данные. какую именно проблему Вы пытаетесь решить с помощью записи логов в unix socket, чтения данных из unix socket`а питоновским скриптом и потом записи данных этим питоновским скриптом в текстовой файл? https://habr.com/ru/companies/dododev/articles/467047/ Феномен XY: как избежать «неправильных» проблем -- Best regards, Gena ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Тест nginx -- сколько сообщений в log syslog без потерь?
On Mon, Feb 05, 2024 at 02:40:42PM +0300, Anatoliy Melnik via nginx-ru wrote: >syslog-ng при работе с unixSocket показал довольно низкую >производительность. (Долго с ним не разбирался. Чисто дефолтная установка >и минимальная настройка). Syslog-ng производит огромное количество ненужных (на мой взгляд) сисколов при работе с unix-сокетами, к тому же пытается то, что отдаётся в syslog(3), подменить на более "правильную", по мнению автора, информацию... Например, выправить pid, если писатель нарисовал чужой (наверное, это такая забота о безопасности). Всё очень трогательно, но эта забота выливается в большие накладные расходы. Под большую нагрузку syslog-ng явно не заточен. -- Eugene Berdnikov ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Тест nginx -- сколько сообщений в log syslog без потерь?
И снова Здравствуйте :)
Итак конечный вариант решения:
В конфиге nginx вот такая конструкция
map "$remote_port" $log_selector_0 {
default 0;
~0$ 1;
}
map "$remote_port" $log_selector_1 {
default 0;
~1$ 1;
}
map "$remote_port" $log_selector_2 {
default 0;
~2$ 1;
}
map "$remote_port" $log_selector_3 {
default 0;
~3$ 1;
}
map "$remote_port" $log_selector_4 {
default 0;
~4$ 1;
}
map "$remote_port" $log_selector_5 {
default 0;
~5$ 1;
}
map "$remote_port" $log_selector_6 {
default 0;
~6$ 1;
}
map "$remote_port" $log_selector_7 {
default 0;
~7$ 1;
}
map "$remote_port" $log_selector_8 {
default 0;
~8$ 1;
}
map "$remote_port" $log_selector_9 {
default 0;
~9$ 1;
}
.
access_log
syslog:server=unix:/run/socket-00,nohostname,facility=local5,severity=info,tag=nginxStats01
st01 if=$log_selector_0;
access_log
syslog:server=unix:/run/socket-01,nohostname,facility=local5,severity= info
,tag=nginxStats01 st01 if=$log_selector_1;
access_log
syslog:server=unix:/run/socket-02,nohostname,facility=local5,severity= info
,tag=nginxStats01 st01 if=$log_selector_2;
access_log
syslog:server=unix:/run/socket-03,nohostname,facility=local5,severity= info
,tag=nginxStats01 st01 if=$log_selector_3;
access_log
syslog:server=unix:/run/socket-04,nohostname,facility=local5,severity= info
,tag=nginxStats01 st01 if=$log_selector_4;
access_log
syslog:server=unix:/run/socket-05,nohostname,facility=local5,severity=info,tag=nginxStats01
st01 if=$log_selector_5;
access_log
syslog:server=unix:/run/socket-06,nohostname,facility=local5,severity= info
,tag=nginxStats01 st01 if=$log_selector_6;
access_log
syslog:server=unix:/run/socket-07,nohostname,facility=local5,severity= info
,tag=nginxStats01 st01 if=$log_selector_7;
access_log
syslog:server=unix:/run/socket-08,nohostname,facility=local5,severity= info
,tag=nginxStats01 st01 if=$log_selector_8;
access_log
syslog:server=unix:/run/socket-09,nohostname,facility=local5,severity= info
,tag=nginxStats01 st01 if=$log_selector_9;
Данные почти равномерно расходятся по 10-ти файлам, которые пишутся на tmpfs в
RAM.
Отказался и от rsyslog и от syslog-ng
В качестве принимающей стороны выступает пока python скрипт
В нем стартую 10 процессов, каждый слушает свой сокет и вся его задача --
сложить в файл данные.
Отказ от rsyslog-а обусловлен просто огромным количеством переключений
контекста, rsyslog-ом генерируемое.
Уже на 200-210тыс/сек их количество переваливает за 1.4 млн/сек. ( примерно
0.9млн - работа rsyslog-а) и на этой отметке сильно деградирует
производительность системы в целом.
syslog-ng при работе с unixSocket показал довольно низкую производительность.
(Долго с ним не разбирался. Чисто дефолтная установка и минимальная настройка).
python по сравнению с rsyslog ЦПУ потребляет немного больше, но переключений
контекста значительно меньше, и это положительно сказывается на работе всей
системы.
Как итог -- проверен порог в 220-230 тыс/сек (такая нагрузка сохранялась около
3-х часов) на 1 nginx, на моем железе все отработало нормально, все метрики
сошлись.
Попытка с UDP -- больше потребление CPU, больше прерываний, больше переключений
контекста...
И если 220-230 тыс/сек на 10 unixSocket -еще не предел для моего железа, то те
же 220-230 тыс/сек на udp на loopback интерфейс практически предел судя по
мониторингу.
Всем еще раз спасибо за внимание и советы.
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru
Зеркало https://hg.nginx.org/pkg-oss на github
Здравствуйте! Нельзя ли добавить на github зеркало сабжевого репа? Используем его для сборки nginx и модулей (отсутствующих в официальной поставке), зеркалируем реп во внутренний гитлаб, хотелось бы убрать костыли типа mercurial 2 git. С уважением, Иван. ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginxQuic: скорость загрузки при активации kTLS
Добрый день, Максим. Ясно, благодарю за пояснение :) Вы писали 5 февраля 2024 г., 11:40:55: > Hello! > Это какая-то внутренняя история curl'а про борьбу с неэффективным > демультиплексингом, к nginx'у не имеет отношения примерно > никакого, да и в самом curl'е относится только к случаю получения > нескольких файлов одновременно по одному соединению. -- С уважением, Izorkin mailto:izor...@gmail.com ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginxQuic: скорость загрузки при активации kTLS
Hello! On Sun, Feb 04, 2024 at 10:03:56AM +0300, izor...@gmail.com wrote: > Добрый день, Максим. > > Сегодня увидел, что разработчики избавились от буферов приёма и > создали новый способ разгрузки для протокола HTTP/2: > https://github.com/icing/blog/blob/main/curl-h2-perf-evolution.md > https://github.com/curl/curl/pull/12828 > > Реализации аналогичного варианты в Nginx как-то поможет для ускорения > работы с протоколом HTTP/2? Это какая-то внутренняя история curl'а про борьбу с неэффективным демультиплексингом, к nginx'у не имеет отношения примерно никакого, да и в самом curl'е относится только к случаю получения нескольких файлов одновременно по одному соединению. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
