Владимир спасибо. Что касается лучше сразу много, чем много раз по одному - это вообщем-то известно). это касается почти всех баз в разумной мере. мне видимо не хватает знаний по кх. а тчо значит нативное чтение из кафки?

Владимир спасибо. Что касается лучше сразу много, чем много раз по одному - это вообщем-то известно). это касается почти всех баз в разумной мере. мне видимо не хватает знаний по кх. а тчо значит нативное чтение из кафки?

Лучше данные хранить все таки надёжно и персистентно в какой то бд, и хранить там столько месяцев сколько нужно. И сделать некий тулинг, который будет наполнять редис нужными данными из той бд, тоесть подогревать их

ну да, он может изменения писать в AOF файл. Но это лишь методика регулирования нагрузки на дисковое IO в попытке обеспечить персистентность данных с высоким рейтом операций записи \ апдейта.

Ну там время в секундах выставляется, лог пишется последовательно, сложно будет упереться в диск. Чем не "взрослая" база данных? Там тоже fsync на каждую транзакцию никто не делает. (Нагруженный редис не практиковал, по-этому рассуждаю/спрашиваю)

Ну там время в секундах выставляется, лог пишется последовательно, сложно будет упереться в диск. Чем не "взрослая" база данных? Там тоже fsync на каждую транзакцию никто не делает. (Нагруженный редис не практиковал, по-этому рассуждаю/спрашиваю)

Добрый день. У меня стоит простая задача - сделать так, чтобы логи писались из приложения в elasticsearch. Приложение - java. Логов может быть как много, так и мало, поэтому я хочу сделать буферизацию, чтобы посылать логи в эластик пачками. И заодно выкидывать логи если elastic не справляется или упал там. Я хочу для этой цели использовать fluentd. Есть планы перейти на fluent-bit, но пока fluentd. И соответственно использовать memory buffer. Но у меня не получается. И поэтому я хотел попросить кого-нибудь, кто это уже делал мне подсказать - это же обычная задача - многие наверняка с ней сталкивались. В частности мне совершенно непонятно как работают эти буфера и chunks во fluentd. Я по наивности полагал, что если не настраивать ключи для chunks, то fluentd будет выделять из общей памяти размером total_limit_size пространство под чанк, заполнять этот чанк новыми сообщениями и потом, как только чанк заполнится сообщениями на chunk_full_threshold начнет пытаться его отсылать. Если память кончится, то если выставить overflow_action drop_oldest_chunk, то старые чанки будут выкидываться. Но все оказалось не так, как я думал. А как - я не понимаю и поэтому прошу помочь разобраться. Итак конкретика: сначала у меня была конфигурация вот такая: <buffer> @type memory flush_interval 1s retry_forever false retry_wait 10 retry_exponential_backoff_base 2 retry_max_times 4 chunk_limit_size 512K total_limit_size 32M overflow_action drop_oldest_chunk fluentd 1.1 В принципе все работало, но память, потребляемая вырастала больше 150мегабайт. Но у нас же сконфигурено было 32мега лимит - откуда 150? Я попытался сделать по-другому: <buffer> @type memory ... flush_mode immediate chunk_limit_size 1M chunk_limit_records 1000 total_limit_size 32M и оно вообще перестало писать в эластик. Но ведь кто-то же умеет. Подскажите, а?

Ну там время в секундах выставляется, лог пишется последовательно, сложно будет упереться в диск. Чем не "взрослая" база данных? Там тоже fsync на каждую транзакцию никто не делает. (Нагруженный редис не практиковал, по-этому рассуждаю/спрашиваю)

Ебаный хромиум ушатывает мне файлуху по кд при запуске на 16.04. Это всё что нужно знать об охуенном опенсорсе.

Ебаный хромиум ушатывает мне файлуху по кд при запуске на 16.04. Это всё что нужно знать об охуенном опенсорсе.

Живой. Вот уже почти час прошел - ни одной ошибки. При старте хромиума файлуха сразу в РО.

Ну, переустановить я всегда смогу. Для начала "пуржну" хромиум. Но, сука, я домой прихожу чтобы деградировать, а не ебаться с файлухами по пятницам😡

Ну, переустановить я всегда смогу. Для начала "пуржну" хромиум. Но, сука, я домой прихожу чтобы деградировать, а не ебаться с файлухами по пятницам😡

Не btrfs ли у вас часом?

Не, это не старая история. Старая - это какой-то архитектурный косяк в QT, из-за чего иногда отваливает буфер обмена общий в линупсах. У меня на десктопной телеге, на 12.04 и на 16.04 такое проявляется. Этому багу около десяти лет, который наблюдается в разных продуктах

Он отваливается через кажется 42.7 дней аптайма

Как минмум аптаймы телеги у меня больше месяца, а иногда больше и трех месяцев.

Там не тока в телеге дело

WORK 24/7 будет жить. Поприветствуем!

Видели вакансию в яндекс?)

в этой помойке кто то еще сидит?

сидят и не матерятся, да

Ну я девопс жобс сегодняшнюю