Комментарии 50
Я вам скажу по секрету что на JFS будет еще быстрее.
Ну а по тесту — где тест на запись?!
Я имею ввиду вставка например 100 миллионов записей в одну таблицу.
Ну а по тесту — где тест на запись?!
Я имею ввиду вставка например 100 миллионов записей в одну таблицу.
>> Я вам скажу по секрету что на JFS будет еще быстрее
цели проверить все ФС небыло)) (хотя еще тестировалась Btrfs)
>>Ну а по тесту — где тест на запись?!
>>Я имею ввиду вставка например 100 миллионов записей в одну таблицу.
жаль что вы не смотрите раздел с вопросами, я бы обязательно учел ваше пожелание.
цели проверить все ФС небыло)) (хотя еще тестировалась Btrfs)
>>Ну а по тесту — где тест на запись?!
>>Я имею ввиду вставка например 100 миллионов записей в одну таблицу.
жаль что вы не смотрите раздел с вопросами, я бы обязательно учел ваше пожелание.
С какими параметрами смонтированы файловые системы?
С какими параметрами они были отформатированны?
С какими параметрами они были отформатированны?
Отформатированы и смонтированы по умолчанию которые определены в gentoo (/etc/mke2fs.conf):
base_features = sparse_super,filetype,resize_inode,dir_index,ext_attr
default_mntopts = acl,user_xattr
enable_periodic_fsck = 0
blocksize = 4096
inode_size = 256
inode_ratio = 16384
Доп. параметров для mkfs и mount не передавалось.
ext3/ext4 по умолчанию rw,user_xattr,acl
xfs по умолчанию rw
base_features = sparse_super,filetype,resize_inode,dir_index,ext_attr
default_mntopts = acl,user_xattr
enable_periodic_fsck = 0
blocksize = 4096
inode_size = 256
inode_ratio = 16384
Доп. параметров для mkfs и mount не передавалось.
ext3/ext4 по умолчанию rw,user_xattr,acl
xfs по умолчанию rw
noatime, nodiratime и при удачном положении планет в созвездиях, можно выиграть десяток-другой % I/O.
Я вообще не понял, что вы тестили и для чего. Базу данных или файлуху?
Файловые системы, в принципе, все одинаковые и из коробки будут отличаться незначительно. Успех достигается в тюнинге и в выборе файловой системы под конкретную задачу.
Некоторые файловые системы сильно быстрые, но если использовать их неправильно, будут проблемы.
Лучшая файловая система для постгреса — это больше памяти.
Я вообще не понял, что вы тестили и для чего. Базу данных или файлуху?
Файловые системы, в принципе, все одинаковые и из коробки будут отличаться незначительно. Успех достигается в тюнинге и в выборе файловой системы под конкретную задачу.
Некоторые файловые системы сильно быстрые, но если использовать их неправильно, будут проблемы.
Лучшая файловая система для постгреса — это больше памяти.
— ext3. периодические затупы на вызове fsync вот как раз у postgres. Иноды опять же ограничены, сабдиректории. Надежная, как паровоз, правда.
— xfs. много миллионов файлов и почти полный диск? краш-краш-краш.
— reiserfs. Много пишите и перемещаете? Скоро вам придется делать rebuild-tree.
— btrfs. Сыровато, хотя и быстро. Краш-краш-краш.
— %любая_файловая_система% тоже что-то обязательно не так.
— xfs. много миллионов файлов и почти полный диск? краш-краш-краш.
— reiserfs. Много пишите и перемещаете? Скоро вам придется делать rebuild-tree.
— btrfs. Сыровато, хотя и быстро. Краш-краш-краш.
— %любая_файловая_система% тоже что-то обязательно не так.
>> Я вообще не понял, что вы тестили и для чего. Базу данных или файлуху?
было любопытно есть ли разница в скорости постгреса на разных фс.
>> Лучшая файловая система для постгреса — это больше памяти.
это да, бесспорно
>> ext3. периодические затупы на вызове fsync вот как раз у postgres
а с ext4 такое наблюдается?
>> btrfs. Сыровато, хотя и быстро
сыровато, но я бы не сказал что очень быстро, у меня раздел с портеджами, и както все медленно по ощущениям
было любопытно есть ли разница в скорости постгреса на разных фс.
>> Лучшая файловая система для постгреса — это больше памяти.
это да, бесспорно
>> ext3. периодические затупы на вызове fsync вот как раз у postgres
а с ext4 такое наблюдается?
>> btrfs. Сыровато, хотя и быстро
сыровато, но я бы не сказал что очень быстро, у меня раздел с портеджами, и както все медленно по ощущениям
ext4 пошустрее будет, но с ней были проблемы, допустим, у виртуалок openvz, когда механизм подсчета квот крашился на ней. У нас продакшн так просто не переделать, а в тестовых условиях там непонятно, эти несколько процентов действительно выйгрыш, либо это лишь погрешности и неправильные методологии тестирования. И ради этих неподтвержденных процентов все перенастраивать будет дорого довольно.
Мы свой постгрес как только не мучили уже. Файлуху меняли, железо, всякие флешкэши и смарткэши на винтах, ссд и прочее. Если разница и есть, то ее так незаметно )) Ну если не брать заведомо ненадежные суперкэши writeback.
Память только помогает.
Мы еще тестили разные файлухи для хранения 20 миллионов файлов, обновляемых каждые 25 суток, ничего лучше ext3 не видели еще )))
Мы свой постгрес как только не мучили уже. Файлуху меняли, железо, всякие флешкэши и смарткэши на винтах, ссд и прочее. Если разница и есть, то ее так незаметно )) Ну если не брать заведомо ненадежные суперкэши writeback.
Память только помогает.
Мы еще тестили разные файлухи для хранения 20 миллионов файлов, обновляемых каждые 25 суток, ничего лучше ext3 не видели еще )))
Странно что у вас флэшкеш не взлетел, мы поставили SSD (HP MO0200EBTJU), собрали facebook'овский flashcache и ощутили достаточно сильный профит в плане скорости. Две независимых друг до друга установки работают уже как чуть больше полгода и судя по мониторингам износ ssd еще крайне мал.
Да еще один момент.Советую все таки поставит не gentoo а что-то вроде SLES или RHEL. У нас работало быстрее.
Ну конечно это вряд ли зависит от дженты, скорее это зависит от прямых рук ставящего софт. Однако же не забывайте о таком замечательном сайтике, товарищи, на нем имеются зерна истины: funroll-loops.info/
Угу… Я так и представил как админ будет сидеть профилировать систему с разными флагами USE и компилятора, для того что бы сделать базу быстрее… Не смешите мои тапки. Сколько он времени на это потратит?
Вы знакомы с Gentoo по статям на луркморе, или имеет реальный опыт использования этого дистрибутива?
Достаточно большой опыт использования Gentoo в серверном направлении, некоторые вещи в этом дистрибутиве мне очень нравятся.
Я много чего сделал для Gentoo в свое время. Например вот этот документ — www.gentoo.org/doc/en/utf-8.xml.
Сейчас немного другие цели, потому Gentoo и не использую.
Сейчас немного другие цели, потому Gentoo и не использую.
Все же мне не понятно, как USE флаги при сборке postgresql на gentoo могут повлиять на его производительность?
Ну во-первых через USE можно включать нужный функционал.
А во-вторых через CFLAGS задаются оптимизации компилятору.
И самое сложное в том что бы собрать систему(glibc особенно) с нужными параметрами, которые дадут больший перформанс. Лет 5 назад мы на работе проверяли расчет матрици комбинация на Erlang.
На SLES 1,5 миллиона вариантов развернулись за 4,3 секунды, а на Gentoo за 15,2.
Железо одно и тоже, версии тоже примерно одинаковые были. Но SuSE кроме просто сборки еще и занимается профилированием, чего gentoo никогда делать не будут.
А во-вторых через CFLAGS задаются оптимизации компилятору.
И самое сложное в том что бы собрать систему(glibc особенно) с нужными параметрами, которые дадут больший перформанс. Лет 5 назад мы на работе проверяли расчет матрици комбинация на Erlang.
На SLES 1,5 миллиона вариантов развернулись за 4,3 секунды, а на Gentoo за 15,2.
Железо одно и тоже, версии тоже примерно одинаковые были. Но SuSE кроме просто сборки еще и занимается профилированием, чего gentoo никогда делать не будут.
>> У нас работало быстрее
все ведь относительно, у нас на продакшене на другом железе тоже совершенно иные показатели
все ведь относительно, у нас на продакшене на другом железе тоже совершенно иные показатели
согласен. У нас сторедж был отдельной железкой через гигабитный файбр ченел
во!!! это отдельная песня)) там вобще все по другому… одно дело если к стораджу подключен всего однин клиент и другое дело когда там несколько клиентов…
( давайте призовем amarao )
( давайте призовем amarao )
Блин а что можно ожидать от теста только для чтения? а на update и insert?
Вообще ни о чем.
1. Настройки постгреса? Например размер shared_buffers?
2. Записи нет совсем. Точнее не показательна
3. Лог iostat?
4. Размер кеша контролера/размер оперативки по отношению к размеру БД/индексов.
Вывод конечно правильный, практика показывает что PostgreSQL достаточно эффективно работает с файловыми системами (с ext2 он будет работать еще быстрее :) ). Но эта же практика показывает что если БД не помещается в оперативу хороших скоростей ФС не обеспечит. Но я склонен считать что во время вашего тестирования все попадало в кэш. Ибо примерно теже цифры мы получали на 380 G7, на обычном SATA2 7200 причем они были одинаковы с SSD шным диком (чиста бытовым интелом), но с достаточным количеством озу. Ровно до тех пор пока озу не заканчивалось. И вот тогда начинали работать диски, рос %util в iostat и tps упало до нескольких десятков на HDD и почти не изменилось на SSD. Вот в этих режимах (однозначно не штатных) и интересно посмотреть на сравнение систем.
1. Настройки постгреса? Например размер shared_buffers?
2. Записи нет совсем. Точнее не показательна
3. Лог iostat?
4. Размер кеша контролера/размер оперативки по отношению к размеру БД/индексов.
Вывод конечно правильный, практика показывает что PostgreSQL достаточно эффективно работает с файловыми системами (с ext2 он будет работать еще быстрее :) ). Но эта же практика показывает что если БД не помещается в оперативу хороших скоростей ФС не обеспечит. Но я склонен считать что во время вашего тестирования все попадало в кэш. Ибо примерно теже цифры мы получали на 380 G7, на обычном SATA2 7200 причем они были одинаковы с SSD шным диком (чиста бытовым интелом), но с достаточным количеством озу. Ровно до тех пор пока озу не заканчивалось. И вот тогда начинали работать диски, рос %util в iostat и tps упало до нескольких десятков на HDD и почти не изменилось на SSD. Вот в этих режимах (однозначно не штатных) и интересно посмотреть на сравнение систем.
1. Добавил
2. Это вам к разработчикам TPC-B, и pgbench (pgbench не умеет к сожалению регулировать пропорции чтения/записи)
3. iostat не снимался, не было цели смотреть задержки (disk util же очевидно 100%)
4. данные об оборудовании есть в шапке, не хватающих параметров железа можно найти в интернетах
Вопрос такой, как это «все» попадало в кэш, если база больше оперативы в 5 раз и чтение/запись осуществляется из случайных участков базы… по моему так кэш постоянно перемешивается, не?
2. Это вам к разработчикам TPC-B, и pgbench (pgbench не умеет к сожалению регулировать пропорции чтения/записи)
3. iostat не снимался, не было цели смотреть задержки (disk util же очевидно 100%)
4. данные об оборудовании есть в шапке, не хватающих параметров железа можно найти в интернетах
Вопрос такой, как это «все» попадало в кэш, если база больше оперативы в 5 раз и чтение/запись осуществляется из случайных участков базы… по моему так кэш постоянно перемешивается, не?
disk util зачастую ни о чём не говорит. Нет цели смотреть на задержки? Счастливый человек!
так задержки при обращении к диску я выясню более простыми средствами)) для этого не нужен огород из разных фс и постгреса поверх.
Если бы disk util был 100% не было бы >100 tps. iostat бы показал что работа действительно ведется с диском а значит и с файловой системой, а не с shared_buffers (что весомо особенно при значительном числе клиентов) и не с кешем операционной системы. Что тест реально гоняет файловую систему, а не обращается последовательно по таблице от начало до конца в пределах размера кеша. Задержки покажут что действительно работаем, а не читаем из кеша контроллера и т.д.
Опять таки размещая WAL вместе с данными замазали почти все что различно у файловых систем. и преалокацию, и работу с sync. Вот даже по вашему тесту вы уверенны что скорость работы ограничивалась именно доступом к файлам таблиц, а не с коммитом WAL. Особенно в тестах TPC-B. Средняя скорость транзакций 100tps в течении двух часов это неинтересно. Может у вас первые полчаса было под 20-30 тысяч а остальные полтора часа менее 10. (Пока индексы помещаются в shared_buffers скорость вставки может быть и 40k/s а потом ррраз и резко 2-3 записи).
Опять таки размещая WAL вместе с данными замазали почти все что различно у файловых систем. и преалокацию, и работу с sync. Вот даже по вашему тесту вы уверенны что скорость работы ограничивалась именно доступом к файлам таблиц, а не с коммитом WAL. Особенно в тестах TPC-B. Средняя скорость транзакций 100tps в течении двух часов это неинтересно. Может у вас первые полчаса было под 20-30 тысяч а остальные полтора часа менее 10. (Пока индексы помещаются в shared_buffers скорость вставки может быть и 40k/s а потом ррраз и резко 2-3 записи).
>> Может у вас первые полчаса
Ну это гипотеза, предполагать можно что угодно.
Давайте так. Определим наиболее подходящий сценарий теста здесь Ведь я не зря задавал этот вопрос, а теперь когда тема привлекла столько внимания, у меня будет больше шансов учесть все нюансы.
Ну это гипотеза, предполагать можно что угодно.
Давайте так. Определим наиболее подходящий сценарий теста здесь Ведь я не зря задавал этот вопрос, а теперь когда тема привлекла столько внимания, у меня будет больше шансов учесть все нюансы.
>>>> Может у вас первые полчаса
>> Ну это гипотеза, предполагать можно что угодно.
Вот и iostat помог бы подтвердить или опровергнуть.
Я вообще склонен к большому числу тестов кратковременных. например не два часа теста и среднее, а последовательно подряд 24 теста по 5 минут. заодно и увидим равномерно ли, если ли пики, насколько они существенны/незначительны, меняется ли со временем.
Ну и вторая склоннось — обложить все различными логами от iostat до top и поотм искать корреляции. А то мало ли ext4 быстрее но отжирает 100% CPU. У меня вот прямо сейчас под постгрессом UPDATE одной записи в табличке из 5 записей общим размером меньше 10 килобайт занимает 62 минуты. А все потому что fs фрагментировано свободное пространство и любой чих с файловой системой приводит к 95%sys на полчаса. (кстати xfs забитая на 95%)
>> Ну это гипотеза, предполагать можно что угодно.
Вот и iostat помог бы подтвердить или опровергнуть.
Я вообще склонен к большому числу тестов кратковременных. например не два часа теста и среднее, а последовательно подряд 24 теста по 5 минут. заодно и увидим равномерно ли, если ли пики, насколько они существенны/незначительны, меняется ли со временем.
Ну и вторая склоннось — обложить все различными логами от iostat до top и поотм искать корреляции. А то мало ли ext4 быстрее но отжирает 100% CPU. У меня вот прямо сейчас под постгрессом UPDATE одной записи в табличке из 5 записей общим размером меньше 10 килобайт занимает 62 минуты. А все потому что fs фрагментировано свободное пространство и любой чих с файловой системой приводит к 95%sys на полчаса. (кстати xfs забитая на 95%)
>Вопрос такой, как это «все» попадало в кэш, если база больше оперативы в 5 раз и чтение/запись осуществляется из >случайных участков базы… по моему так кэш постоянно перемешивается, не?
Все не попадало, данные пишутся более менее равномерно, есть шанс что эффекетивно работает prefetch и поднимает данные для следующего запроса в кеш.и он в итоге так «окошком» и идет. Кстати легко проверить: при работе запросов на выборку в цикле дропать кеш :) по вашей теории это не будет влиять ибо все равно все перемешено и идет мимо кеша.
Все не попадало, данные пишутся более менее равномерно, есть шанс что эффекетивно работает prefetch и поднимает данные для следующего запроса в кеш.и он в итоге так «окошком» и идет. Кстати легко проверить: при работе запросов на выборку в цикле дропать кеш :) по вашей теории это не будет влиять ибо все равно все перемешено и идет мимо кеша.
SSD на базах не катит, у SSD 10000-100000 перезаписей блока, при большом обьеме изменений, диски будут лететь только в путь. Боюсь, что лучше SAS RAID пока ничего нет…
Еще как катит, тут лишь встает вопрос стоимости и реализации, есть узкоспециализированные решения типа NetApp EF540 — сторадж с набором до 24 SSD общей емкости 19,2TB. Но и стоит этот девайс как несколько квартир в центре Мск.
Тут надо смотреть для чего больше база используется. Если больше для чтения то да. У меня к примеру все проекты работают постоянно на запись и обновление данных в базе. Я не решаюсь использовать SSD. В сутки проходит около 100 000 000 апдейтов, пот посудите сами, если у SSD заявено что он выжевит только 10 000-100 000 перезаписей одного блока, то насколько мне бы хватило этих дисков? В моей ситуации даже на slave нельзя SSD ставить, так как репликация неприрывная. Поэтому чтобы вы не говорили SAS в RAID помоему пока самое адекватное решение для БД.
Ну в целом серьезные SSD накопители заявляют до нескольких петабайт записи. Если пишем терр в сутки то на пару лет должно хватить :) Опять же многомного памяти, длинные чекпоинты и еще подольше. Мы тут прикидывали — разница по стоимости HDD 10к/SSD порядка 10 раз. А по производительности от 3х до 10х. Там проблема встаеть уже в 6G интерфейсе. Приходится PCIE думать а тут уже с горячей заменой сложности.
Но в целом думаю за SSD будущее СУБД. Да и последний HighLoad. Все у кого более менее серьезное чтото, где требуется хоть какаято надежность (всякие фейсбуки не в счет). Так или иначе — реляционки + флеш, у кого под хранение, у кого под кеш.
Но в целом думаю за SSD будущее СУБД. Да и последний HighLoad. Все у кого более менее серьезное чтото, где требуется хоть какаято надежность (всякие фейсбуки не в счет). Так или иначе — реляционки + флеш, у кого под хранение, у кого под кеш.
Дело не в петабайтах, а в количестве перезаписи одного блока. Даже если сброс на диск сделать асинхронным и вхреначить памяти побольше, боюсь при огромных количествах перезаписях не долго они протянут. Пока заявленные цифры перезаписи блока малы, так то конечно я за SSD их скорость отличная, но пока приходится использовать SAS.
Информационность теста устремлена к нулю, т.к. надо
1. вывод iostat при одинаковых нагрузках(задачах)
2. исследование опций монтирование на скорость фс и награзку на физические диски
3. Графики во времени, т.к. поведение может меняться из-за кэширования ФС и БД
т.к. всего этого нет, мы и не видим никакой разницы.
1. вывод iostat при одинаковых нагрузках(задачах)
2. исследование опций монтирование на скорость фс и награзку на физические диски
3. Графики во времени, т.к. поведение может меняться из-за кэширования ФС и БД
т.к. всего этого нет, мы и не видим никакой разницы.
1. про iostat написал выше. Выводы iostat во всех случая были бы одинаковые, поскольку оно показывает показатели работы с диском, а не к фс.
2. это уже совсем отдельная тема исследования. я искал истину с опциями по умолчанию
3. графики во времени это хорошо. но в них не всегда есть необходимость. Pgbench дает «среднюю температуру по больнице в tps» что конечно плохо, мы не сможем увидеть пики и падения в tps, но чтобы избежать влияния вот таких вот всплесков tps, (связанных в том числе с кэшированием ФС) мы увеличиваем время длительности теста (до двух часов например) чтобы средний tps независим от всплесков.
2. это уже совсем отдельная тема исследования. я искал истину с опциями по умолчанию
3. графики во времени это хорошо. но в них не всегда есть необходимость. Pgbench дает «среднюю температуру по больнице в tps» что конечно плохо, мы не сможем увидеть пики и падения в tps, но чтобы избежать влияния вот таких вот всплесков tps, (связанных в том числе с кэшированием ФС) мы увеличиваем время длительности теста (до двух часов например) чтобы средний tps независим от всплесков.
Хотелось бы увидеть тесты, более приближенные к реальности. С графиками. И обоими Riser'ами
Кроме производительности разные FS обладают некоторыми полезными фичами. XFS (равно как Reiser и JFS) в купе с LVM, например можно растянуть на горячую, чего не сделаешь с семейством EXT.
Кстати еще советую взять EnterpriseDB. Это постгрес собраный интеловским компилятором(плюс поддержка языка SQL оракла). На оптеронах скорость была выше чем gcc сборка. Тут вообще поле для экспериментов очень большое. Все еще зависит от того какие у Вас данные в базе.
Не буду советовать за EnterpriseDB. Его самый большой плюс это коммерческие консультации/поддержка/ Практически все гуру PG «живут» им. По чистой скорости работы, некоторые оптимизации конечно есть, но не ключевые. А насчет Оракловых хранимок в PG ощущение двоякое. Видел я код для PG писаный Оракловцем. Спасибо не надо. Просто некоторые вещи с постгрессе сделаны совсем не так как в оракле. И использующий, например вьюшки для оптимизации времени исполнения программер оракла не может даже представить что в постгрессе они ни коим образом не материализуются, совсем. И мест таких достаточно. Так что бездумно код переносить не стоит.
Но конечно ODBC более «взрослый» что ли.
Но повторюсь: какой то принципиальной разницы, особенно в использовании диска, не будет. Ребята из Enterprise DB вроде более менее честные и свои концептуальные изменения бекпортят в основной Постгрес.
Но конечно ODBC более «взрослый» что ли.
Но повторюсь: какой то принципиальной разницы, особенно в использовании диска, не будет. Ребята из Enterprise DB вроде более менее честные и свои концептуальные изменения бекпортят в основной Постгрес.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PostgreSQL на разных фс (ext3, ext4, xfs)