зеркало ssd для ZIL и незеркало на техже ssd для L2ARC,

На эти деньги купи RAM, будет больше пользы

Я под ZIL отдал старый SSD Intel X25-M G2 80 Gb, который иопсами и скоростью записи то и сам по себе не блистал, а у меня еще в виде vmdk используется. В итоге получил около 30 мбайт/c. Предел данного диска в чистом виде около 80.

В итоге получил около 30 мбайт/c.

это запись? а без ZIL скока было?

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

Что касается L2ARC, советую не обращаться к теме, пока не закончатся слоты памяти :)

У меня NFS с синхронной записью на raidz пулах, поэтому было около 5.

O_O

Скинь более детальную инфу, если не трудно

Я вкуривал в тему, и насколько мне удалось понять: ZiL штука весьма спорная. Даст выгоды, или не даст... Всё зависит от.

L2ARC - штука в целом толковая, если ты больше пишешь, чем читаешь. А так, в целом - у меня к примеру, есть два НЖМД, объеденив их в RAID, и подключив L2ARC, запустил виртуальную машинку с win, получил такое: http://storage4.static.itmages.com/i/15/0714/h_1436890995_3054070_9b18ded7f5.png

В общем и целом, чем больше абстракций, тем тормознее. :) RAID1 тормознее просто одного диска, RAID1 с L2ARC - тормознее на запись ещё. И т.д.

NAS на базе esxi, система на ssd, винты прокинул через vt-d и на них сделал пулы. Основной датастор для виртуалок на одном из пулов, через nfs с sync, да и некоторые рабочие файлы на сетевые ресурсы ссыкатно без защиты писать. Без ZIL было 5 мб/c на запись, решил с системного ssd выдать виртуальные диски по 4 гб, виртуальный контроллер LSI SAS дает оверхед по 4к-иопсам по разным данным (из чужих тестов) от 30 до 200%. Ну у меня вроде так и вышло, скорость записи самого диска не измерял, но даже большими блоками она не более 80 мб/с, запись по nfs меньше в 2 раза, меня устраивает.

ZIL на ssd имеет смысл только при синхронной записи. l2arc помогает при большом кол-ве чтения, но тут надо смотреть статистику arc по cache hit/miss и думать.

Вроде всё как у людей. До сих пор не верю, что NFS так любит проводить время в ожидании синка :)

Вот кстати, в каких отношениях arc с обычным линуксовым кешем чтения?

Ну во-1х, у меня древний ssd. Во-2х, у меня слой виртуализации, дающий оверхед, пробросить ssd не могу, т.к. нет свободного контроллера. И в 3х nfs работает с блоками 8к, тут еще сетевая производительность примешивается, т.к. мелкими блоками даже на usb-диске скорость сильно упадет, а для больших сетевых блоков нужно ATAoE/iSCSI+zvol, на что у меня нет ни желания, ни времени, ни подходящего бубна.

Есть мнение, что если всё по-дефолту - то одно, дублирует другое. :(

ZiL штука весьма спорная. Даст выгоды, или не даст... Всё зависит от.

ZIL штука нифига не спорная. Без него него производительность приложений, требующих синхронной записи, была бы унылой. Отключением его можно получить более высокие результаты для таковых, но ценой отсутствия гарантий по целостности данных соответствующего приложения. Впрочем, в этом вашем ляликсе это никого никогда не останавливало. ZIL задействуется всегда для синхронных операций, даже если никакого отдельного устройства для него нет - в этом случае блоки выделяются непосредственно из пула. Задействование отдельного устройства (устройств) с малым временем записи оказывает заметный эффект на производительность приложений, требующих синхронной записи. Возможность достичь максимального эффекта определяется не только ZIL'ом, так как данные, синхронно записанные в него, требуется рано или поздно сохранить и в основном пуле, так что производительность основного пула тоже играет роль. Есть и еще разные другие факторы.

L2ARC - штука в целом толковая, если ты больше пишешь, чем читаешь.

Не подскажешь, где такую забористую траву дают?

Не подскажешь, где такую забористую траву дают?

Ух йопрст... Наобарот, конечно. :) Вестимо всё наобарот. Спасибо!

Возможность достичь максимального эффекта определяется не только ZIL'ом, так как данные, синхронно записанные в него, требуется рано или поздно сохранить и в основном пуле, так что производительность основного пула тоже играет роль. Есть и еще разные другие факторы.

Золотые слова!

производительность приложений, требующих синхронной записи

Приведи пример таких приложений? СУБД?

Насколько мне известно, ни в каких, они сами по себе.

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

И от этого, очень, очень больно и уныло. Особенно, когда возникает очень стойкое ощущение, что ARC не спешит возвращать обратно память в систему...

Насколько мне известно, ни в каких, они сами по себе.

Ну отсюда вопрос - как на них делить память :)

возникает очень стойкое ощущение, что ARC не спешит возвращать обратно память в систему...

Так он и не должен. Сколько ему разрешили, столько он и выедает.

Может я и правда обкурился, но вроде как должен же? ARC - прописан «от» и «до». И если в системе мало памяти, должен обратно возвращать в систему, до состояния «от».

Пруфов нету под рукой, но что-то подобное читал.

Приведи пример таких приложений? СУБД?

iSCSI имеет встроенный механизм синхронной записи, который вроде даже нельзя отключить, но он быстрее синхронной записи через nfs. Ну и СУБД, да.

как на них делить память

Так она же сама делится. Кеш чтения 1го уровня это RAM, он же системный кеш. Кеш чтения 2го уровня это L2ARC, в него вытесняется содержимое 1го уровня, начиная с самых старых блоков.

Среди случаев практического использования могу вспомнить одного чувака с гигабитным интернетом, который хотел раздавать торренты. Так вот, у него скорость была нормальная только на 1-3 раздачах, больше она жостко резалась еще на уровне случайного чтения с пула на hdd, он воткнул ssd под L2ARC, через некоторое время торренты закешировались и он получил гигабит на 30+ одновременных активных раздачах.

ARC не спешит возвращать обратно память в систему

ARC это кеш чтения 1го уровня zfs, L2ARC это кеш чтения 2-го уровня. Они оба не возвращают ничего, а только освобождают самые старые блоки новыми. И не надо ничего возвращать, если zfs захочет прочитать блок с пула, он сначала смотрит его в ARC, потом в L2ARC и уже потом читает с пулы, одновременно записывая в ARC. Когда тот переполняется, блок вытесняется в L2ARC (а может и сразу копируется в оба кеша, точно не скажу). Но если потребуется закешировать новый блок ARC/L2ARC или система/программа потребует памяти под свои нужды, кеш сразу освободит память.

Читаем внимательнее, вопрос был про arc и ядрёный кэш в линуксе.

Ну это уж вы сами как-нибудь, в моём царстве таких проблем нет, если это не mmap, конечно :)
zfs_arc_min и zfs_arc_max в помощь.

а только освобождают самые старые блоки новыми.

ARC ведёт два списка(вернее 4) - recently used и frequently used и истории вытеснений по обоим спискам.

Но если потребуется закешировать новый блок ARC/L2ARC или система/программа потребует памяти под свои нужды, кеш сразу освободит память.

Какая система? Какая программа? Операционная система похоже что ничего не получает из ARC, а тупо начинает в swap уходить.

Так вот, вопрос в том, может-ли переходить память из arc, обратно в ОС, в пределах, установленных с zfs_arc_max в zfs_arc_min?

zfs_arc_min и zfs_arc_max в помощь.

Рычажки-то есть. У меня нет понимания, кому в каких случаях память нужнее.

NAS на базе esxi, система на ssd, винты прокинул через vt-d

Неправильно делаешь ты.

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

то прокидывать в виртуалку надо весь контроллер, а не отдельные винты

Так и сделано. Просто сократил повествование.

чуть доплатить денег и поставить отдельный сервер

Не выйдет «чуть доплатить», т.к. два сервера это две серверных мамки, два серверных проца, два вагона ECC памяти и т.п. По сути NAS совместил с тестовой лабораторией.

vfs.zfs.arc_max 	5568M
vfs.zfs.arc_min 	768M
vfs.zfs.prefetch_disable 	0
vm.kmem_size 	7424M

на фре настройки zfs такие для 8 Гб, свап отключен, все работает хорошо

Ну то есть выходит, что таки zfs отдаёт в систему, память обратно, если система начинает уходить в swap?

Ну и вообще говоря: unix != linux, боюсь, что в этих системах реализация zfs, очень сильно различная.

Да не доходит до свапа вообще. Свободной памяти валом, ARC сверху ограничен.

Не, ну если сервер не выполняет ничего такого, то тогда, да. В общем я уменьшил ARC до 256 мб. поотключал все кеши, и прочее - на серверах с KVM виртуализацией. Пока полёт нормальный. Но в swap всё равно хожу.

Не выйдет «чуть доплатить», т.к. два сервера это две серверных мамки, два серверных проца, два вагона ECC памяти и т.п. По сути NAS совместил с тестовой лабораторией.

Что-то я не пойму. Два сервера, две мамки, два серверных проца, два вагона ECC памяти, два портсигара отеч^W^W^W, а дисковая подсистема - 2 десктопных SATA + SSD под кэш?

Ааа, ты же не топикстартер :)

Я фиг его знает, как оно в линуксах точно. Возьми systemtap, да посмотри, как оно там :)

Странное решение. Память и соответственно ARC нужен как раз для быстрой работы zfs. У меня около 50 Тб места, несколько пулов и я хочу чтобы все это работало быстро, поэтому отдал память именно под ARC, оставив системе небольшой резерв. А уже если рамы мало, а скорость чтения важна, особенно рандом, тогда и можно думать про L2ARC. Но одно другим заменить не выйдет. Если так мало рамы, выгоднее вообще отказаться от zfs.

При виртуализации ARC выступает уже третьим кешем... 1) кеш внутри самой виртулаки 2) на уровне хост ОС 3) ARC. - Ни к чему дублировать.

Я понимаю еще дублирование кешей для десктопных VMM, но bare metal гипервизоры намного гибче рулят памятью. Вот я отдал 8 гб виртуальному NASу монопольно, всего это 8192 мб, эта память нигде больше не используется. Системе я отдаю 7424 мб (-256 видеопамять, -512 виртуальный диск в памяти). У меня нет иных ФС, а ОС находится на рам диске, так что единственный кеш в системе это ARC и я задал минимум и максимум для него. Prefetch осуществляет предвыборку непосредственно в процессе чтения с диска, запрашивая и помещая в ARC. Старые блоки просто удаляются, т.к. нет L2ARC. Таким образом ARC является основным и в моем случае единственным кешем.

Ок, ситуации различные бывают. Я не использую baremetal. В Вашем случае, это видимо ESXi?

Да, я выше писал про esxi, потому и удивился.

но bare metal гипервизоры намного гибче рулят памятью

bare metal = buzzword, а тут технари собрались. KSM выключи, KVM память тоже монопольно будет использовать.