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
