Gena Makhomed Wrote:
-------------------------------------------------------
> On 19.02.2024 16:01, Anatoliy Melnik via nginx-ru wrote:
>
> >>>> Если вы предлагаете писать напрямую с nginx-а в файл --
> >>>> сделайте у себя ротацию файлов с интервалом 30 сек
> >>>> при 200-250 тыс подключений/сек...
> >>>>
> >>>> Если у вас уже есть такое рабочее решение -
> >>>> поделитесь опытом, буду рад вас выслушать.
> >>>
> >>> Я намеренно ввел вас в заблуждение путем публикации сообщения,
> >>> допускающее двойное толкование в ту или иную сторону по желанию
> >>> сторон.
> >>
> >> Почему / зачем?
> >
> > Был шанс увидеть в ответ нестандартное решение.
>
(мантры про логи...)
>
> Какое именно "нестандартное решение" для вышеобозначенной проблемы
(мантры....)
Если вам его не видно -- это не значит, что его нет.
Тот же костыль из юникс-сокета у меня в "альфа" версии на этапе проверки
возможностей
показал результат в 400тыс/сек с запасом.
Кстати от вас я так и не увидел ни одной ссылки на конкретные значения из
вашего личного опыта.
Лично мой опыт показывает, что при значениях более 500тыс/сек и примерно 1млн
"живых" tcp сессий "падает" уже сама ось.
Если у вас есть конкретный пример, что на таком-то железе, такой-то оси вы
"перевариваете" 1млн/сек -- отлично.
Если нет... Ну на нет и суда нет.
>
> >> С моей точки зрения более важным является обеспечение более
> высокой
> >> надежности работы системы, чтобы логи не терялись в процессе
> записи,
> >> чем экономия свободного места на диске и экономия ресурсов NVMe
> SSD.
> >>
> >> Поэтому с моей точки зрения - я не могу признать решение
> >> через syslog и unix socket более оптимальным, чем вариант
> >> записи логов напрямую в файлы и ротации логов через SIGUSR1.
> >>
> >> а ротацию логов можно делать и чаще, чем раз в 30 секунд,
> >> например, раз 15, или раз в 10 или даже раз в 5 секунд,
> >> если хочется уменьшить отставание статистики по времени.
> >>
> >> По сути - лог-файл на диске - это можете воспринимать примерно,
> >> как то же самое, что и unix socket, только с буфером не в памяти,
> >> а в виде файла на диске и без существенных ограничений по размеру
> >> такого буфера, что будет лучше сглаживать всплески нагрузки
> >> и может позволить большую асинхронность между процессом
> >> записи информации в лог и процессом чтения информации
> >> из лога. А во всем остальном - никакой существенной
> >> разницы нет, учитывая только что запись логов в файлы
> >> меньше грузит процесор и использует немного больше
> >> свободного места на диске.
> >>
> >> Но мне например, лучше чтобы процессор был немного свободнее,
> >> чем проистаивающее и никак не используемое место на диске.
> >>
> >> Но самое главное - что запись логов в файлы не приводит к потере
> >> данных, а запись логов в unix socket может приводить к потерям
> >> даных, если читатель будет не успевать забирать данные из unix
> >> socket.
> >>
> >> Более надежное и более простое решение, и более экономно
> >> расходующее процесор сервера - и будет более оптимальным.
>
> > пока я наблюдал скорее проблему "писатель не успевает записывать",
> > а не "читатель не успевает забирать".
>
> видимая Вами проблема "писатель не успевает записывать"
> вызвана именно тем, что "читатель не успевает забирать".
>
> Потому что когда у Вас был всего один читатель - он не успевал
> читать данные из syslog и поэтому у nginx не было никаких других
> вариантов, кроме как дропать часть сообщений. После того как вместо
> одного читателя Вы сделали 10 читателей - они начали успевать читать
> данные из syslog и проблема с потерей сообщений стала быть Вам не
> видна.
>
Вы, как и всегда, имеете полное право на свое мнение.
> > Эта же проблема и при файлах присутствует -- NVME не у всех всегда
> везде.
> > Система дисковая как ни крути - общий ресурс, и если ее интенсивно
> нагрузить
> > чем-то еще логи тоже могут получить проблему читатель-писатель.
>
> На frontend-сервере, сеть может быть загружена на 100% передачей
> данных,
> и процессор может быть загружен на 100% шифрованием/расшифровской
> TLS.
> Дисковая подсистема может использоваться только для записи логов.
>
> нагружать дисковую подсистему чем-либо еще, крмое записи логов
> - нерационально, имеет смысл даже полностью выключить использование
> диска при проксировании, чтобы не было блокирования nginx на
> операциях
> дискового ввода-вывода и чтобы не было увеличения latency, когда
> этого
> можно очень просто ибежать:
>
> proxy_http_version 1.1;
> proxy_request_buffering off;
> proxy_max_temp_file_size 0;
>
> По поводу того, что сейчас NVMe есть не у всех и не всегда
> - это Вы мне сейчас из какого года свое сообщение пишете ?
Вы, как и всегда, имеете полное право на свое мнение.
Свой набор критериев оптимальности и эффективности.
>
> > Единственный плюс прямой записи в файл -- это длительное хранение
> данных, чего лично мне вот вообще не требуется.
>
> У Вас очень специфически задачи. Потому что как правило логи нужны.
Что и было описано еще в самом начале.
> Потому что если логи не нужны - их просто выключают для 1хх, 2хх
> и 3хх статусов и логгируют только 4хх и 5хх ошибки, так что размер
> лог-файлов получается очень небольшим и никаких проблем создать не
> может.
>
> map $status $loggable {
> ~^[45] 1;
> default 0;
> }
> access_log /path/to/access.log combined if=$loggable;
>
> >> Вот как я уже говорил, задача построения VPN - если взять все
> множество
> >> таких задач, то в части случаев для построения VPN более
> оптимальным
> >> вариантом будет использование WireGuard, а в части случаев -
> OpenVPN.
> >> Именно потому, что WireGuard обладает некоторыми свойствами
> >> и качествами, которые отсутствуют в OpenVPN, и наоборот,
> >> потому что OpenVPN обладает некоторыми свойствами и качествами,
> >> которые отсутствуют в WireGuard. И поэтому в части случаев
> >> оказывается более оптимальным и целесообразным построение
> >> VPN с использованием WireGuard, а в некоторых случаях
> >> - более оптимальнныи и целесообразным оказывается
> >> построение VPN с использованием OpenVPN.
> >>
> > И в части случаев оба они окажутся в равной степени не пригодны...
> > Да и там, где пригодны, далеко не всегда оптимальны по каким-то
> критериям.
> > VPN технологий существуют десятки. Но вы почему-то в этом посте
> ограничились 2-мя.
> > А как же "все множество путей" ?
> > Эти 2 достаточно удобны для решения большого круга задач -- это да,
> но это не отменяет достоинств других VPN-ов.
>
> Я рассматриваю только те реализации VPN, которые доступны
> в виде open source, и которые доступны для использования,
> без необходимости покупать лицензию на право использования
> программы.
>
> Все другие варианты Open Source VPN имеет смысл рассматривать
> только в том случае, если они имеют какие-то преимущества,
> по сравнению с WireGuard и OpenVPN. Если у них никаких
> преимуществ нет - тогда их можно и не рассматривать.
>
> Еще есть Shadowsocks, если необходимо обходить
> блокировки WireGuard и OpenVPN через DPI,
> но это очень специфическая задача.
В openssh-е есть "встроенный" socks5. Можно вообще без дополнительного ПО
обойтись.
Довольно долгое время вообще ppp over ssh пользовался и более чем устраивало.
Но опять же.
Вы, как и всегда, имеете полное право на свое мнение.
Свой набор критериев оптимальности и эффективности.
>
> WireGuard и OpenVPN - это две наиболее надежные
> по качеству кода и наиболее проверенные аудитами
> реализации VPN. По этому парметру - все остальные
> реализации и варианты VPN - значительно хуже.
>
> Например, в самом протоколе IPsec или в его популярных реализациях
> могут быть закладки от NSA, поэтому IPsec лучше не использовать.
> https://en.wikipedia.org/wiki/IPsec#Alleged_NSA_interference
>
> >> Так ведь свободное место на разделе есть, с этим же нет проблем.
>
> > Есть проблема.
> > В исходной постановке (когда сия задача встала передо мной) задачи
> было пожелание обойтись имеющимся ресурсом.
> > Я задачу решил именно в этих начальных условиях.
>
> Как правило, свободное место на диске - это самый дешевый ресурс.
> И экономить место на диске, увеличивая нагрузку на процессор,
> или теряя часть сообщений - это не самое лучшее решение.
Вы, как и всегда, имеете полное право на свое мнение.
Свой набор критериев оптимальности и эффективности.
>
> >>> с моей точки зрения менять одну проблему на другую смысла нет
> >>
> >> использование места на диске - это не проблема, это необходимая
> плата
> >> за то, что запись в логи будет происходить без потерь информации,
> >> и что чтения и обработка информации из логов не обязаны быть
> >> такими синхронными и производительными, как в случае с unix
> >> socket`ами.
> >>
> > Обязаны! и синхронными и производительными.
> > Если статистика будет накапливаться быстрее, чем обрабатываться, то
> данные никогда не будут актуальны.
> > Т.е. я сегодня увижу статистику за вчера, а за сегодня-- только
> через 2 дня, а к концу года буду видеть уже с отставанием в месяц??
> > И кому это будет интересно??
>
> Вы меня не поняли.
>
> Если использовать unix socket - при переполнении буфера
> в памяти происходит потеря части сообщений. Если в условиях
> постановки задачи важно не терять сообщения - тогда читатель
> сообщений должен быть таким же производительным и как писатель.
>
> Иногда, во время DDoS-атак приходит огромное количество запросов,
> так что процессор может быть занят на 100% и просто не остается
> на сервере процессорных мощностей для того, чтобы читатель
> с другой стороны unix socket`а успевал бы считывать данные
> с такой же скоростью, с какой их будет писать туда nginx.
> А это означает, что такая ситуация неизбежно приведет
> к потере части сообщений, которые nginx будет вынужден
> дропать потому что читатель не успевает их читать
> с другой стороны unix socket`а.
>
> Мне такое нестабильно работающее и ненадежное решение не нужно,
> которое вроде бы нормально работает под небольшой нагрузкой,
> но начинает глючить и терять сообщения, когда нагрузка возрастает.
>
> Если же nginx пишет логи в файл - тогда такой высокой степени
> синхронности читателя и писателя логов не нужно, пототому что
> нет буфера в памяти, который очень быстро может переполниться,
> а есть просто файлы на диске, и читатель логов может читать их
> с постоянной скоростью, например, 1 мегабайт в секунду, и даже
> если будут всплески нагрузки на сервер и в какие-то моменты
> nginx будет писать логи со скоростью 10 или 100 мегабайт в секунду
> - это все равно не будет приводить к потере сообщений, потому что
> в этом случае нет небольшого буфера в оперативной памяти, а роль
> буфера выполняет фактически все свободное место на диске сервера.>
> И пиковые всплески нагрузки на сервер будут сглаживаться с помощью
> очень большого "буфера" на диске, и потери сообщений тогда не будет.
>
> То есть, при всех прочих условиях, более надежная и более устойчивая
> к всплескам нагрузки система обработки логов nginx которая не теряет
> сообщения является более предпочтительной, чем та система, которая
> теряет часть сообщений в процессе работы при всплесках нагрузки.
>
> В большинстве случаев потери сообщений недопустимы
> или крайне нежелательны, поэтому запись сообщений
> напрямую в лог-файлы, без дополнительных костылей
> через syslog и unix socket`ы практически всегда
> будет более предпочительным вариантом.
>
> Тем более, что работающее решение для ротации логов nginx
> при 200-250 тысячах подключений в секунду и интервале ротации
> раз в 30 секунд можно очень легко получить, заменив SIGHUP на
> SIGUSR1.
> Это есть ответ на тот Ваш вопрос о решении Вашей настоящей проблемы
> X,
> который приведен в самом начале этого сообщения.
>
Вы, как и всегда, имеете полное право на свое мнение.
Свой набор критериев оптимальности и эффективности.
> > Итоги разных экспериментов:
> > Исходные данные - 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% и
> > зависимости результата от файлового ввода-вывода.
>
> парсинг лога не только самый быстрый, он еще и самый надежный,
> потому что в этом варианте нет потери сообщений. - Собственно,
> о чем я Вам и говорил, что это есть самый оптимальный вариант.
>
> нагрузку на сеть можно уменьшить, включив HTTP/1.1 и keepalive
> при подключении к backend`у - это если делать обработку логов
> именно через mirror на специально выделенный для этой задачи сервер.
>
> Вы же не рассмотрели вариант, когда nginx сам пишет логи напрямую
> в файл, например, блоками по 1 мегабайту, делая всего один системный
> вызов для записи одного такого блока информации. Насколько
> я понимаю, при N рабочих процессах nginx для этого потребуется
> дополнительно всего лишь только N мегабайт оперативной памяти.
> Но в результате - получим значительное уменьшение расходования
> процессора на запись логов и значительно меньшее количество
> операций переключения контекста, ведь по умолчанию вызывается
> операция записи для каждой строчки лога.
Вы, как и ранее, совершенно спокойно решаете за меня что я делал, а чего не
делал.
Еще на старте я указал, что
"долго, кучно, с кучей подробностей.... и абсолютно бесполезно."
Вы с блеском подтвердили этот тезис.
Дальнейшее обсуждение не имеет смысла.
>
> > Таким образом единственный сколь-нибудь существенный бонус -
> потенциальная полнота данных для обработки перестает быть
> существенным, когда считаем
> > усредненные данные на миллионных выборках.
>
> полнота даных для обработки - как правило это важно.
>
> если Вам нужны усредненные данные на милионных выборках -
> тогда с технической точки зрения, самым оптимальным вариантом
> будет написать модуль для nginx, который будет делать эту работу
> на лету и практически мгновенно и практически с 0 затратами ресурсов.
Ок. Встанет перед вами такая задача -- вы выберете соответствующий путь ее
решения.
>
> > Не знаю насколько эффективен будет Go.
>
> Go создан достаточно умными людьми,
> такими как Роб Пайк, один из создателей кодировки UTF-8.
>
> Go позволяет сделать concurrency используя goroutines и channels,
> и этот язык программирования, созданный в Google практически
> идеально подходит для работы в состоянии высоких нагрузок,
> позволяя быстро писать быстрый, качественный и надежный код,
> который легко справляться даже с очень высокими нагрузками.
Без проблем -- пишете, тестируете, выкладываете сюда сравнительные результаты.
С числами, процентами, погрешностями и т.д. в конкретной задаче.
>
> Если производиельности которую дает Go будет не хватать,
> тогда остается только Rust, C++ и C, но обычно - дешевле
> и проще будет просто горизонтальное масштабирование,
> путем увеличения количества серверов для вебсайта.
>
> Если нет highload, тогда удобнее и приятнее Python,
> и скорость написания кода будет выше, но скорость
> работы кода будет ниже - вот такой тут trade-off.
>
> > Он должен на порядок превосходить какой-нибудь php
>
> Он превосходит. Поэтому практически весь highload делают
> сейчас именно на Go а не на PHP, если есть возможность выбора
> и нет необходимости работать с большим количеством legacy кода.
"Он превосходит" и "он превосходит на порядок" -- несколько разные
формулировки.
Но у вас есть возможность показать это практически -- пишете 2 реализации
одного и тогоже функционала на Go и НЕ_Go,
сравниваете, затем сравниваете с "тупо 200 всем прям с nginx-а" и обнародуете
результат.
На даном этапе лично я свой "костыль" довел до альфа-версии инвалидского кресла
с моторчиком :)
Проверяю возможность автоматического противодействия ДДоС-у почти в реальном
времени.
Но это уже совсем другая история.
>
> --
> 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
