Комментарии 20
Тяжеловато ES для такого объёма логов. Если задача 2 дня хранить, то зачем все 30. Можно же хранить 2 дня в ES, а остальное в сжатом виде и искать любым Map Reduce, дольше, но сильно проще и дёшевле. Не?
Задача была хранить 30 дней. Сейчас, кстати, думаем начать хранить ещё больше.
Да, можно было бы сгружать все старые логи куда-то, где они будут лежать компактней, но часто бывают кейсы, когда люди прямо что-то ищут на интервале 30 дней, графики строят, аналитику делают. И, как обычно, результаты таких запросов им нужны не через час, а максимум секунд через 30-40, ну может минуту. Да, эластик приходится сильно «готовить», но, по сути, если считать кол-во событий, обрабатываемых мастером, его можно ещё раза в 2-3 увеличить без больших напрягов.
Да, можно было бы сгружать все старые логи куда-то, где они будут лежать компактней, но часто бывают кейсы, когда люди прямо что-то ищут на интервале 30 дней, графики строят, аналитику делают. И, как обычно, результаты таких запросов им нужны не через час, а максимум секунд через 30-40, ну может минуту. Да, эластик приходится сильно «готовить», но, по сути, если считать кол-во событий, обрабатываемых мастером, его можно ещё раза в 2-3 увеличить без больших напрягов.
а дальше мы работаем уже с mapped-файлом. Из-за этого получается, что при попытке GC остановить треды в приложении мы очень долго идём в safepoint
Нельзя ли по-медленнее? Я записываю.
Как оказались связаны mmap файлы и длительность TtSP (time to safepoint)? Речь про то, что процесс обращается к памяти, и тут внезапно возникает page fault, и обработка page fault'а растягивает TtSP?
200 ТБ — один современный сервер с полкой на 24 диска (и это уже с избыточностью в рейдах), что такого в этой цифре?
Если речь про производительность кластера на запись — так и пишите в заголовке.
Если речь про производительность кластера на запись — так и пишите в заголовке.
Хранить 200тб просто. Сложней в них быстро что-то найти
Нет, если данные индексированы. Поисковые базы побольше 200 ТБ будут, а ищут почти мгновенно.
Вот записать 200ТБ за какой-то обозримый промежуток времени — да, проблема.
Вот записать 200ТБ за какой-то обозримый промежуток времени — да, проблема.
Ребята наверное просто не пробовали выдать эластику 512Гб RAM и 64 ядра. Я кстати тоже не пробовал.
а что так можно было?
www.elastic.co/guide/en/elasticsearch/guide/master/_limiting_memory_usage.html
www.elastic.co/guide/en/elasticsearch/guide/master/_limiting_memory_usage.html
Хранить 200тб просто. Сложней в них быстро что-то найти
Зато помогли разработчикам эластика улучшить поведение мастер-нод, видишь какие Одноклассники корпорация добра :). Вообще это достаточно адекватно, просто другой подход к эксплуатации. У меня в известном тебе OpenStack'е похожая пропорция была, 40 нод, 20Тб SSD, правда проблем было гораздо меньше потому что вместо graylog'а был известный тебе mapreduce и данные заливались батчами напрямую в дата-ноды хранящие primary-реплику шарда в который эти данные надо сложить.
RAID 5 из 10Тб дисков что-ли? нет спасибо.
промахнулся
промахнулся
миграция на JDK13 и использование сборщика мусора Shenandoah
Это связанные события или нет?
Shenandoah разлива JDK 8/11 не хватает? Или в JDK13 есть что-то дополнительное?
Связано. В JDK 13 Shenandoah GC претерпел существенные изменения; его даже иногда называют Shenandoah 2.0. В частности, была пересмотрена модель барьеров: ушли от дорогих read barriers в пользу load reference barriers, а также отказались от forwarding pointers — дополнительного слота в хипе перед заголовком каждого объекта.
А картина в конце статьи с linux к чему? Все проблемы-то судя по написанному c jvm и иже с ним.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кластер Elasticsearch на 200 ТБ+