Почему SSD тормозят при добавлении их разделов в разные пулы и их кэш?

Latency and iops имеют обратно пропорциональную зависимость, с чего то ты их разделил.

я тоже так думал и спрашивал в чате zfsonlinux, но мне ответили, что практика иногда отличается от теории

по собственным наблюдениям при добавлении десктопных SSD в SLOG их утилизация сразу же поднимается выше 50%, а то и упирается в 100%, про Intel я уже упоминал, что даже, находясь в двух пулах одновременно, их утилизация плавает где-то между 5% и 10%
вот тебе и пропорциональная зависимость
хотя, возможно, если последовательно читать ISOшник, то Desktop SSD могут оказаться и в выигрыше, но как это относится к моему случаю остается загадкой

Какой нафиг новомодный? Его специально придумали для таких применений как лог фс, кеш БД, и пр Энтерпрайз штучки. https://www.hgst.com/products/solid-state-solutions/zeusram-sas-ssd

Энтерпрайз от десктопа отличается ресурсом перезаписи и только. Все остальное маркетинговые уловки. Кондеры есть и в десктоп дисках, и не только ssd.

От пропадания питания не спасает ни ssd ни zfs, да благодаря транзакциям она откатится до непротиворечивого состояния, но в случае с БД есть один момент: транзакция бд <> транзакция фс.

Энтерпрайз от десктопа отличается ресурсом перезаписи и только. Все остальное маркетинговые уловки. Кондеры есть и в десктоп дисках, и не только ssd.

если погуглить, то можно найти и другие мнения

От пропадания питания не спасает ни ssd ни zfs, да благодаря транзакциям она откатится до непротиворечивого состояния, но в случае с БД есть один момент: транзакция бд <> транзакция фс.

инфа на HDD скорее докатится из SLOG, хотя в слоге может и будет какой-то небольшой откат назад

после запуска базы, если ZFS чего-то и откатила, то и промышленная СУБД после restart db сделает то же самое по своим recovery логам

Какой нафиг новомодный? Его специально придумали для таких применений как лог фс, кеш БД, и пр Энтерпрайз штучки. https://www.hgst.com/products/solid-state-solutions/zeusram-sas-ssd

и много ли РФ продавцов такого популярного в РФ решения?

теперь сравни с Intel 3700

Э… а можешь дать ссылку где написано что l2arc хранит данные в сжатом виде? Насколько я знаю сжатые данные хранятся только на VDEV, может я что-то проспал…

Ну раз 2 гига, значит уменьшили, но до оракловских не дотянули :)

Это не рассуждения, это факты. Proxmox на zfs = kernel panic если виртуалки съели почти весь ram. SmartOS и FreeBSD на это пофиг.

А какие виртуалки ты гоняешь на freebsd?

Э… а можешь дать ссылку где написано что l2arc хранит данные в сжатом виде? Насколько я знаю сжатые данные хранятся только на VDEV, может я что-то проспал…

http://wiki.illumos.org/display/illumos/L2ARC Compression

Это не рассуждения, это факты. Proxmox на zfs = kernel panic если виртуалки съели почти весь ram. SmartOS и FreeBSD на это пофиг.

ну так да, надо мониторить сначала и с калькулятором немного поработать, а потом оно само уже работает

всяко выгоднее по времени, чем солярку изучать

Я такой взгляд на жизнь не разделяю, но это уже оффтопик.

Ну ок, видимо хватает l2arc.

А вообще есть general rule - сначала наращивать ram на сколько позволяет мама, потом l2arc.

сначала наращивать ram на сколько позволяет мама

да старый сервак, ему уже лет 10
там если и можно добавить RAM без замены, то всего несколько гиг
замену наверно можно сделать, надо смотреть, сколько там предел оперативки, возможно потом так и сделаю

но сначала с моей точки зрения эффективнее добавить сразу сотни гиг L2ARC, а уже только потом оперативку, потому что базы то большие и в оперативку их целиком загнать не получится, да даже 10% и то наврядли

кроме того СУБД сама кэширует в своих буферах на другом сервере, там с оперативкой попросторнее, так что на хранилище все же эффективнее наращивать в таком случае именно L2ARC, а не RAM (которой получилось бы на порядок меньше)

и как я уже замечал, Intell SSD приобретены в первую очередь под SLOG, а не L2ARC, поэтому и взята самая маленькая емкость всего 400гиг, а L2ARC уже просто попробовал подключить за компанию, и вообщем то нормально работает, если третий раздел не пихать в другой пул

я тоже так думал и спрашивал в чате zfsonlinux, но мне ответили, что практика иногда отличается от теории

Так говорят те кто не знает теории или не понимает чего меряет. На конференции ruBSD 2014, один товарищ пытался доказать докладчику что SAS дают больше iops чем sata одного формфактора при одинаковом среднем latency.

по собственным наблюдениям при добавлении десктопных SSD в SLOG их утилизация …

Во! про утилизацию есть соседняя тема. Я кстати тоже не пойму чего она показывает, как и что показывает LA в top. У меня на одном серваке о 4 ядрах этот LA показывал 200-400 попугаев! Причём это один процесс грузил все 4 ядра на 100%.

Продолжу про iops. Вот недавно наблюдал как мне zpool iostat показывает 25к операций записи в секунду на пуле из 4 hdd. На первый взгляд теория расходится с практикой аж в 250 раз. На второй - все правильно.

Продолжу про iops. Вот недавно наблюдал как мне zpool iostat показывает 25к операций записи в секунду на пуле из 4 hdd. На первый взгляд теория расходится с практикой аж в 250 раз. На второй - все правильно.

ну так я же в контексте нагрузки СУБД про IOPS всегда упоминаю, а это значит, что операции обязаны быть синхронными

если установить sync=disabled то 4 HDD и 50K random write OPS легко осилят без всяких SSD, только в таком режиме пользователям нельзя работать, потому что в случае выключения питания будет потеря данных

SLOG из Intel SSD как раз для этого и предназначен, чтобы СИНХРОННЫЕ операции записи были очень быстрыми, но потери данных не было

А по асинхронным random IOPS ZFS может удивить своими показателями любого вдумчивого наблюдателя, который не в курсе, что все свои записи - транзакции ZFS делает последовательными (в пределах фрагментации конечно)
даже если это запись поверх уже ранее записанных данных, разбросанных относительно случайно, по факту поверх ничего не пишется, только дополняется. Ну и поверх ZVol ведь еще и ext3, совсем весело получается.

Так говорят те кто не знает теории или не понимает чего меряет. На конференции ruBSD 2014, один товарищ пытался доказать докладчику что SAS дают больше iops чем sata одного формфактора при одинаковом среднем latency.

Так ведь как ни странно, хоть у SSD и нет движущихся частей, но random и serial IOPS сильно отличаются у одной и той же SSD.

Тоже видел упоминания, что диски SAS выдают больше IOPS в режиме random, глупо сравнивать диски SAS и SATA копированием одного большого файла, гораздо веселее наблюдать как на какой-нибудь примитивной файловой системе типа FAT SATA быстро захлебнется от случайной нагрузки, есть мнения, что SAS будет работать немного лучше, лично я не проверял.

Кроме того упоминаются другие различные причины использовать SAS на серверах, в т.ч. якобы более лучшая обработка ситуаций с ошибками чтения, более подходящая для массива, но лично сам недавно наблюдал обратное, хотя возможно, что как раз из-за не HBA контроллера, т.е. JBOD-ы как то не очень ведут себя при сбое диска, пришлось вручную делать detach, чтобы привести производительность пула в норму, но то была старая версия ZOL двухлетней давности, может быть сейчас уже лучше, проапргейдил на всякий.

Во! про утилизацию есть соседняя тема. Я кстати тоже не пойму чего она показывает, как и что показывает LA в top. У меня на одном серваке о 4 ядрах этот LA показывал 200-400 попугаев! Причём это один процесс грузил все 4 ядра на 100%

Ну так, наверно, подразумевается, что 400% - это 100% на каждом ядре?

Я не про top, а про dstat:
dstat --disk-tps --disk-util --disk --fs --freespace --cpu; # --ipc

Когда-то давно, по меркам истории браузера, я читал статью где чуть ли не математически доказывалось что лог ФС и лог БД могут «не совпасть во мнениях» :)

К сожалению не помню точно в чем проблема, но не просто так же оракл стал поддерживать создание БД прямо на raw device. И, емнип, это у них рекомендуемая фича. Firebird кстати тоже умеет. Про остальные не знаю.

Когда-то давно, по меркам истории браузера, я читал статью где чуть ли не математически доказывалось что лог ФС и лог БД могут «не совпасть во мнениях» :)

ну в моем случае - это только по вашим словам теоретически возможное несовпадение мнений ext3 и СУБД, чего сам я ни разу не наблюдал

а ext3 логирует только метаданные по умолчанию и такое использование предусмотрено инструкцией разработчика софта

чем может отличаться состояние после отката транзакции ZFS на ZVol-е в худшую сторону по сравнению с выключением обычного блочного устройства?
Journal recovery ext3 скорее всего почти ничего не сделает
а дальше уже СУБД пройдет обычую процедуру crash recovery

зато разрушение раздела ext2 (без логов ext3 и без ZVol) с базой данных после reset однажды видел

так что, мое мнение по этому поводу полностью противоположное

Я гоняю виртуалки в XenServer, но он мне не очень нравится (не сам xen, а linuxdom0), поэтому жду когда в FreeBSD допилят поддержку не только её самой и линукса, как допилят - перееду на неё. SmartOS всем нравится, но, нету вменяемой веб управлялки (fifo не вменяемая, а libvirt она не умеет), плюс на каждую KVM виртуалку резервирует +1гиг памяти к указанному в конфиге. В общем система для больших датацентров, собственно joyent её по назначению и юзает.

Но знаю чувака гоняющего оракловую базу в виртуальном центосе на фряхе, он забил на xen/linuxdom0 и перевёл виртуалку на bhyve. Говорит что работает идеально.

Вернее так: он ждёт когда в FreeBSD допилят dom0, говорит будет ещё идеальнее :)

Я собирал тестовый стенд на котором тестил proxmox, SmartOS и FreeBSD при условии что образы лежат на ZFS. Тест проксмокса закончился при разворачивании 2-й виртуалки паникой ядра, уменьшение arc_max помогло её только запустить, полная нагрузка на mem и IO окончилась паникой, на xfs/ext3/ext4 работает почти идеально если не считать провалы io временами, значит дело в zfs. Остальные 2 без проблем переварили 100% нагрузку по cpu, mem и io.

О! Вот откуда берутся заоблачные иопсы :D

Спасибо за ссылку, фигасе я поспать…

Ага, советская инженерная школа и годы работы в опп, где цена ошибки - много зелёных пачек денег, впечатали в мозг золотое правило - семь раз отмерь, один раз отрежь.

Не то что щас - х…к х…к и в продакшен (с) менеджмент.

Блин, только щас дошло что это просто сторадж :)

Тем более стоит уделить время на изучение соляры (OmniOS например) или FreeBSD, вдруг подвернётся контора использующая стораджы на солярке/фряхе, всякое в жизни бывает.

чем может отличаться состояние после отката транзакции ZFS на ZVol-е в худшую сторону по сравнению с выключением обычного блочного устройства?

Эээ. Это ты что тут сказать пытаешься? Ты хоть понимаешь, как ZFS работает, зачем нужен ZIL, и так далее?

ну так я же в контексте нагрузки СУБД про IOPS всегда упоминаю, а это значит, что операции обязаны быть синхронными

Ну не все же операции, commit transaction должен вызывать fsync, а то представь что будет если update поля по таблице в 100500 записей начнёт синчить каждый рекорд.

если установить sync=disabled то 4 HDD и 50K random write OPS легко осилят

Не осилят, 200-250 для raid 10, я тебе про реальные иопсы говорил, а не про мнимые, а мои 25к мнимые.

все свои записи - транзакции

А все ли? ЕМНИП, транзакция стартует при fsync от приложения, истечении интервала в 5сек для сброса изменений и синхронизации метаданных, превышении лимита unsync data.

Тем более стоит уделить время на изучение соляры (OmniOS например) или FreeBSD, вдруг подвернётся контора использующая стораджы на солярке/фряхе, всякое в жизни бывает.

в нашем маленьком городке маловероятно, а на вечерней удаленке может быть только програминг

Ну не все же операции, commit transaction должен вызывать fsync, а то представь что будет если update поля по таблице в 100500 записей начнёт синчить каждый рекорд.

верно, каждый комит каждого пользователя, а теперь вcпомним про количество одновременных пользователей

Не осилят, 200-250 для raid 10, я тебе про реальные иопсы говорил, а не про мнимые, а мои 25к мнимые.

а что такое мнимые IOPsы?
первый раз вижу упоминание мнимых

если в db2top во время реорганизации посмотреть physical writes, то можно увидеть около 50K physical writes при sync=disabled, это OPS или что-то другое?

А все ли? ЕМНИП, транзакция стартует при fsync от приложения, истечении интервала в 5сек для сброса изменений и синхронизации метаданных, превышении лимита unsync data.

я делал акцент на последовательности записи, причем тут это, мое утверждение разве противоречит?

Эээ. Это ты что тут сказать пытаешься? Ты хоть понимаешь, как ZFS работает, зачем нужен ZIL, и так далее?

ну как будто блочное устройство отключили в момент окончания последней полной транзакции ZFS, т.е. в состояние, которое потом откатится ZFS, а не состояние, которое было немного позже на блочном устройстве?

Database crash recovery разве не должен нормально отработать с любого состояния, при условии, что все каталоги базы данных находятся на одном и том же ZVol, т.е. и данные и настройки, и логи, т.е. весь /home/db2inst на ZVol Нет обычного блочного устройства (не ZFS), состояние которого бы отличалось от состояние после отката ZFS. Кстати экспериментировал на тестовой базе, размещая логи на другом NFS маунте, и таки да, в таком случае база может не рестартануть, но у меня то все на одном и том же ZVol, который сначала откатывается к консистентному состоянию ZFS, а потом база откатывается к своему консистентному состоянию уже на этом ZVol

можешь считать, что выключение ZVol - это аналог выдергивания блочного устройства в момент окончания полной транзакции ZFS, или не согласен?

ну и кроме того делаются ежечасные снэпшоты в состоянии базы write suspend, уж к ним то можно откатиться точно, но ни разу не пришлось ими воспользоваться по причине сбоя crash recovery, crash recovery всегда нормально отрабатывал

Не осилят, 200-250 для raid 10, я тебе про реальные иопсы говорил, а не про мнимые, а мои 25к мнимые.

с моей точки зрения, тут надо четко понимать, где мы меряем IOPs (причем формально даже синхронизированных!), на vdev или на FS

при sync=disabled

на vdev их будет столько, сколько обычно могут вытянуть HDD, если пул из HDD

ну а на FS легко 50K и даже +over

Нашёл в почте.

top - 09:40:40 up 17:40,  1 user,  load average: 269,99, 225,71, 144,32
Tasks: 180 total,   2 running, 178 sleeping,   0 stopped,   0 zombie
%Cpu0  : 57,2 us, 40,5 sy,  0,0 ni,  1,3 id,  1,0 wa,  0,0 hi,  0,0 si,  0,0 st
%Cpu1  : 57,3 us, 40,3 sy,  0,0 ni,  2,3 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
%Cpu2  : 55,9 us, 33,8 sy,  0,0 ni,  1,3 id,  0,0 wa,  0,0 hi,  9,0 si,  0,0 st
%Cpu3  : 56,3 us, 41,1 sy,  0,0 ni,  2,0 id,  0,7 wa,  0,0 hi,  0,0 si,  0,0 st

Не прикидывайся, ввод-вывод выполняет устройство, где его ещё мерять, вот его io и есть реальный.

А мнимые иопсы в том смысле что ты видишь не то что есть на самом деле. Например, ты видишь 25к/4k random write, а реально пишет 1 sequence 100m block .

Не прикидывайся,

а что такое прикидываться? можно точное определение?

ввод-вывод выполняет устройство, где его ещё мерять, вот его io и есть реальный.

ой ой как интереснооо то :) ! а ZVol тогда что такое? а блочное устройство iSCSI?

а почему у NetApp подобных «чумаданах по цене золота» в рекламе кричат про IOPs блочного устройства или про IOPS NFS mount для VMWare т.е. и вовсе файловой системы с NFS, а не IOPS HDD, который вот вот будет исключен из пула по причине его износа?

А мнимые иопсы в том смысле что ты видишь не то что есть на самом деле.

каком еще таком самом деле?!
вот этом чтоли?
http://lurkmore.to/На_самом_деле

Например, ты видишь 25к/4k random write, а реально пишет 1 sequence 100m block .

ну так у современных файловых систем - повышение IOPS без побочных эффектов - обычно одна из важных функций

если я вижу в db2top на mdraid 1К IOPS, а на ZVol 50K IOPS то где здесь мнимое, а где реальное? мне реально лучше использовать ZVol - инфа 100% ;)

тебе анон уже расписал что и почему, но ты продолжаешь нести не пойми что и гнуть пальцы. это всё от непонимания матчасти.

а почему у NetApp подобных «чумаданах по цене золота» в рекламе кричат про IOPs блочного устройства или про IOPS NFS mount для VMWare т.е. и вовсе файловой системы с NFS, а не IOPS HDD, который вот вот будет исключен из пула по причине его износа?

потому, что есть san, а есть nas.

потому, что есть san, а есть nas.

в смысле NetApp относительно более дорогие из-за поддержки Storage Area Network?

но видел упоминания, как их пиарят именно из-за высокой производительности их NFS сервиса для VMWare ESX, который все операции через NFS шлет синхронно

тебе анон уже расписал что и почему, но ты продолжаешь нести не пойми что и гнуть пальцы. это всё от непонимания матчасти.

а что он конкретно расписал?
то, что виртуальные ZVol, которые передаются в виртуалку выдают мнимые IOPS?
а что такое мнимые?
если мне они систему ускоряют реально, а не мнимо
я про это, а ты про что?

а что такое прикидываться? можно точное определение?

в словаре посмотри

а ZVol тогда что такое? а блочное устройство iSCSI?

virtual device, операции IO выполняются вполне себе реальным physical device.

а почему у NetApp подобных «чумаданах по цене золота» в рекламе кричат про IOPs блочного устройства или про IOPS NFS mount для VMWare т.е. и вовсе файловой системы с NFS, а не IOPS HDD, который вот вот будет исключен из пула по причине его износа?

а потому что в этих «чумаданах по цене золота» понапиханы: дохерагигабайтные cache on PCI-E SuperEnterpriseSSD + дохерагигабайт in memory cache + NetAPP SuperPuperFS использующая тот же принцип записи что и ZFS, а все это надо для того, чтобы не облажаться перед махровым энтерпрайзом требующим миллион иопсов, что легко переварит 1(одна!) 4-х портовая 10 ГБит сетевая карта.

повышение IOPS без побочных эффектов

а какие побочные эффекты бывают от повышения IOPS?

если я вижу в db2top на mdraid 1К IOPS, а на ZVol 50K IOPS

а сколько в это время кажет iostat?

операции IO выполняются вполне себе реальным physical device.

это зависит от контекста обсуждения, например physical write в DB2 на ZVol - ведь для DB2 output operation?


просто ты привык обсуждать операции в контексте железа, где они происходят «на самом деле» :)

а на виртуальном устройстве IOPS виртуализируется, но их точно так же можно измерять и рассуждать о них

мне как их прикажешь называть Virtual IOPs?

из контекста моих сообщений было легко понять, что я имею ввиду виртуальные IOPs

так же как в эмуляторе MIPS или ARM на железе X64 ты можешь увидеть различные параметры, свойственные тем процам, но при этом таких регистров, операций, частот на X86 может и в помине не быть, речь о ВИРТУАЛЬНЫХ попугаях если что, но при всей их виртуальности они очень даже реальны, а вовсе не мнимые

а потому что в этих «чумаданах по цене золота» понапиханы: дохерагигабайтные cache on PCI-E SuperEnterpriseSSD + дохерагигабайт in memory cache + NetAPP SuperPuperFS использующая тот же принцип записи что и ZFS, а все это надо для того, чтобы не облажаться перед махровым энтерпрайзом требующим миллион иопсов, что легко переварит 1(одна!) 4-х портовая 10 ГБит сетевая карта.

ну во первых у нас бюджетная организация, во вторых чем будет хуже обычный сервер, заряженный оперативкой, enterprise SSD и OpenZFS on Linux, Illumos/Nexenta или соляркой?

а какие побочные эффекты бывают от повышения IOPS?

если речь про повышение виртуальных IOPS, то можешь погуглить на тему zfs set sync=disabled или сам поэкспериментировать с выдергиванием питания в таком режиме

а сколько в это время кажет iostat?

не знаю, посмотрю при случае

можешь погуглить на тему zfs set sync=disabled

а чего тут гуглить? любая система позволяет отстрелить себе яйца.

любая система позволяет отстрелить себе яйца.

даже бронетрусы ? :)

а сколько в это время кажет iostat?

http://picpaste.com/pics/MDiJ4xvd.1468380551.jpg

еще бы как то померять количество синхронных операций на сервере СУБД на блочном iscsi устройстве

я про диски, латентности и zfs, в общем. что за мнимые и виртуальные тут у вас я уже чёт перестал догонять.

но видел упоминания, как их пиарят именно из-за высокой производительности их NFS сервиса для VMWare ESX

ну так это доступ на файловом уровне ака nas, логично, что показывают иопсы на уровне файловой системы. так-то у блочных ака san иопсы рэйд-групп.

так-то у блочных ака san иопсы рэйд-групп.

А как ее использовать в приложении? какой от нее профит?

RAID группа для приложения представима в виде одного виртуального блочного устройства, похожего на ZVol?

Наверно, есть какой-то софт, чтобы построить SAN из нескольких iSCSI блоков?

ууу, как тут всё запущено. я те точно говорю матчастью надо заняться.
ОС видит lun как блочное устройство, как хочешь, так и используй.

софт, чтобы построить SAN из нескольких iSCSI блоков?

чего?

я со Storage Area Network незнаком, так мельком читал, что вроде как через SAS интерфейс организуется сеть из SAS устройств, различные экстендеры и т.п. позволяют использовать сотни SAS устройств одновременно, но у меня не было нужды их использовать, соответственно я про них почти не читал ну и значит дуб дубом в этой области (Storage Area Network), я же не отрицаю

описал бы вкратце зачем оно надо, в чем профиты
а то лень изучать

Не SAS.

Fibre Channel (FC), Infiniband (IB).

Вкратце тут https://ru.wikipedia.org/wiki/Сеть_хранения_данных

я про них почти не читал ну и значит дуб дубом в этой области

я тебе и намекаю, что в дисковой подсистеме ты не шаришь. и это касается не только san.

в кратце, один ящик о 100/1000 hdd/ssd на 10к/100к/1м оипс пилят на «диски» для разных систем с одновременным доступом, вот как-то так. а заниматься базовым образованием, уж извини.

я тебе и намекаю, что в дисковой подсистеме ты не шаришь. и это касается не только san.

а я тебе уже без каких-либо намеков предлагаю поконкретнее написать, где я ошибся в своих выкладках? а то какое-то пустословие получается с твоей стороны

то, что у меня нет опыта работы с SAN говорит лишь о том, что не приходилось иметь дела с SAN, соответственно кругозор в этой области Уже, и почти отсутствует, да
на SAN свет клином не сошелся и без него многие прекрасно себе живут
на том железе, которое доступно, с моей точки зрения я правильно понимаю как работает дисковая подсистема

Наверняка, сейчас как и обычно в лабораториях разрабатывают еще более новые дисковые подсистемы, возможно они отличаются концептуально как SAN и NAS, и можно любому админу сказать, что он в них не шарит, потому что он как минимум никогда с ними не сталкивался

Лично мне хватает iSCSI поверх ZVol и NFS поверх ZFS более чем, и именно в этой области, я представляю как оно работает