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 есть не у всех и не всегда
> - это Вы мне сейчас из какого года свое сообщение пишете ?
Вы, как и всегда, имеете полное право на свое мнение.
Свой набор критериев оптимальности и эффективности.
>
> > Единственный плюс прямой записи в файл -- это длительное хранение
> данных, чего лично мне вот вообще не требуется.
>
> У
