Тюнинг производительности ZFS

sync=disabled пока не рассматриваем

Лень много писать, в кратце:
Нет, ZIL на SSD не увеличит пропускную способность, поскольку это всё потом надо куда-то записать, но улучшит отклик и общее состояние системы при синхронной записи. ZIL вообще только при синхронной используется.
Да, L2ARC повысит скорость произвольного чтения.
Нет, не имеет смысла отдавать часть SSD под лог/кэш, оно и так там будет.
А вообще, тебе сюда, сюда и сюда.

А вообще, тебе сюда, сюда и сюда.

часть уже читал, теперь хотелось бы получить ответы на конкретные вопросы

Нет, ZIL на SSD не увеличит пропускную способность, поскольку это всё потом надо куда-то записать, но улучшит отклик и общее состояние системы при синхронной записи.

Имел ввиду кратковременную пропускную способность при всплесках активности random write, наверно, это и есть отклик?

даже на старых почти 10 летних винтах в RAID10 (2x2 zmirror) после добавления SSD типа Kingston KC300 вообще разницы не заметил

зато кратковременный sync=disable на другом сервере дает почти 100 кратное увеличение random write per second при дефргагментации блока данных внутри ZVol, софтина (DBMS) скорее всего непрерывно шлет тысячи fsync-ов в секунду

со 150 растет до 5-50K !

как то бы SSD приспособить под SLOG, чтобы такие же показатели получить даже при sync=standard

у кого-нибудь получалось? надо какие-нибудь сверхмодные серверные SSD?

впечатление, что даже если SLOG разместить на ZeusRAM все равно будет немногим лучше

кстати, интересно, если сервер рухнет при sync=disable, может ли при этом порушиться ZPool или старые снэпшоты, которые оказались на диске еще до sync=disable и до последней команды sync?

Имел ввиду кратковременную пропускную способность при всплесках активности random write, наверно, это и есть отклик?

Я неправильное слово употребил, я имел в виду latency. Кратковременные пики тоже может сглаживать.

даже на старых почти 10 летних винтах в RAID10 (2x2 zmirror) после добавления SSD типа Kingston KC300 вообще разницы не заметил
зато кратковременный sync=disable на другом сервере дает почти 100 кратное увеличение random write per second

На одинаковых задачах?

кстати, интересно, если сервер рухнет при sync=disable, может ли при этом порушиться ZPool или старые снэпшоты

Нет, потеряется только то, что накопилось в памяти с момента последнего сброса транзакций.

На одинаковых задачах?

разные задачи

на старом домашнем сервере виртуалка в частыми записями венды, разных SEO программ, пока без СУБД
при sync=disabled утилизация виртуального диска по вендо v8 монитору, который снаружи находится в zmirror падает с 70% почти до нуля

с линуксовыми мониторами iops пока еще не разбирался подробно, пробовал какие-то, но там как-то непонятно и разные значения в разных мониторах чему верить непонятно, поэтому пока забросил попытку
чем простым померять IOPS при рандомной записи тоже не знаю
на чтение много всяких програмулин
под венду какую-то находил, так она показала одинаковые значения около аж целых 3500 IOPS на рандомную запись внутри вендо виртуалок, одна из которых в пуле с SSD SLOG, другая без SLOG просто на винтах

в другом случае наблюдаю iops по db2top, там видно сколько физических записей в секунду, так вот при sync=disabled увеличивается аж в 100 раз при db2 reorg

Нет, потеряется только то, что накопилось в памяти с момента последнего сброса транзакций.

а на команду sync в командной строке датасет, у которого sync=disabled тоже никак не реагирует?

т.е. для сброса на диск надо сделать последовательность:

sync=standard;
# нужна ли здесь задержка?
sync;
sync=disabled;
?
по db2top заметил, что мгновенно срабатывает только sync=always,

а sync=standard почему то еще секунд десять соображает стоит ли прекратить высокие показатели IOPs, типа нафига они кайф обламали, так вот интересно, если сразу после
sync=standard;
без задержки отправить sync;
то сбросится ли буфер записи на диск из оперативки?

для ZFS наверно лучше добавлять только устройство целиком под определенную функцию (SLOG, L2ARC, и т.п.)?

exactly!

падает с 70% почти до нуля

а когда добавляешь ссд ничего подобного не происходит? странную петрушку ты описываешь.

а на команду sync в командной строке датасет, у которого sync=disabled тоже никак не реагирует?
т.е. для сброса на диск надо сделать последовательность:
sync=standard;
sync;
sync=disabled;

Возьми, да проверь :)

по db2top заметил, что мгновенно срабатывает только sync=always,

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

падает с 70% почти до нуля

а когда добавляешь ссд ничего подобного не происходит? странную петрушку ты описываешь.

на домашнем сервере при 70% утилизации виртуального диска внутри virtualbox (гость - венда v8) как раз в наружном пуле был подключен SSD в лог и кэш этого пула

помогает только sync=disabled для датасет диска C:


в другом случае для db2 просил маленькие по объему но быстрые серверные IBM-ские SSD в зеркало лога, а мне подсунули какое-то десктопное гуано - 500 гиговые Crucial MX, если их параллельно задействовать в другом пуле, то очень быстро растет их утилизация по dstat почти до 100 процентов

есть ли какие-нибудь аналоги IBM SSD в лог?
может, Intel, Samsung?
они должны быть типа SLC?

интересно, при наличии 3-х комплектов типа
контроллер LSI/IBM + 4 винта

как лучше выстроить быстрый пул?

нюансы: в одном из комплектов объем винтов сильно больше, чем в других комплектах

варианты:
1)
zmirror2+zmirror2 первого комплекта
zmirror2+zmirror2 второго комплекта

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

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

или

zmirror2+zmirror2 на полных больших винтах третьего комплекта? все в тот же первый пул?

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

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

то очень быстро растет их утилизация по dstat почти до 100 процентов

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

они должны быть типа SLC?

ищи write-biased или optimized и таки лучше slc.

как лучше выстроить быстрый пул?

сначала слепи из двух маленьких зеркал, потом добавь туда большое и выстави autoexpand=on, zfs заюзает сколько надо и при замене дисков на большие(после замены обоих дисков в зеркале) сама расширит пул.

то очень быстро растет их утилизация по dstat почти до 100 процентов

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

это домашний комп (почти сервер по предназначению)
на нем пока нет DBMS,
некоторые проги используют текстовые файлы аки списки
маразм конечно, но пока не до того, чтобы заменить участки кода на работу с DBMS

сначала слепи из двух маленьких зеркал, потом добавь туда большое и выстави autoexpand=on, zfs заюзает сколько надо и при замене дисков на большие(после замены обоих дисков в зеркале) сама расширит пул.

а это уже другой настоящий сервер под хранилище настоящей тяжелой СУБД смущает насколько эффективно будет работать пул с зеркалами разного размера
получается на большое зеркало запись будет происходить чаще, чем на маленькое? некоторые датасет могут попасть вообще только на большое после заполнения малых?
тогда запись будет происходить на скорости RAID1, а не RAID 10 и более ?
при наличии быстрого SLC SSD SLOG-а и большого хотя бы MLC SSD L2ARC, наверно, это несущественно?

некоторые проги используют текстовые файлы аки списки

возможно в этом собака и порылась.

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

нет.

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

нет.

если пул составлен из 2-х комплектов zmirror:

1) zmirror: 2 hdd по 150GB
2) zmirror: 2 hdd по 150GB

3) zmirror: 2 hdd по 2TB
4) zmirror: 2 hdd по 2TB

т.е. всего в пуле получается 4 зеркала - 2 пары разного размера

то как будет происходить распределение записи на них?

где это можно почитать?

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

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

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

this. я думал большие и маленькие это типа 600гб и 900гб, ну или 1тб и 2тб. с такими дисками, что в наличии, точно не стоит так делать. они ещё и разные поди - fc и sata?

ZFS тогда перебросит часть данных с малых на большие, чтобы немного освободить малые?

нет. два пула делай и не парься.