Gena Makhomed Wrote:
-------------------------------------------------------
> On 15.02.2024 12:49, Anatoliy Melnik via nginx-ru wrote:
>
> >>>>> Если вы предлагаете писать напрямую с nginx-а в файл --
> >>>>> сделайте у себя ротацию файлов с интервалом 30 сек
> >>>>> при 200-250 тыс подключений/сек...
> >>>>>
> >>>>> Если у вас уже есть такое рабочее решение -
> >>>>> поделитесь опытом, буду рад вас выслушать..
>
> > "Я намеренно ввел вас в заблуждение путем публикации сообщения,
> допускающее двойное толкование в ту или иную сторону по желанию
> сторон."
>
> Почему / зачем?

Был шанс увидеть в ответ нестандартное решение.

>
> > Дальнейшее перемалывание темы ротации лично для меня интереса не
> представляет..
>
> Тогда прекращаем.
>
> >>> Вы почему-то упорно пытаетесь отказать мне в праве самостоятельно
> >>> решать что мне надо :)
>
> Так я и не пытался решать за Вас, как именно будет лучше поступить
> в Вашей конкретной ситуации - скорее я рассматривал все множество
> задач сбора статистики и обработки информации из логов - и на всем
> этом множестве задач старался увидеть наиболее оптимальный способ
> решения задачи, если абстрагироваться от затрат времени
> и сил на реализацию решения в виде програмного кода.
>
Т.е. насколько я понимаю некоего идеального коня в сферическом вакууме.
Не получиться "универсальный анализ логов".
мне нужны средние, кому-то подавай количество больше чем, кому-то нужен разброс будет от min до max.
Например 100 коннектов по 1К и 100 по 1М для кого-то то же самое, что и 200 по 0.5005М, а для кого-то это суперважно.
соответственно и обработка разной получится. в 1 проход или в 2.


> >> Решайте сами, я просто хотел понять Вашу исходную задачу X,
> >> поэтому и задавал уточняющие вопросы.
>
> > Спасибо. Как уже упоминалось ранее -- по озвученной на самом старте
> теме я уже все решил.
>
> С моей точки зрения более важным является обеспечение более высокой
> надежности работы системы, чтобы логи не терялись в процессе записи,
> чем экономия свободного места на диске и экономия ресурсов NVMe SSD.
>
> Поэтому с моей точки зрения - я не могу признать решение
> через syslog и unix socket более оптимальным, чем вариант
> записи логов напрямую в файлы и ротации логов через SIGUSR1.
>
> а ротацию логов можно делать и чаще, чем раз в 30 секунд,
> например, раз 15, или раз в 10 или даже раз в 5 секунд,
> если хочется уменьшить отставание статистики по времени.
>
> По сути - лог-файл на диске - это можете воспринимать примерно,
> как то же самое, что и unix socket, только с буфером не в памяти,
> а в виде файла на диске и без существенных ограничений по размеру
> такого буфера, что будет лучше сглаживать всплески нагрузки
> и может позволить большую асинхронность между процессом
> записи информации в лог и процессом чтения информации
> из лога. А во всем остальном - никакой существенной
> разницы нет, учитывая только что запись логов в файлы
> меньше грузит процесор и использует немного больше
> свободного места на диске.
>
> Но мне например, лучше чтобы процессор был немного свободнее,
> чем проистаивающее и никак не используемое место на диске.
>
> Но самое главное - что запись логов в файлы не приводит к потере
> данных, а запись логов в unix socket может приводить к потерям
> даных, если читатель будет не успевать забирать данные из unix
> socket.
>
> Более надежное и более простое решение, и более экономно
> расходующее процесор сервера - и будет более оптимальным.
>

1. Т.к. мне практически всегда нужны некоторые усредненные данные,
то абсолютная полнота статистики не является основным условием.
Хорошо, если она присутствует, но и если потеряно даже половина данных --
на средних значениях это слабо скажется :)
2. пока я наблюдал скорее проблему "писатель не успевает записывать",
а не "читатель не успевает забирать".
Эта же проблема и при файлах присутствует -- NVME не у всех всегда везде.
Система дисковая как ни крути - общий ресурс, и если ее интенсивно нагрузить
чем-то еще логи тоже могут получить проблему читатель-писатель.
Сжатие на лету -- это не только ресурс CPU при сжатии перед записью, это еще и
ресурс при распаковке для анализа, у меня это происходит со всеми данными.
Т.е. если nginx потратил ресурс на запаковку, то я в ответ должен потратить ресурс на распаковку...
И где тут экономия CPU??
Мое мнение:
Единственный плюс прямой записи в файл -- это длительное хранение данных, чего лично мне вот вообще не требуется.

При необходимости обработки и анализа полученных данных пока опыт эксплуатации показывает преимущества юникс-сокета.
Об этом чуть ниже.

> > При желании добраться из пунта А в пункт Б именно на машине и
> проблеме "машина не едет" 2 концептуальных решения:
> > 1.Заменить машину.
> > 2.Устранить причины "не едет" в имеющейся.
> > Соответственно 2 пути -- ищем другую машину, или меняем вышедшую из
> строя запчасть.
> > Если провести параллели, то с моей точки зрения мне вполне
> достаточно запчасти.
> > Вы предлагаете замену машины.
>
> Не так, я скорее рассматриваю одновременно все множество путей
> из точки А в точку Б для различных вариантов А и Б и различных
> внешних условий и стараюсь понять, какой именно автомобиль,
> с какими именно параметрами будет наиболее оптимальным
> решением для такой задачи - перемещения их точки А в точку Б.
>
Вертолет и телепортацию не забудьте :)
Учитывая ваши слова "если абстрагироваться от затрат времени
и сил на реализацию решения..."


> Вот как я уже говорил, задача построения VPN - если взять все
> множество
> таких задач, то в части случаев для построения VPN более оптимальным
> вариантом будет использование WireGuard, а в части случаев - OpenVPN.
> Именно потому, что WireGuard обладает некоторыми свойствами
> и качествами, которые отсутствуют в OpenVPN, и наоборот,
> потому что OpenVPN обладает некоторыми свойствами и качествами,
> которые отсутствуют в WireGuard. И поэтому в части случаев
> оказывается более оптимальным и целесообразным построение
> VPN с использованием WireGuard, а в некоторых случаях
> - более оптимальнныи и целесообразным оказывается
> построение VPN с использованием OpenVPN.
>
И в части случаев оба они окажутся в равной степени не пригодны...
Да и там, где пригодны, далеко не всегда оптимальны по каким-то критериям.
VPN технологий существуют десятки. Но вы почему-то в этом посте ограничились 2-мя.
А как же "все множество путей" ?
Эти 2 достаточно удобны для решения большого круга задач -- это да, но это не отменяет достоинств других VPN-ов.


> >> Получить потери можно в случае использования syslog
> >> и unix socket`ов - если читающая сторона не будет
> >> успевать читать данные из сокета - у nginx не останется
> >> иных варантов, кроме как дропать часть записей.
> >>
> >> При записи логов в файлы - этот вариант исключен,
> >> если на разделе есть достаточное количество свободного места.
> >>
> > О появились доп. условия -- место на разделе...
>
> Так ведь свободное место на разделе есть, с этим же нет проблем.
Есть проблема..
В исходной постановке (когда сия задача встала передо мной) задачи было пожелание обойтись имеющимся ресурсом.
Я задачу решил именно в этих начальных условиях.

>
> Если часто делать ротацию логов - его надо будет совсем не много.
>
> Тем более, что можно включить компрессию логов на лету, если надо.
>
Повторюсь: я уже просто запись в файл счел лишним этапом,
а уж сопутствующие этому затраты на компрессию-декомпрессию только в минус.
> >> Хотя бы даже одним только этим свойством запись логов в файлы
> >> намного лучше записи логов в unix socket`ы.
>
> > А как же место на разделе? Замена одной проблемы другой. Только и
> всего.
>
> У Вас разве есть проблемы со свободным местом на разделе?
> тогда включите компрессию логов на лету - свободного места
> потребуется меньше, ресурсов процессора будет использовано
> больше. Только и всего. Это не проблема, это лишь tradeoff.
>
И еще раз повторюсь -- что мешает мне на концептуальном уровне
просто изменить подход так, чтоб эта проблема даже на горизонте не маячила?



> > Т.е. Проблему X -- расхождение при использовании сокета, вы меняете
> на проблему У -- достаточное количество места
> > и производительность системы ввода-вывода, просто с вашей точки
> зрения это как-бы и не проблема вовсе
>
> Количество свободного места на разделе - это не проблема, потому что
> Thin provisioning и все разделы виртуальных машин имеют логический
> размер в 50 TiB, - я бы сделал и больше, но Red Hat не рекомендует.
Это тут вообще к чему?

>
> > с моей точки зрения менять одну проблему на другую смысла нет
>
> использование места на диске - это не проблема, это необходимая плата
> за то, что запись в логи будет происходить без потерь информации,
> и что чтения и обработка информации из логов не обязаны быть
> такими синхронными и производительными, как в случае с unix
> socket`ами.
>
Обязаны! и синхронными и производительными.
Если статистика будет накапливаться быстрее, чем обрабатываться, то данные никогда не будут актуальны.
Т.е. я сегодня увижу статистику за вчера, а за сегодня-- только через 2 дня, а к концу года буду видеть уже с отставанием в месяц??
И кому это будет интересно??


> > Вот вам идея оптимального по большинству критериев решения --
> > Когда будете решать сходную задачу напишите свой модуль для nginx
> > Чтоб сразу считать все нужное "внутри" без посредников.
> > Я такое решение тоже рассматривал, отказался.
> > Лично мои трудозатраты по реализации такого подхода превосходят все
> разумные пределы.
> > Что и стало ключевым фактором "против".
>
> Такой модуль уже есть, Angie умеет экспортировать данные
> напрямую в Prometheus. Если бы у njs была возможность разделять
> данные между worker`ами, то можно был бы пряом через njs это делать.
> И скорее всего - это можно уже сейчас запрограммировать на lua,
> используя в качестве веб-сервера OpenResty, там есть доступ
> к разделяемой памяти. Или - просто парсить логи и все,
> это будет и быстрее и проще, чем unix socket`ы, IMHO.

Нет там нужных мне метрик. И быть не может :)
Метрика по параметру в GET/POST запросе, усредненная за 60 секунд...

Итоги разных экспериментов:
Исходные данные - CPU Xeon E5-26xx v4 CPU 2.2GHz
Для наглядности привожу данные по 1 вычислительному ядру.
Итак, на 1 вычислительное ядро
--- Существующий на данный момент бекэнд, куда nginx у меня проксирует запросы -- максимум около 2000 в секунду на одно ядро (вообще не моя епархия, но там точно НЕ php).
--- NGINX для теста, на который отзеркалированы запросы, вся его функция -- выдать ответ "200" и сообщение в лог записать, все, никакого проксирования или отдачи контента,
никаких вычислений и т.д. Голый "200" + строка в лог-файле средствами nginx-а, ротация 10 секунд с удалением результата. --- максимум примерно 10 000 в секунду на 1 ядро
--- парсинг данных из лога, накопленного за 60 секунд из расчета нагрузки 400тыс/сек, т.е. 24млн строк. -- на одном ядре от 8 минут. в зависимости от нагрузки на дисковую подсистему 8-9 минут. т..е. при среднем 500секунд 48 000 в секунду на одно ядро.
--- Обработка через юникс-сокет "на лету" python3.9 скриптом -- 43 000 в секунду на одно ядро 100% соответствие результатов, около 89-92% занятость ядра CPU.

Итого технически "самый быстрый" -- парсинг лога, но тянет за собой запись-чтение-удаление при относительном преимуществе 9-12% и
зависимости результата от файлового ввода-вывода.
а по факту на общей нагрузке системы потенциальный выигрыш составляет 1,5-2% от производительности системы, т.к. это задача вторая, а первая -- проксирование, и она "кушает" гораздо больше парсинга.
Возможно оптимизацией парсинга можно добиться и повышя скорости, выигрыш составит еще 1,5%...
А из расчета загрузить сокет-питон на 100% и это преимущество теряется.

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

Зеркалирование -- проигрывает по всем параметрам.
код принимаюшей стороны должен быть эффективнее nginx-а (отвечающего всем "200") в 5 раз для реального выигрыша над юникс-сокет+питон.
Не знаю насколько эффективен будет Go. Но честно говоря даже не вижу смысла проверять.
Он должен на поррядок превосходить какой-нибудь php, а по обнаруженным данным там разница в 3-5 раз, а надо минимум в 10 для того, чтоб это имело хоть какой-то смысл в данной конкретной задаче.
Могу и ошибаться.



>
> --
> 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