Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"В systemd-journald спустя 6 лет признали проблему избыточной нагрузки на накопители"	+/–
Сообщение от opennews (??), 15-Авг-26, 00:23
Разработчики проекта systemd приступили к изучению и устранению давней архитектурной проблемы в компоненте "systemd-journald", приводящей к многократному завышению объёма записываемых на диск данных (write amplification) по сравнению с фактическим объёмом логов... Подробнее: https://www.opennet.me/opennews/art.shtml?num=66082
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
Сообщение от Аноним (1), 15-Авг-26, 00:23
Всю жизнь монтирую /var/log в tmpfs кстати.
Ответить | Правка | Наверх | Cообщить модератору

	2. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+4 +/–
	Сообщение от Аноним (2), 15-Авг-26, 00:25
	Удачи потом в расследовании инцидентов.
	Ответить | Правка | Наверх | Cообщить модератору

	15. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (15), 15-Авг-26, 01:04
	Можно подумать, что ты хоть раз расследовал на гигабайтах логов. Есть смысл временно включать, чтобы проверить почему падает отдельная служба, но держать на постоянке и никогда туда не смотреть... ну ты сам себе буратино.
	Ответить | Правка | Наверх | Cообщить модератору

	19. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (2), 15-Авг-26, 01:21
	Гигабайты там и не нужны. Хватает 100 строчек выхлопа тогоже ядра, чтобы понять, почему вся система отъехала. К слову, актуально даже на десктопе с теме же амдешными, кривыми GPU дровами.
	Ответить | Правка | Наверх | Cообщить модератору

	16. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (16), 15-Авг-26, 01:06
	> Удачи потом в расследовании инцидентов. Может он эти инциденты и создает? "В расследовании главное не выйти на самого себя!"
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

3. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
Сообщение от Аноним (3), 15-Авг-26, 00:35
И года не прошло.. А хотя не, прошло) 6!
Ответить | Правка | Наверх | Cообщить модератору

	6. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (6), 15-Авг-26, 00:49
	А как пели: бинарный формат, это не партянки, всё быстро...
	Ответить | Правка | Наверх | Cообщить модератору

	12. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–1 +/–
	Сообщение от Аноним (16), 15-Авг-26, 00:59
	>  А как пели: бинарный формат, это не партянки, всё быстро... А оно и правда - быстро. Скажем я могу более-менее в реальном времени парсить "все сообщения от sshd". Префильтр и индексированный доступ - обеспечит сам journald. И сообщение таки - можно атомарно читануть от и до. В текстовом же случае... 1) Вы вообще сами будете искать где граница между сообщениями. Мало того что это пригрузит проц - так вы еще и облажаться рискуете, когда атакующий в какой-нибудь юзернейм или что там 0x0d, 0x0a, 0x0 или что там воткнет - парсинг текста сорвется - и вы получите неполные или поддельные записи логов под контролем атакующего вообще. Что может быть использовано для обхода банов, крафтинга банов совершенно непричастным айпишникам и проч. 2) Парсинг гигз логов - нифига не быстро. А без этого - как вы вообще получите знание "сколько запросов с этого IP было за последние 5 минут"? Вот то то и оно - трекать такие вещи с текстовиками - потребует опять же юзать бинарные бд для всяких индексов - и вообще enterprise-grade soultion. Который настолько монструозен что будет у полутора коопрв. А доморощенные админы будут сиять голым окороком - доказывая что и так сойдет!
	Ответить | Правка | Наверх | Cообщить модератору

4. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
Сообщение от Аноним (4), 15-Авг-26, 00:35
А я думал это норма, что что все эти лог журналы насилуют твой ссд, чтобы потом форензик экспертам было легче копаться в твоих штанах.
Ответить | Правка | Наверх | Cообщить модератору

	8. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 15-Авг-26, 00:52
	>  А я думал это норма, что что все эти лог журналы насилуют твой ссд, > чтобы потом форензик экспертам было легче копаться в твоих штанах. Да не парься ты так - форенсики с твоего SSD и с якобы-in-place файлухи вынут кучу данных с твоего SSD. Потому что флеш память не умеет in place перезаписи, внезапно. А стирание медленное и крупноблочное. Так что контроллер - всяко почти наверняка CoW сделает. И если читануть NAND напрямую без его услуг по пропуску лишнего... Кстати, "secure" erase с явным протиранием нулями региона - тоже так не сработает. Оно протрет нолями ДРУГОЙ регион SSD. Вот явный запрос TRIM конкретного региона - еще может какую-то пользу принести. Только это блочный уровень, ФС сами по себе без явного прокостыливания такими вещами не оперируют.
	Ответить | Правка | Наверх | Cообщить модератору

5. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–3 +/–
Сообщение от Аноним (-), 15-Авг-26, 00:48
> В данном случае разработчики systemd продемонстрировали > типичный для корпоративного Open Source подход В данном случае опеннетчики продемонстрировали типичный подход: много критиканить других и мало делать самим. А ваши текстовые логи - это прекрасно. Кроме того момента что даже просто банить околореалтаймно ботов по ним адское мучение. И либо дичайше жрет проц на парсинг гигабайтов - либо требует навороченных энтерпрайзных систем с индексами, и там вопрос амплификации, нагрузки и проч вообще - не раскрыт. А каких-то реально сравнимых решений получить? Что вы, не дождетесь!
Ответить | Правка | Наверх | Cообщить модератору

	9. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от Аноним (9), 15-Авг-26, 00:53
	Так может лучше задействовать для бана ботов нормальную базу данных, а не эти ошмётки? А текстовые логи оставить только для отладки.
	Ответить | Правка | Наверх | Cообщить модератору

	13. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (16), 15-Авг-26, 01:03
	> Так может лучше задействовать для бана ботов нормальную базу данных, а не эти ошмётки? > А текстовые логи оставить только для отладки. Ваша проблема в том что у вас в итоге только: - Голый зад - и нифига кроме рассказов как все это "не надо". - Невь...й enterprise grade которому для обслуги надо тиму фултайм админов в комплекте. Потому что ваша нормальная база данных - обслуживаемая. И надо - того кто умеет в DBA. Бесплатно работать DBA почему-то не любят. А mid-range и просто возможность забанить надоевших ботиков с своего сервера без огромных напрягов и затрат? В вашей картине мира такое не предусмотрено вообще. А у поттера так можно было. И это причина по которой мир в целом предпочел - его. А вы можете свои базы данных админить, если вам это надо.
	Ответить | Правка | Наверх | Cообщить модератору

7. Скрыто модератором	+1 +/–
Сообщение от Аноним (7), 15-Авг-26, 00:51
>Разработчики systemd тогда наотрез отказались признавать проблему: мейнтейнеры заявили исследовательские претензии в духе "вы не понимаете, как работают файловые системы", отказались от проведения профилирования и закрыли заявку со вердиктом "not actionable". Конченые щекотатели ануса, md в systemd означает мудачье
Ответить | Правка | Наверх | Cообщить модератору

10. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
Сообщение от Аноним (6), 15-Авг-26, 00:55
> типичный для корпоративного Open Source подход: критический недочёт в инфраструктурном компоненте игнорировался годами Вся суть архитектуры системды.
Ответить | Правка | Наверх | Cообщить модератору

	17. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–1 +/–
	Сообщение от Аноним (16), 15-Авг-26, 01:17
	>> типичный для корпоративного Open Source подход: критический недочёт в инфраструктурном >> компоненте игнорировался годами > Вся суть архитектуры системды. А альтернативы то какие? Сидеть с голым задом или огроменные энтерпрайзные монстры? Тоже мне дузовные метания мадам грицацуевой.
	Ответить | Правка | Наверх | Cообщить модератору

11. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
Сообщение от Avririon (ok), 15-Авг-26, 00:56
Напоминает местного вахтёра.
Ответить | Правка | Наверх | Cообщить модератору

	14. Скрыто модератором	–1 +/–
	Сообщение от Аноним (16), 15-Авг-26, 01:04
	> Напоминает местного вахтёра. Автора новости смотри. Этому везде видятся - заговоры корпораций. Сам он ничерта сравнимого как решение разумеется выкатить чисто технически не способен.
	Ответить | Правка | Наверх | Cообщить модератору

18. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
Сообщение от Rev (ok), 15-Авг-26, 01:17
Ждём исправления в нашем любимом Дебиане лет через 6-8.
Ответить | Правка | Наверх | Cообщить модератору

	20. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (20), 15-Авг-26, 01:24
	Хехе, не дождетесь. Там только на профилирование, дебаг и рабочие фиксы уйдёт года полтора-два. Вспоминаем историю #12309.
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема