Как стать автором
Обновить

Комментарии 20

Тяжеловато ES для такого объёма логов. Если задача 2 дня хранить, то зачем все 30. Можно же хранить 2 дня в ES, а остальное в сжатом виде и искать любым Map Reduce, дольше, но сильно проще и дёшевле. Не?

Задача была хранить 30 дней. Сейчас, кстати, думаем начать хранить ещё больше.
Да, можно было бы сгружать все старые логи куда-то, где они будут лежать компактней, но часто бывают кейсы, когда люди прямо что-то ищут на интервале 30 дней, графики строят, аналитику делают. И, как обычно, результаты таких запросов им нужны не через час, а максимум секунд через 30-40, ну может минуту. Да, эластик приходится сильно «готовить», но, по сути, если считать кол-во событий, обрабатываемых мастером, его можно ещё раза в 2-3 увеличить без больших напрягов.
Предположу, что графики строятся по числовым данным, то предположу, что наверное можно эти данные нормализовать и сгрузить в ClickHouse. Там это явно будет компактнее и шустрее
Они могут строиться и по результатам поиска агрегированным в некую цифру на лету.
а дальше мы работаем уже с mapped-файлом. Из-за этого получается, что при попытке GC остановить треды в приложении мы очень долго идём в safepoint

Нельзя ли по-медленнее? Я записываю.
Как оказались связаны mmap файлы и длительность TtSP (time to safepoint)? Речь про то, что процесс обращается к памяти, и тут внезапно возникает page fault, и обработка page fault'а растягивает TtSP?
да, пока отрабатывается pagefault кернелом JVM ждет его завершения и на safepoint не становится. соотвественно длительность такой паузы сильно зависит от того какие диски и как хорошо справляется кернел с текущей нагрузкой на чтение/запись.
200 ТБ — один современный сервер с полкой на 24 диска (и это уже с избыточностью в рейдах), что такого в этой цифре?
Если речь про производительность кластера на запись — так и пишите в заголовке.
Хранить 200тб просто. Сложней в них быстро что-то найти
Нет, если данные индексированы. Поисковые базы побольше 200 ТБ будут, а ищут почти мгновенно.
Вот записать 200ТБ за какой-то обозримый промежуток времени — да, проблема.
Ребята наверное просто не пробовали выдать эластику 512Гб RAM и 64 ядра. Я кстати тоже не пробовал.
Можно нарезать на 16 инстансов. Но не обязательно, 64битные указатели это не так плохо, особенно когда типичный аналитический запрос отжирает 200Гб памяти.
Хранить 200тб просто. Сложней в них быстро что-то найти
Зато помогли разработчикам эластика улучшить поведение мастер-нод, видишь какие Одноклассники корпорация добра :). Вообще это достаточно адекватно, просто другой подход к эксплуатации. У меня в известном тебе OpenStack'е похожая пропорция была, 40 нод, 20Тб SSD, правда проблем было гораздо меньше потому что вместо graylog'а был известный тебе mapreduce и данные заливались батчами напрямую в дата-ноды хранящие primary-реплику шарда в который эти данные надо сложить.
миграция на JDK13 и использование сборщика мусора Shenandoah

Это связанные события или нет?
Shenandoah разлива JDK 8/11 не хватает? Или в JDK13 есть что-то дополнительное?
Связано. В JDK 13 Shenandoah GC претерпел существенные изменения; его даже иногда называют Shenandoah 2.0. В частности, была пересмотрена модель барьеров: ушли от дорогих read barriers в пользу load reference barriers, а также отказались от forwarding pointers — дополнительного слота в хипе перед заголовком каждого объекта.
Во. Про такое тоже стоит упоминать.
Я почему-то считал, что это всё портировано и в 8
Портировано, но позже. Во время событий, описанных в статье, Shenandoah 2.0 в JDK 8 ещё не было. Да и не вечно же сидеть на восьмёрке.

А картина в конце статьи с linux к чему? Все проблемы-то судя по написанному c jvm и иже с ним.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.