Comments 27
Далее для каждой связки “сценарий + профиль окружения” я брал максимальное достигнутое значение TPS (по какому-то числу клиентов) и сравнивал их между собой.
А почему вы уверены, что полученный результат не выброс ?
Далее, какие выводы делаются на основании "latency stddev (ms) " ?
Разница между сценариями , весьма значительна.
В публичных облаках, как правило, всякие PaaS/SaaS/KaaS работют в ВМ - то есть по сути, отличие только в том, что взяли обычную ВМ и накидали слоев кубера. Никто не пустит разных юзеров в один куб - поэтому ВМ, в ней куб, и поехали. То, что вам показывают "кластеры БД" а не ВМ-ки, не значит что ВМ нет, их просто не показывают. В противном случае слишком велики риски получить совершенно неожиданный неприятный "подарок" от одного юзера лругому
А вот почему кубовые сервисы оказались таким дном - интеренсый вопрос. В теории, сеть добавит 1-2мс в худшем случае, откуда берется остальное?
для полноты картины: хорошо бы увидеть
- сравнение СУБД в ВМ где диск физически прикручен с СУБД в k8s где диски тоже "поближе" к подам
- сравнение СУБД в ОС на голом железе с СУБД в k8s на голом железе
к сожалению нет возможности самому сделать стенд. Но может найдутся энтузиасты с возможностями? Пусть не подробный отчет, хотя бы цифры голые
Я поржал. Сравнение в молоко. Tls ? Ну, камон, базу без тлс запускать в 2025. А еще, дорогой товарищ, ты поотключал какие либо сервисы на узле кластера, чтобы не было истории с шумными соседями ? Тюнинг планировщика линукс ? Нет ? А ничего, что даже настройки линукса на контейнерной машине и на стендэлоун виртуалке у облачных провайдеров отличаются? А чего тогда вообще с managed db не сравнить ? Ну, чтобы база в кубере натурально проиграла ? Потому что у облака явно в их managed db сервисах есть очень крутые оптимизации… не знаю, выводы так себе, прям…
Ну, и zolando писать… ну, полный стыд. Скриншоты для истории оставил. Вот и весь уровень статьи.
Спасибо! Рад, что смог вас порадовать. Я учту ваши комментарии в будущих тестах.
конструктивно:
mdb Postgres в YC имеет ключевое ограничение - 200 коннектов на ядро ( в вашей терминологии - оптимизацию)
"шумные" соседи - их "импакт" был в тестах исключен, но в реальном продуктовом кластере у вас не может быть ноды вообще с одним подом Postgres - нужны логи, метрики т.д. - всегда будет что-то служебное
Все тесты "синтестические" и каждый может сам на основе результатов этих тестов сделать свои собственные выводы и поделится ими с сообществом - почвой для которых и служит данный материал.
Спасибо за Ваш комментарий.
у вас не может быть ноды вообще с одним подом Postgres - нужны логи, метрики т.д. - всегда будет что-то служебное
валидно! Но тогда с тем же успехом можно констатировать, что это все на ноде с постгрес требует специфичной настройки, чтобы не ломать производительность pg. А самое главное - чтобы не заезжали другие, левые, пользовательские поды.
Безусловно. Для подов и ноды были сконфигурированы соответствующие Taints и Tolerations. В рамках теста была выделенная нода для cnpg. Все "служебные" поды имели ограничения по запросам и лимитам ресурсов - "шум" был сведен к возможному минимум. Так же были выделеные гаранитрованые реквесты для пода cnpg равные по ресурсам native vm c Postgres.
ну так-то на vm будут всё те же экспортеры и сборщики логов. Соседи отстреливаются через taints, если вдруг у нас такой highload. Так что единственная разница с VM это сетевой путь до пода, поскольку разницы между systemd unit и запущенными в контейнере сервисами нет никакой.
Ну а так, на мой взгляд, внутрикуберовые постгрессы решают задачу множественности выделенных кластеров постгресса для множества сред исполнения: тестовые стенды. Или обычные кластера обычных сервисов, из которых не делают ядро сервисов высокочастотного криптотрейдинга. Всё это даёт отличную плотность использования ресурсов для рядовой нагрузки. Наборы на VM существенно более расточительные в плане инфраструктуры.
Привет, Сергей!
В теории Вы абсолютно правы. Технически же появляется дьявол в деталях. Инстансы под кластера кубера и ВМ - разные (привет, таймвеб).
Конфигурация ОС под ВМ и под кубер разная (привет яндекс)
и прочая пачка влажных историй из эксплуатации.
Чтобы провести чистый эксперимент - надо брать условный VM в хетцнере с бубунтой, ставить туда постгрес как пакет операционной системы. Далее брать в том же хетцнере такую же VM (можно взять ТУ ЖЕ самую после полного формата диска), катить на нее воркера кубеадм кластера (возьмем еще одну виртуалку) и тогда уже и сравнивать. Не забыть еще про диски - что есть разница между локальным диском системы и ebs снаружи (в хетцнере не так, как в яндексе, так как производительность диска не меняется в зависимости от размера диска). Короче, говорить просто в вакууме, что кубер медленнее - это вроде бы с одной стороны результат, а с другой - ну, он бессмысленен.
По облачной части тест достаточно хорош: в обсуждаемом тесте постгресс тестируется на одинаковых compute одного провайдера. Также мы никак не лимитированы в настройках нод кубера в managed kubernetes от yandex cloud: daemonset + nsexec/nsenter, я таким успешно пользуюсь. Так что всем остальным в плане облака можно смело пренебречь в рамках обсуждаемого тестирования производительности postgresql в единых условиях. Однако автор использует по разному настроенные postgresql, в качестве аргумента используя "я настроил 10 одинаковых параметров", игнорируя остальную "навеску" от операторного решения. Я бы просто поднял под с голым постгрессом без всяких операторов с одинаковым конфигом на VM и в поде.
тогда получается, надо брать настройки от "кубернетесовского" cnpg постгреса и инжектировать в standalone, а дальше обсуждать влияние именно от k8s стека. Кстати, его можно легко нивелировать - через правильное использование csi (local path provisioner?), host network (чтобы не было задержки cni) etc.
Там cilium с включенным netkit и заменой kube-proxy нельзя поставить? Мне кажется не должно быть большой разницы на одном железе.
imho лучше сравнивать на своих серверах, а не виртуалках в облаке.
Talos (cilium+linstor с дисками в одну реплику) с cnpg против патрони на etcd - и получаем одинаковый результат. Понятно что обвязка свое заберет, но блин не в -40% ))
Тюнинг конфига посгреса в кубе тут наименьшую результативность принесет, если ничего другого не делать ни с кубом, ни с cni\csi
Спасибо за статью, изложенная в ней методика тестирования имеет множество серых зон из-за которых выводы автора видятся преждевременными. Но отмечу, что сама тема статьи шикарна и актуальна.
Оставлю тут свои пожелания, для повторного тестирования:
клиента в виде pgbench некорректно запускать с отдельной vm - такого в реальной микросервисной среде не бывает, в обоих случаях нужно запускать pgbench в кубе, в одном случае в том же ns, что и бд.
Обязательно исключить троллинг на контейнерах Postgres, для этого выдать целочисленные и равные реквесты и лимиты на cpu, qos class guaranteed и получение ядер из dedicated пула с правильно настроенным cpu manager
Ну и с советами вышел я тоже согласен, в тестировании не хватает промежуточных вариантов, типо просто пода с голым postgres без оператора.
Для контекста, перешли из managed database postgres из yandex на postgres оператор zalando в кубах Cloud.ru и имеем схожую максимальную производительность в qps от той что была ранее (потеряли не более 5-7%) для всех сервисов для которых не критично ограничение в 1Гб/с на storage, к сожалению в cloud.ru нет более быстрых storage классов и для достижения сопоставимой производительности, нам пришлось шардировать кластера. Но у нас и не стояло задачи получить столько же, у сервисов после переезда не оказало влияния на созданные графики slo/sla конечных сервисов, что нас уже устроило.
А jit везде был отключен?
Статья неплохая, но есть много вопросов
1) Почему 14-я версия пг? На дворе уже 18-я есть. Ну хотя бы на 17-й тестировали;
2) Не указано производился ли тюнинг ОС на VM: измененные параметры sysctl, параметры i/o планировщика и прочее
3) Не указана версия ubuntu на VM
4) Не понял из статьи был ли это Managet k8s от Yandex или или свой на VM, а так же не понял был ли это чистый кластер (без соседей) или там что-то уже работало.
5) Про jit в пг выше валидный вопрос.
6) Насколько я понял пулер соединений не использовался или использовался?
Все эти тонкости могут повлиять на итоговую производительность в тестах.
Сравнение изначально некорректное. Поскольку используются услуги открытые на разном железе заведомо находящемся в разных условиях в плане нагрузки на аппаратные компоненты. Не говоря о том что ноды "под куб" и "под вм" могут ощутимо отличаться аппаратной конфигурацией.
Для корректных замеров нужно использовать одну и туже вм (или набор вм). В идеале, с контролем того на какой ноде вм запускается при перезагрузке.
Пришёл навалить базы, а в комментариях уже за меня справились.
Чтобы тест был объективным - его нужно запускать на одинаковом железе, с одинаковыми дисками (желательно локальные).
Тогда можно будет сказать: "кубернетис и оператор cnpg внесли столько-то".
А измерять на вм в облаке, да на managed k8s, да на сетевых облачных дисках - это трата времени впустую. Ну или для наброса использовать.
Сколько производительности съедает Kubernetes: сравниваю native PostgreSQL и CloudNativePG в Yandex Cloud