полгода назад мы тоде шли на определенный риск, сейчас там добавили такую фичу, что в случае вылета SSD диска, все запросы направляются на основной диск и flashcache-том не разваливается как раньше с IO Error, а продолжает работать.
Еще как катит, тут лишь встает вопрос стоимости и реализации, есть узкоспециализированные решения типа NetApp EF540 — сторадж с набором до 24 SSD общей емкости 19,2TB. Но и стоит этот девайс как несколько квартир в центре Мск.
Странно что у вас флэшкеш не взлетел, мы поставили SSD (HP MO0200EBTJU), собрали facebook'овский flashcache и ощутили достаточно сильный профит в плане скорости. Две независимых друг до друга установки работают уже как чуть больше полгода и судя по мониторингам износ ssd еще крайне мал.
>> Может у вас первые полчаса
Ну это гипотеза, предполагать можно что угодно.
Давайте так. Определим наиболее подходящий сценарий теста здесь Ведь я не зря задавал этот вопрос, а теперь когда тема привлекла столько внимания, у меня будет больше шансов учесть все нюансы.
1. про iostat написал выше. Выводы iostat во всех случая были бы одинаковые, поскольку оно показывает показатели работы с диском, а не к фс.
2. это уже совсем отдельная тема исследования. я искал истину с опциями по умолчанию
3. графики во времени это хорошо. но в них не всегда есть необходимость. Pgbench дает «среднюю температуру по больнице в tps» что конечно плохо, мы не сможем увидеть пики и падения в tps, но чтобы избежать влияния вот таких вот всплесков tps, (связанных в том числе с кэшированием ФС) мы увеличиваем время длительности теста (до двух часов например) чтобы средний tps независим от всплесков.
1. Добавил
2. Это вам к разработчикам TPC-B, и pgbench (pgbench не умеет к сожалению регулировать пропорции чтения/записи)
3. iostat не снимался, не было цели смотреть задержки (disk util же очевидно 100%)
4. данные об оборудовании есть в шапке, не хватающих параметров железа можно найти в интернетах
Вопрос такой, как это «все» попадало в кэш, если база больше оперативы в 5 раз и чтение/запись осуществляется из случайных участков базы… по моему так кэш постоянно перемешивается, не?
во!!! это отдельная песня)) там вобще все по другому… одно дело если к стораджу подключен всего однин клиент и другое дело когда там несколько клиентов…
( давайте призовем amarao )
здесь тесты проводятся для того чтобы посмотреть сколько транзакций выдержит база при n-нном количестве клиентов с разным типом нагрузки (ro,rw). В результате видно, что в каких-то случаях обрабатывается большее кол-во транзакций.
>> Я вам скажу по секрету что на JFS будет еще быстрее
цели проверить все ФС небыло)) (хотя еще тестировалась Btrfs)
>>Ну а по тесту — где тест на запись?!
>>Я имею ввиду вставка например 100 миллионов записей в одну таблицу.
жаль что вы не смотрите раздел с вопросами, я бы обязательно учел ваше пожелание.
ESXi это же linux, установите туда утилиту для работы с вашим raid-контроллером и через эту утилиту сможете увидеть свой диск и его статус, ну а дальше можно написать скриптовую обвязку для периодической проверки и отправки данных в случае чего.
было любопытно есть ли разница в скорости постгреса на разных фс.
>> Лучшая файловая система для постгреса — это больше памяти.
это да, бесспорно
>> ext3. периодические затупы на вызове fsync вот как раз у postgres
а с ext4 такое наблюдается?
>> btrfs. Сыровато, хотя и быстро
сыровато, но я бы не сказал что очень быстро, у меня раздел с портеджами, и както все медленно по ощущениям
Ну это гипотеза, предполагать можно что угодно.
Давайте так. Определим наиболее подходящий сценарий теста здесь Ведь я не зря задавал этот вопрос, а теперь когда тема привлекла столько внимания, у меня будет больше шансов учесть все нюансы.
2. это уже совсем отдельная тема исследования. я искал истину с опциями по умолчанию
3. графики во времени это хорошо. но в них не всегда есть необходимость. Pgbench дает «среднюю температуру по больнице в tps» что конечно плохо, мы не сможем увидеть пики и падения в tps, но чтобы избежать влияния вот таких вот всплесков tps, (связанных в том числе с кэшированием ФС) мы увеличиваем время длительности теста (до двух часов например) чтобы средний tps независим от всплесков.
2. Это вам к разработчикам TPC-B, и pgbench (pgbench не умеет к сожалению регулировать пропорции чтения/записи)
3. iostat не снимался, не было цели смотреть задержки (disk util же очевидно 100%)
4. данные об оборудовании есть в шапке, не хватающих параметров железа можно найти в интернетах
Вопрос такой, как это «все» попадало в кэш, если база больше оперативы в 5 раз и чтение/запись осуществляется из случайных участков базы… по моему так кэш постоянно перемешивается, не?
( давайте призовем amarao )
здесь тесты проводятся для того чтобы посмотреть сколько транзакций выдержит база при n-нном количестве клиентов с разным типом нагрузки (ro,rw). В результате видно, что в каких-то случаях обрабатывается большее кол-во транзакций.
все ведь относительно, у нас на продакшене на другом железе тоже совершенно иные показатели
цели проверить все ФС небыло)) (хотя еще тестировалась Btrfs)
>>Ну а по тесту — где тест на запись?!
>>Я имею ввиду вставка например 100 миллионов записей в одну таблицу.
жаль что вы не смотрите раздел с вопросами, я бы обязательно учел ваше пожелание.
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
hpacucli ctrl slot=4 pd all show