Комментарии 21
В любых тестах есть смысл, когда их можно воспроизвести и проверить.
А Postgres Pro Enterprise, во-первых, не находится в открытом доступе.
А во-вторых, адекватная компания Postgres Pro при получении версии Enterprise требует подписания соглашения с таким пунктом:
"2.2. Получаемое Пользователем право не включает права:
2.2.1. Передачи и распространения полученных результатов тестирования Продукта и информации о них (в устной и письменной формах) в средства массовой информации (СМИ), в сеть Интернет, в иные источники и ресурсы, позволяющие третьим лицам получить доступ к информации о результатах тестирования Продукта, включая, но не ограничиваясь: открытые и закрытые блоги, чаты, группы, социальные сети."
Так что мы, конечно, практически верим вашим тестам, но когда вы запрещаете кому-либо писать о результатах их перепроверки, это наводит на разные интересные мысли.
Кружок юного юриста объявляется открытым
Почему вы считаете, что лицензия на использование должна давать право на тестирование? Совершенно стандартная, примерно для всех вендоров, практика, что для тестирования и публикации результатов используется отдельное соглашение. В котором, кстати, будет прописано обязательство предварительно прислать результаты вендору, чтобы он убедился в корректности проведённых тестов и одобрил публикацию.
И как написано в статье (если внимательно прочитать) все методики выложены, так что можете провести все эксперименты у себя. И если результаты разойдутся с нашими, то приходите - будем искать причину.
А тестирование это разве не использование продукта? А?! Я беру реальные данные, создаю реальную нагрузку с помощью тестов и смотрю как Ваш хваленый продукт работает как замена oracle/ms sql, а потом делаю выводы можно ли покупать еще больше лицензий илы нет.
По вашей логике я должен купить кота в мешке доверившись маркетологам и радоваться? Пфффф.
Если вам интересно почему мир устроен как устроен, а не так как вам кажется правильно, это надо у людей с юридическим образованием спросить.
И внутреннее тестирование проводить ни один документ не запрещает ;)
"Совершенно стандартная, примерно для всех вендоров, практика, что для тестирования и публикации результатов используется отдельное соглашение. В котором, кстати, будет прописано обязательство предварительно прислать результаты вендору, чтобы он убедился в корректности проведённых тестов и одобрил публикацию. "
О как! Теперь буду знать, что если я тестирую какую-либо программу и пишу про результаты тестов, что вендор предварительно должен одобрить публикацию. Спасибо за новые знания!)
А по существу: я бы с удовольствием проверил бы ваши тесты, особенно на данных, которые сжимаются не очень и для которых CFS неэффективна, а дополнительную нагрузку на процессор создает. Но вы же, в отличие от Microsoft и Oracle, не даете ни Postgres Pro Enterprise для тестирования, ни права публиковать то, что будет можно будет увидеть.
Поэтому придется вам верить на слово и думать, а с чего вдруг вам потребовалось все запрещать. Вроде же скрывать нечего, правда же?)
Так вы проверять-то будете или только ехидные(нет) комментарии оставлять будете?
Я вам только что написал, что тестировать не на чем, потому что открытая и ничего не скрывающая компания Postgres Pro не дает Enterprise для тестирования (в отличие, например, от Microsoft SQL Server и Oracle, где все лежит в открытом доступе). Ну или дает, но только тем, кто не напишет про этот продукт что-нибудь неодобренное.
Приношу свои извинения, что проверить ваши тесты не могу, хотя и очень хочу(
В первом конфиге effective_cache_size указан 2 раза
Други, вот читаю я статьи (и за плечами 15 лет оптимизации производительность MS SQL Server под сотни различных платформ начиная с серверов с 1гб озу и винчестерами на борту). И сразу вспоминается случай из жизни когда один довольно крупный банк сделал серьезные инвестиции в абсолютно свежую архитектуру Intel где процессоры были с огромным (40-80) кажется количеством ядер. И с удивлением обнаружил, что процессы которые он так хотел ускорить своими инвестициями под 1мио зелени, на самом деле замедлились примерно в 2 раза. Прозорливый человек сразу найдет ответ - частота процессоров с бОльшим количеством ядер была практически в 2 раза ниже нежели использовавшееся в предыдущем поколении 6-ядерников.
К чему все это - "производительность" серверов БД измеряется количеством транзакций в секунду только в крайне ограниченном и довольно редком спектре сценариев. Для 70% бизнесов гораздо бОльшей ценностью будет обладать банальная большая тактовая частота и конечно же более быстрые диски (и их близость к процессору, поэтому NVME). Именно поэтому существует не 1 единственный и достаточный тест TPC, а довольно большое количество профилей.
PS из личного опыта PG прекрасен даже в базовых настройках если ставишь его просто на актуальный (в плане архитектуры) сервер ценой условно 100 долл/мес. И дальше любые проблемы перфоманса - это на 95% кривые руки разработчиков. Именно в настройки/ограничения сервера еще ни разу не видел чтобы упирались. Даже финансовые брокера с огромным потоком заявок сделок которые процессятся (и учет и риск-мендежмент) через функции в PG вполне себе могут использовать стандартные настройки и типовое железо. Да и нужно понимать, что любой труд по "оптимизации" должен быть оправдан. И если раньше стоимость сервера для бизнеса была сопоставима с полугодовой зарплатой "оптимизатора", то сейчас все поменялось. И любые попытки меряться транзакциями в секунду вызывают только немой вопрос - "у вас это хобби (за месяц изысканий добиться +5% пикового перфоманса) или я тупой, но покажите мне бизнес, где выгодно это оплачивать (при том что бизнес никогда не живет в пиковых производительностях - уже при 60-70% нужно начинать действия по изменениям)?"
Как говорится - подписываюсь под каждым словом, именно так по реальной жизни происходит.
"производительность" серверов БД измеряется количеством транзакций в секунду только в крайне ограниченном и довольно редком спектре сценариев.
IMHO только один сценарий - pbench на физических серверах.
любые проблемы перфоманса - это на 95% кривые руки разработчиков.
Однако есть одна очень серьезная проблема - объяснить все это манагерам и разрабам.
По личному опыту , это очень серьезная проблема , цитат и перлов можно привести не на одну статью.
Если я правильно понял, то на сервере был RAM 1Tb. При этом база была "146 Gb без сжатия и 13 Gb при включённом CFS.". Т.е., грубо говоря, вся база была закешинована в оперативке, а дисковые операции были только на запись, чтобы синхронизировать данные. По факту данное сравнение получается "проверка производительности pg* без влияния дисковой системы".
Было бы интересно посмотреть на сравнение, когда дисковая подсистема влияет на производительность. Т.е. те же тестирования, но на сервере с 8 Gb оперативки. Тогда и 146 не будут влезать в кеш, и 13 точно также не будут влезать в кеш. Может это будет и худшее сравнение "какая числодробилка лучше", но зато будут приближены к реальным условиям.
И вдогонку, после размышлений.
1) Нет утилизации памяти процессами пг. Занимает ли pg pro c cfs меньше памяти, или нет? Я не работал с данной технологией, поэтому не знаю. Если памяти меньше - круто, молодцы.
2) Если меряемся размером данных на диске. Давайте тогда и pg ванильный запустим на btrfs со сжатием! И посмотрим как это влияет на скорость и реальный размер данных
Всё правильно говорите, но наша задача была повторить тесты коллег из селектела, чтобы без претензий что мы ручки подкрутили. Или не докрутили )
Каждый тест выполнялся 600 секунд.
А почему для тестов выбран столь короткий промежуток времени ?
Не проводились ли аналогичные замеры , но за более долгий период ? Например 1 час ?
Есть уверенность , и на чем она основана, что на результаты не повлиял шум ?
для снижения флуктуаций было выполнено по 3 итерации тестов с усреднением полученных результатов.
Почему так мало итераций ?
Под усреднением подразумевается "среднее арифметическое" ?
Если мы что-то протестировали не так или что-то забыли, обязательно напишите в комментариях. Исправимся и дотестируем.
Не кажется ли автору , что для столь серьёзных выводов было выполнено недостаточное количество столь коротких тестовых замеров ?
Серьезные тесты стоят серьезных денег. Да и не релевантны они для большинства. Нормальные бизнеса сами себе тесты ставят на своем характере нагрузок на различном железе. И для измерения пикового перфоманса и для нагрузочных тестирований сутками гоняют нагрузку в 70-80% от максимальной. Но это совсем другая история. И только там где это реально стоит денег / может иметь эффект большин финансовых и репутационных рисков.
для измерения пикового перфоманса и для нагрузочных тестирований сутками гоняют нагрузку
Тоже пришел к такому выводу - для получения более менее статистически значимых результатов нужны минимум сутки.
Возможно , для физических серверов время тестирования можно сократить , но в облаках влияние инфраструктуры очень неравномерно .
Продолжаем выжимать максимум из PostgreSQL