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

наша паршивка по вашим просьбам заточена под тесты для хомяков @(всегда ваши, вендоры)

начинай с описания модели своих дисков.

Я бы не стал использовать zfsonlinux от слова «совсем».

Оно даже на Hipstere начинало непонятно вести себя при больших нагрузках.

Только Solaris, только Oracle.

Под базы данных ZFS нужно как-то тонко настраивать. King_Carlo может рассказать

zfs хороша тем, что прекрасно документирована, берём доку http://www.solarisinternals.com/wiki/index.php/ZFS_for_Databases
и не рушим себе мозг.
Но ТС не про это спрашивал.

Причем утилизация SSD по dstat от нескольких % до примерно 10%.

Какой размер пула, какой % пула занят, какого размера ssd, какой uptime?

Только Solaris, только Oracle

Это религиозный экстаз...

берём доку http://www.solarisinternals.com/wiki/index.php/ZFS_for_Databases

уже читал

Какой размер пула, какой % пула занят, какого размера ssd, какой uptime?

рассмотрим один пул:

zpool list
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
data 556G 367G 189G - 67% 65% 1.00x ONLINE -


планируется замена дисков на бОльшие

zpool status: http://pastebin.com/3uMxsMGT

начинай с описания модели своих дисков.

1) когда работает хорошо, конфиг такой:

зеркало SLOG: 2 x Intel3700 partition1: 10GB
L2ARC: те же самые 2xIntel3700 partition2: = 320GB total

2) если сделать:
L2ARC: те же самые 2xIntel3700 partition2: = 120GB total

А остаток те же самые 2xIntel3700 partition3 около 200GB добавить в другой пул в качестве зеркала данных

то работает значительно медленнее

причем в этом другом пуле еще и зеркало обычных относительно быстрых десктопных SSD, т.е. получается RAID 10

3) Планирую попробовать:

зеркало разделов 2xIntel3700 по 10 гиг ТОЛЬКО под SLOG, остаток пока пусть пропадает
пара десктопных SSD ТОЛЬКО под L2ARC

dstat показывает:

заполнение SLOG всего на 1-3 мегабайт в секунду

L2ARC объемом 320GB заполняется примерно за неделю

L2ARC объемом 120GB заполняется примерно за пару дней

Доступ СУБД к хранилищу организован примерно так:

DBMS->ext3->iscsi client (RedHat) -> iscsi lio target (Debian) -> zvol (8k blocks)->pool

До меня только сейчас дошло, что ты хочешь один ssd-mirror и под zil и под l2arc. Это не очень хорошая идея, оно действительно работает медленнее чем отдельные ssd под zil и l2arc.

С первым тезисом согласен на 100%

Со вторым - хипстер на то и хипстер :)

С третьим ты переборщил. Поделись своим открытием с joyent, omniti, netflix, integros, ixsystems, etc.

Плюс я сам наблюдал как в режиме 24/7 zfs переваривает 250000 iops на запись при дефолтных настройках (FreeBSD/OmniOS).

Дефрагментация приличная.

У тебя данных в пуле 367 гб и имеются 2 ssd по 500 гб, правильно? Вариант положить базы на ssd не вариант?

scsi-SAdaptec_V* прошивка на контроллере raid или it?

Жадность фраера погубит.

Тормозит, потому что конфликтующие режимы использования. Для slog важна низкая задержка, иначе ускорения не получится, и размеры блоков, которые slog пишет на SSD, небольшие - по умолчанию до 32K, но их может быть много и пишутся они часто. Пока пишутся только они - все хорошо. Места при этом используется немного, ибо блоки эти короткоживущие, живут там не более 3-х идущих подряд групп транзаций, зато IOPSы используются только в путь. При этом эти блоки читаются только в одном случае - при импорте пула и монтировании файловых систем и/или томов после нештатного завершения работы.

Тут жадного фраера начинает душить жаба - это как же, столько ж места пропадает, - и он нчаинает использовать тот же диск в качестве кэша второго уровня. У которого совершенно иной режим использование - запись большими блоками по 8M (или меньше, если в момент записи нужного количества блоков не нашлось), и случайные чтения блоков меньшего размера, но их тоже может быть много в зависимости от размеров памяти, ARC, политик кэширования и нагрузки на систему.

Вот отправил ты такой восьмимегабайтную запись, а теперь подумай, сколько времени понадобится чтобы ее через интерфейс для твоего SSD пропихнуть, и что в это время будут делать те операции записи, которые идут в slog... Курить нервно в сторонке они будут. Вот эта запись кончилась, и вроде бы можно начинать писать, а тут вдруг чтения из l2cache поперли, и хорошо если они IOPS'ы с записью пополам поделят, а могут ведь и в совершенно иной пропорции. А через секунду еще одна такая 8M запись может полететь в l2cache. И так далее, и тому подобное.

Короче, плохая это идея.

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

И вот тут-то slog'у становится совсем грустно.

столько ж места пропадает, - и он нчаинает использовать тот же диск в качестве кэша второго уровня. У которого совершенно иной режим использование - запись большими блоками по 8M (или меньше, если в момент записи нужного количества блоков не нашлось), и случайные чтения блоков меньшего размера, но их тоже может быть много в зависимости от размеров памяти, ARC, политик кэширования и нагрузки на систему.

в таком конфиге работало нормально и даже хорошо, намного лучше, чем после одновременного добавления другой партиции Intel SSD в другой пул

видимо Intel 3700 SSD легко справляется с такой «неэффективной» нагрузкой (SLOG + L2ARC но только одного пула), именно жадность в данном случае и мешает отказаться от такого способа использования

зачем отказываться если все хорошо?

но планирую попробовать Intel SDD только под SLOG, пусть остаток Intell SSD отдохнет

У тебя данных в пуле 367 гб и имеются 2 ssd по 500 гб, правильно? Вариант положить базы на ssd не вариант?

lsblk:
http://pastebin.com/wa3euBYS

sda-sdd - это HDD
sde,sdf - это десктопные относительно быстрые SSD
nvme* - это пара Intel3700

при таком раскладе (zpool status):
http://pastebin.com/DvnFgC97

пул data притормаживает
пул fast работает относительно нормально
оба пула нагружены базами данных

Планирую улучшить положение использованием:
nvme* только под SLOG пула data
sde,sdf только под L2ARC пула data
соответственно пула fast не станет

scsi-SAdaptec_V* прошивка на контроллере raid или it?

Прошивка дефолтная RAID, HDD настроены четырьмя массивами из одного диска каждый «массив», диски были быстрые 15K RPM, один помер, пришлось заменить на SAS Constilation большего объема и с меньшим RPM, но по dstat все же его утилизация редко поднимается до 100%, хоть для него и неправильный дефолтный ashift

тормоза проявляются именно когда nve* SSD используется одновременно и под SLOG,L2ARC пула data и под одно из зеркал данных другого пула fast, в пуле fast тоже наблюдается незначительное снижение производительности, при этом утилизация nve* не поднимается выше 10%

И вот тут-то slog'у становится совсем грустно.

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

утилизация Intel 3700 SSD при такой грусти SLOG-а колышется между 5 и 10 процентами

use dtrace, luke!

Чёрт, совсем забыл, в ляликсе его до сих пор путем нету.

в ляликсе

:)

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

потому что херовые ссд?

Потому-что для ssd есть ext4, а zfs вендовненько и ненужно.

потому что херовые ссд?

аха Intel 3700 херовей некуда

Потому-что для ssd есть ext4, а zfs вендовненько и ненужно.

насколько надо быть упоротым, чтобы сравнивать ZFS с ExtX?

мне ведь кроме FS еще и снэпшоты нужны и многое другое, что есть только в ZFS

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

это все равно, что Oracle сравнивать с базами в текстовых файлах, и утверждать, что txt файлы объемом 1к через ODBC работают намного быстрее, чем Oracle, у которого даже пустая база занимает столько то сотен метров ..

Вот поэтому zfs и ненужен. В печь комбайны.
Вообще, снапшоты не нужны, но если очень сильно хочется, то есть lvm2.

Вот поэтому zfs и ненужен. В печь комбайны.

да и Sun с Oracle не нужны (корпорации в целом)

Вообще, снапшоты не нужны

а я и не знал, большое спасибо, что просветили

но если очень сильно хочется, то есть lvm2.

LVM может создавать массивы с избыточностью?
копировать снэпшот с одного LVM на второе резервное хранилище по сетке, чтобы одновременно при копировании! на обоих хранилищах работали базы?
сжимать и дедуплицировать данные?
каким местом LVM улучшает random iops?

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

Ну можешь, конечно, системтапом потачать, может чего и натапаешь. Хотя, дай угадаю - тебе за это тоже не доплачивают?

Что ты прямо бисер мечешь, как ребёнок, честное слово

Если тебя устраивает то, как ридзилла и логзилла сосуществуют (слово-то какое) на одном диске, то можешь рассмотреть вариант отказаться от избыточности для логзиллы и отдать по одному распиленному в желаемой пропорции диску в каждый пул.

Не забудьдобавить ZFS в свой список «Ненужно», недоадмин локалхоста.

Вообще, снапшоты не нужны

Не нужны клоуны, которые со своим локалхостным мнением лезут куда их не просят.

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

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

еще интересно по продлению срока жизни Intel SSD, тех, что будут в SLOG-е

как у них происходит remap неисправных ячеек или что-то подобное?

имеет ли смысл время от времени сдвигать рабочую партицию 10Gb на новое место при общем объеме около 400Gb?

Зачем? 2016 на дворе. Нет, если очень хочется геморроя, то хозяин барин.

Зачем? 2016 на дворе. Нет, если очень хочется геморроя, то хозяин барин.

т.е. SSD сама будет ремапить все проблемные блоки

использование всего лишь пары процентов от всего объема SSD вместо 100% увеличит срок жизни SSD пропорционально, т.е. в 10-ки раз при прочих равных условиях?

использование всего лишь пары процентов от всего объема SSD вместо 100% увеличит срок жизни SSD пропорционально, т.е. в 10-ки раз при прочих равных условиях?

Нет. Они рассчитаны на определенный объем записи, после того, как записано больше этого объема, никто ничего не гарантирует. Важно не сколько от линейного размера диска ты используешь, а как много ты на наего пишешь.

Ну и наворотил ты :)

Зачем пулу на ssd сделал slog?! Да ещё на тех же дисках!

sda на 2 тб с размером сектора 4к, остальные - 512b?

zfs нормально работает когда имеет direct access к диску, без умных raid контроллеров с nv-cache и on disk cache, т.е. best choice это LSI HBA, на крайняк onboard Intel sata in ahci mode. На adaptec-ах бывают глюки даже с IT прошивкой, редко но бывают. Посему, если планируешь остаться на hdd - меняй контроллер или перепрошей.

ПС: скажи какой у тебя объём всех баз на этих пулах и размер оперативки кстати сколько. ППС: zd0 это что за девайс?

Зачем пулу на ssd сделал slog?! Да ещё на тех же дисках!

ну так Intel то производительнее же

sda на 2 тб с размером сектора 4к, остальные - 512b?

ессно, я рожу новый диск при выходе из строя старого? все равно скоро все поменяю на 2T 4k

zfs нормально работает когда имеет direct access к диску, без умных raid контроллеров с nv-cache и on disk cache

да знаю, поэтому кэш записи отключен по понятным причинам

, т.е. best choice это LSI HBA

на другом хранилище именно такой HBA и установлен

, на крайняк onboard Intel sata in ahci mode.

диски то SAS

На adaptec-ах бывают глюки даже с IT прошивкой, редко но бывают. Посему, если планируешь остаться на hdd - меняй контроллер или перепрошей.

а что за IT мод прошивки?

ну так Intel то производительнее же

Если пул на ssd - slog не нужен. Samsung 850 EVO на 50% быстрее твоего s3700.

ессно, я рожу новый диск при выходе из строя старого? все равно скоро все поменяю на 2T 4k

Не ессно, есть диски и с 512b сектором. А так тебе придётся пул пересоздавать.

диски то SAS

Ну я же и написал - накрайняк :).

а что за IT мод прошивки?

IT - Initator-Target. Но у адаптека их нет, и щас почитал что Pass-Through там фейковый. Что и видно по наименованию девайса в пуле. Сорри, думал если есть у lsi, то есть и у adaptec.

Сколько оперативки то на серваке?

Если пул на ssd - slog не нужен.

наверно, это зависит от моделей SSD?

Samsung 850 EVO на 50% быстрее твоего s3700.

а причем тут Samsung 850 EVO? у меня нет такой модели
дело не только в скорости (скорости чего? последовательного чтения фильма про стритрейсеров?), но еще и в:
1) надежности сохранения данных в случае внезапного выключения
2) latency
3) Random IOPS для нагрузки типичной для СУБД

Не ессно, есть диски и с 512b сектором. А так тебе придётся пул пересоздавать.

где есть? у меня они есть? у меня они НЕ есть

Сколько оперативки то на серваке?

16Gb ECC

16Gb ECC

Если б не ECC, подумал бы что у тебя сервер на ноутбуке...

Если б не ECC, подумал бы что у тебя сервер на ноутбуке...

так это только под хранилище, разве недостаточно?

или надо обязательно попонтоваться своим (anonymous) сервером с оперативой в несколько сотен гиг? профит от ЧСВ? ветка то открыта не для этого вообще-то

так это только под хранилище, разве недостаточно?

Смотря для какой нагрузки. Ну и память-то лишней не бывает. А по нынешним временам 16 уже и на ноуте не самый большой возможный объем.

или надо обязательно попонтоваться своим (anonymous) сервером с оперативой в несколько сотен гиг? профит от ЧСВ?

Эк у тебя бомбануло-то :)

ветка то открыта не для этого вообще-то

Если что, я в этой ветке поболе иных регистрантов поучаствовал. Так что ты уж научись себя в руках держать, ок?

Смотря для какой нагрузки. Ну и память-то лишней не бывает. А по нынешним временам 16 уже и на ноуте не самый большой возможный объем.

из того, что есть на работе

наверно, это зависит от моделей SSD?

Ну, если бы ты под slog заюзал ZeusRAM, на выделенном канале, то профит бы был, а в твоей конфигурации скорее наоборот. Т.к. пул и лог на одном канале.

а причем тут Samsung 850 EVO?

Как пример десктопного ssd, по тестам никса быстрее интеля по иопсам как раз. Надежность хранения обеспечивается транзакциями фс, для этого их и придумали. Latency and iops имеют обратно пропорциональную зависимость, с чего то ты их разделил.

16Gb ECC

Ещё некоторое время назад, я бы сказал что использовать l2arc при таком объёме ram ССЗБ. Т.к. l2arc съедал 250 байт ram на каждую запись, т.е. твои 120 gb/8kb*250b=3,7gb, щас вроде как уменьшили до 170, а в оракловой ветке до 80. Но оракл не делится кодом.

Далее, в линуксе ARC конфликтует с другими кэшами по очевидной причине - хреновая интеграция.

Ладно, дабы не начинать холивар, причины твоей проблемы (по нисходящей):

Очень высокая, для hdd, фрагментация пула.

Выбор платформы.

Сомнительная польза от l2arc, в случае если объём горячих данных твоих баз влазит или чуть чуть больше размера arc, а это 80% ram by default.

Ну, если бы ты под slog заюзал ZeusRAM, на выделенном канале, то профит бы был, а в твоей конфигурации скорее наоборот. Т.к. пул и лог на одном канале.

в организации, где я работаю, таких денег не выделяют под эту задачу

да и потом с правильным SSD спокойнее как то, сколько времени ZeusRAM сохраняет данные без питания? мне собственный спокойный сон дороже, чем эксперименды с новомодними кэшами
Еще под SLOG некоторые рекомендуют Samsung 850 PRO, но уж никак не EVO а Intel 3700 проверено электроникой и сотнями админов

Как пример десктопного ssd, по тестам никса быстрее интеля по иопсам как раз. Надежность хранения обеспечивается транзакциями фс, для этого их и придумали. Latency and iops имеют обратно пропорциональную зависимость, с чего то ты их разделил.

Intel выбирался в первую очередь под SLOG, т.е. с расчетом на то, что он будет хорошо переживать выдергивание кабеля из БП сервера, хотя конечно никто этого делать специально не планирует (по крайне мере я надеюсь на это), погугли чем Enterprise SSD более лучше чем Desktop SSD? в крадцэ: 1) кондюры для успевания сохраняния 2) бОльшее количество гарантированных IOP(не_s) до ее выкидывания на помойку

Ещё некоторое время назад, я бы сказал что использовать l2arc при таком объёме ram ССЗБ. Т.к. l2arc съедал 250 байт ram на каждую запись, т.е. твои 120 gb/8kb*250b=3,7gb, щас вроде как уменьшили до 170, а в оракловой ветке до 80. Но оракл не делится кодом.

при физическом объеме раздела L2ARC равном 120GB, логический размер L2ARC за счет сжатия получается порядка 200GB с «копейками» и при этом таблица хидеров отъедает чуть более 2 гиг оперативки, т.е. еще можно наращивать объем L2ARC

Далее, в линуксе ARC конфликтует с другими кэшами по очевидной причине - хреновая интеграция.

можно долго рассуждать на тему достоинств и недостатков Linux по сравнению с тем или иным решением,
НО, что ОЧЕНЬ ВАЖНО:
1) Мне неинтересно что-либо закрытое, что я не смог бы применять в своих проектах
2) Мне накуй НЕ НАДО ТРАТИТЬ ВРЕМЯ НА ИЗУЧЕНИЕ чего-либо отнимающего много времени типа солярки, если это ЗНАЧИТЕЛЬНО не улучшит мое материальное положение в разы или десятки раз

Очень высокая, для hdd, фрагментация пула.

да причем же тут фрагментация то? если щас нормально стало работать при такой же фрагментации, стоило убрать Intel из второго пула

Сомнительная польза от l2arc, в случае если объём горячих данных твоих баз влазит или чуть чуть больше размера arc, а это 80% ram by default.

скорее не влазит, чем влазит, потому что L2ARC очень быстро заполняется даже случайными чтениями (есть еще опция записывать туда все чтения), т.е. фрагментация HDD конечно имеет место быть, но L2ARC собственно для того и существует, чтобы уменьшить отрицательные эффект фрагментации HDD до минимума

скорее бы уже в ZOL сделали persistent L2ARC как в Oracle