Комментарии 22
В докере вероятно идёт замедление. Из результатов работы в проде на большом трафике. Редис 99 перцентиль без тлс стабильно районе 1 мс, с тлс - 2-3 мс в зависимости от нагрузки. Постгрес, среднее в районе 4мс, но 99 перцентиль в районе 7 мс из-за переводческих замедлений. Ну и с постргресом нужно следить , чтобы все запросы работали по памяти ( брали все данные из индекса без обращения к диску, сам индекс соответственно должен полностью помещаться в память)
Тоже были такие мысли, чтобы их развеять я также запускал чистые контейнера postgres и redis в докере и проводил эти тесты между докер контейнерами.
Также запускал redis и postgres напрямую на WSL без docker - результаты в целом сошлись с инстансами в docker, так что в моих тестах я думаю возможным замедлением такого рода можно пренебречь.
"Напрямую на WSL" это не "напрямую" на самом деле :)
WSL использует те же механизмы виртуализации, что и докер :)
В целом, влияние контейнеризации в случае абсолютного большинства приложений - не критично.
Однако кэширование - ровно тот класс задач, где влияние становится как минимум заметным.
Да, WSL и правда работает через трансляции вызовов, прям как Docker. Но, покупать RDP с GPU на Linux ради статьи - это сильно жирно... А использование ВМ - бессмысленно, т.к. там задержки ещё выше. Ну и накатывать Linux ради одной статьи тоже такое себе~
В замен этого я попытался организовать максимально равные условия тестирования для каждой итерации бенчмарка.
Постгрес из коробки не настроен по сути вообще никак, насколько уже понимаю. 32 буфера в памяти по 8 кб - это ниочем даже для такого теста. Ну и вообще, Посгрес - версионник и заточен совсем под иные задачи. Если уж и брать SQL-СУБД, то кмк, лучше бы подошел Мускуль, причем с табличками IN MEMORY сразу. На простых задачах, где НЕ требуется версионирование, он будет выигрывать процентов 30 по скорости от Посгри.
Ну а в целом, удручающее впечатление от статьи .. всё равно, что сравнивать чем забивать гвозди при сборке дома: телескопом или микроскопом? :(
Так и есть, тока сравниваем не только чем забивать, а ещё самое главное - куда забивать? :)
Я понимаю, что реляционные бд в целом не заточены под работу с таблицами ключ-значение, но такая возможность у них есть, а сравниваем мы все таки кеширование и именно бд vs redis.
И про тонкую настройку postgres тоже в курсе. Но это уже не совсем объективное сравнение получится, т.к. на разном железе и ос можно получить совсем разные результаты производительности. Получится что у бенчмарка от настройки к настройке будут совершенно разные результаты.
С MySQL довольно мало доводилось работать, т.к. в основном работаю с Postgres.
К тому же для MySQL насколько я понял нет готового решения для её развертывания на GPU, а главная идея статьи то была в том, чтобы рассмотреть саму возможность работы с кешем на GPU.
Чем Вам "реляционные БД не заточены под ключ-значение"? Минимально любую таблицу можете представить себе как первичный ключ + значение. Достаточно одной таблицы. Микроскоп тоже можно применять для забивания гвоздей, достаточно одного свойства - станина тяжелая.
Только назначение микроскопа иное, там важна оптика и точность перемещения. С этой целью станина - тяжела, а вовсе не для забивания гвоздей. Точно также и тут: реляционные СУБД в целом предназначены для ИНОГО, и оптимизированы, имеют много "лишнего" для забивания гвоздей, как и микроскоп.
Аналогично, применять ГПУ для ХРАНЕНИЯ пар ключ-значение, не предназначенного под это, но имеющего совсем иные инструменты, точно также "забивать микроскопом гвозди".
Так что вопрос не "куда забивать", а ЗАЧЕМ всё вот это?
Боюсь, что у меня нет ответа на ваше ЗАЧЕМ 😔...
Да и в целом статья не агитирует всех бросать свои дела и бежать переводить кеш у в проектах на GPU.
Я просто предложил рассмотреть кеширование на GPU, как один из возможных вариантов реализации кеширования впринципе.
В конце статьи так и написано даже, что такая реализация может быть необходима исключительно каким то супер сложным и требовательным проектам.
Ну а что, есть же компании, которые кластеры серверов с большим объемом ОЗУ ставят, чтобы данные чисто в ней хранить.
Думаете нет компаний, которые все все на GPU считают?) А как же тот же OpenAI? Не знаю, как у них там обстоят дела с кешем, но GPU у них точно в достатке.
@RoPi0nа какой профиль был при тестах на gpu (P-States)? Менялся ли при нагрузках с P8?
По умолчанию профиль выставлен в режим производительности, карточка тоже слегка разогнана.
Если честно не обратил внимание на изменение режима питания с P8 на другие.
На тестах GPU нагрузилась по итогу максимум до ~20-25%, а проблемы с троттлингом, о которых вы наверное подразумеваете на 20-25% нагрузке точно никак не вылезут.
Тесты относительно простенькие, продолжительностью не более полутора минут. На них и вольтаж особо не вырос и даже вентиляторы вроде не загудели)
RTX 3080 TI как-никак околофлагманская GPU на момент выхода.
Я с неё 4к на 120фпс вытягиваю в ААА проектах и то на полную загрузить не могу, то ли дело какой то там Postgres)
В любом случае это довольно интересный и неожиданный результат.
В чем именно неожиданность, в том, что слишком мало просела производительность? Ядро Редиса однопоточное, он не будет получать какой-то выгоды от GPU.
Да и вообще не думаю, что кэш даже в теории может получить выгоду от большого количества потоков. Если это distributed кэш, когда с разных машин по сети коннекшены устанавливаются, потоки в основном нужны для обслуживания этих коннекшенов, есть хороший шанс, что их проброска с CPU на GPU съест всю потенциальную выгоду.
Ну и опрос в конце статьи какой-то мутный. Почему нельзя сразу пользоваться и локальным кешем и distributed? Мне кажется это весьма распространенный случай: локальный для эээ локальных данных, которые не выходят за пределы процесса, распределенный для данных которые надо делить с другими инстансами. И почему словарь/хешмапа для кэша, хочется чтоб вся память утекла? Очень частые сценарии когда кэш может расти за пределы доступной оперативной памяти и лучше использовать LRU/LFU кэш. Можно, конечно, свою имплементацию сделать, но проще воспользоваться готовыми библиотеками, коих, наверняка, миллион. Ну и оба не потокобезопасные, не знаю про Питон, для Джавы есть же конкурент хешмап.
Упд: я смотрю, результат посттгреса довольно близко к результату редиса. Попробуйте их сравнить после недели использования 24/7 с рандомными данными (рандомными, в том смысле, что они случайно выбираются из огромного пула данных, а не в том, что каждая вставка/чтение - уникальные, таким кэш просто-напросто не нужен)
Ядро редиса однопоточно и об этом в статье не раз сказано. Но... Существует вот просто форк редиса, который использует видеопамять (про потоки не сказано) и вот видеопамять в отличии от обычной работает же сильно шустрее. Вот и был смысл взять 2 этих редиса и сравнить. А результат получился неожиданным, потому что версия на GPU проиграла версии на CPU.
Что касается опроса и наличия dict/HashMap в нем... А про пункт с матрасом например почему не спросили?)
Понятно же что часть пунктов там лишние и dict/hashmap в их числе... Я такие шуточные опросы вообще в каждую последнюю статью пихаю...
Видеопамять в отличии от оперативной памяти не быстрее. У нее выше пропускная способность, при это задержки намного выше, чем у оперативной памяти. То есть все будет зависеть от профиля работы. Специфика гпу предполагает возможные задержки со стороны памяти, которые компенсируются огромным объемом данных, которые гпу благодаря своей многоядерности успевает обработать быстро. Цпу же не терпит зажержек памяти, по скольку выполняет зажачи последовательно. Да, есть out of order execution, но работает это далеко не всегда и затык на конкретной инструкции должен быть минимальным. Поэтому redis-у плевать на мощность гпу, он однопоточный, он не может задействовать весь гпу
Исследуя вычисления на CPU и GPU вижу, что можно легко получить отставание на GPU - сказывается "медленная" передача данных из/в GPU. Но на задачах подходящих для GPU ускорение может быть в сотни раз (300+ получалось). И наверно кеш не самая актуальная задача для GPU т.к. не достаточное число раз надо делать одно и то же.
Возможно не самая актуальная, но почему бы не сравнить эту производительность?
Просто я не нашел нормальных подобных сравнений в интернете, а вопрос этот меня мучал.
PG_Strom входит в комплект PostGis например - надстройка на Postgres, для работы с геоданными, когда этих самых данных реально много. Вот там как раз таки и идет прирост с 100... 200... 300 раз.
Какой именно я не знаю, но раз они запилили эту надстройку, значит причина у них была весомая.
Тут интресно что там с vacuum на постргрес, ресурсов будет потреблять на порядок больше, особенно io
Ну так, ресурсов - не жалеем!
Точнее сказать - памяти не жалеем, я её даже не замерял.
Главное в этой статье только одно - perfomance!
Так я не про память ram, я про диск. Каждое обновление создает новую версию той же строки, периодически запускается avtovacuum для очистки старых значений + обновление индекса, это достаточно жирные процессы. Может создаваться ситуация когда нагрузка при каждом следующем vacuum увеличивается и в конечном счёте через день два получаем колом вставшую базу. Видел такое на проде. Поэтому тест этот нужно гонять и смотреть на всю систему и все процессы. Причем гонять именно сутками, даже за час вы эту деградацию скорее всего не увидите. Можно конечно использовать unlogged таблицы которые не пишут wal(при сбое данные пропадут). Но тогда зачем тут постгрес?
Если вы про это, то таблица была создана с флагом UNLOGGED и AUTOVACUUM_ENABLED = FALSE (В спойлере с тест кодом под Postgres ниже приведен SQL запрос инициирующий таблицу).
Оно вообще не должно было ничего читать/писать на диск.
При кешировании так и подразумевается, что при любом сбое - данные пропадают.
Postgres в статье используется именно как система для хранения и доступа к кешу, а не как база данных.
Вообще, подход в статье - замечательный, с тачки зрения игнорирования привычных рамок по использованию инструментов.
Мы вот, например, пришли к тому, что постгрес - замечательная шина данных, если у тебя ограничено количество потребителей :)
Однако, постановка с работой с GPU - кривенькая в силу одной единственной причины: работа через gpu нужна, чтобы потом использовать ответы не выгружая их с GPU. Например, для обучения или инференса нейросети на известном кусочке данных.
Тут же, получается, мы выигрываем только за счёт того, что промежуточные операции с ключом перед чтением/записью делаются в рамках более быстрой памяти. Но после этого добавляем дополнительный шаг чтения/записи RAM-VRAM. А это, вообще говоря, дорогая операция
А то, такой подход иногда позволяет находить простые решения к сложным задачам.
Работу с GPU и правда можно было бы организовать по другому, но опять же пока писал эту статью так вышло, что привычные рамки использования GPU также были проигнорированы.
Получив в качестве результата прирост скорости у Postgres по сравнению с Redis - логичным следующим шагом будет сравнить хотя бы 2 СУБД, которые предназначены для работы на GPU. Только вот с такими задачами я ранее не сталкивался и не могу с уверенностью сказать, что такое моё сравнение (если я его организую) - будет технически грамотным.
Ну а с кешированием работаю постоянно.
По итогу при переходе на VRAM удалось получить относительно небольшой выйгрыш в производительности, что может сбить с толку, но тут стоит обратить внимание на то, что I9-11900K и RAM были настроены на околопредельные частоты для стабильной работы (при повышение по памяти ещё хотя бы на 100МГц я получал неминуемый BSOD в моем случае).
Возможно следовало бы включить в тест кейсы ещё ряд прогонов бенчмарка, но при этом намеренно занизив частоты CPU и RAM, для получения более явного отрыва при переходе на GPU.
Ну и опять же, раз уж взялся сравнивать Redis & Postgres - то БД должна была быть загнана в довольно таки не оптимальные рамки работы "как Redis".
Вертим кеш на GPU