On 21.11.2014 13:07, Владимир Друзенко wrote:
21.11.2014 01:59, Volodymyr Kostyrko пишет:
On 20.11.2014 18:20, Владимир Друзенко wrote:
20.11.2014 19:09, Владимир Друзенко пишет:
05.11.2014 17:49, Volodymyr Kostyrko пишет:
On 05.11.2014 14:15, Vladislav V. Prodan wrote:
Зоопарк. Из FreeBSD все не ниже 9.0 (может конечно 1-2 8.2
осталась, но
уже без нагрузки). Но не в этом суть.
Не так давно в рассылке пробегала "категорическая
рекомендация" не
использовать один физический диск в нескольких различных
пулах, со
ссылкой на планирование IO в ZFS. А тут на одной ZFS куча
других
ZFS. Да
и памяти на столько кэшей ненапастисть.
zfs create -o primarycache=metadata -o sync=disabled -o
logbias=throughput -o volmode=dev -o volsize=?
Это где вы советуете делать? на хосте или на госте?
На хосте. primarycache=metadata позволяет кешировать данные о
fs/volume но не его содержимое. sync=disabled отключает
принудительный сброс данных на диск (возможно с этим я и перегнул
палку, наверно лишнее ибо небезопасно). logbias=throughput отключает
при записи использование логов, т.е. все данные пишутся сразу на
диск. Это ещё базам данных хорошо помогает.
А что делать с памятью? Это же не поможет её сэкономить.
И да, "-o volmode=dev -o volsize=?" - это же не файловая система, а
блочное устройство. Как потом быстро и просто её перенести на другой
сервер или даже на ноут на другой программной платформе (другая ОС)?
dd
К тому же VirtualBox умеет использовать блочные устройства только по
iSCSI. Есть конечно bhyve, но он пока не умеет BIOS и VGA.
VBoxManage internalcommands createrawvmdk - и жуёт на ура.
Очень много лишних телодвижений... Вот как скачать виртуалку на ноут в
локалке с произвольной операционкой?
zfs send | zfs receive
NFS, samba и scp/sftp в твоём случае не помогут без предварительного dd.
Ещё неплохо бы вспомнить "тонкие диски" - на сколько я понимаю после
такого dd диск будет "толстый". А значит надо будет качать лишние
гигабайты ноликов, которые будут занимать место на винте ноута - зачем
такое?
Они всё равно при передаче по сети жмутся а при хранении на диске -
подразумеваются. Фактически получается sparse файл.
В среднем у меня на виртуалку приходится 3 диска - вместо одной команды
zfs create надо делать 3.
А как в одну команду перенести все диски виртуалки на другой, более
медленный или более быстрый носитель на том же сервере, или просто
сделать копию (cp и mv уже не подойдут)?
Обычно не держу больше одного пула на сервере. Всегда лучше построить
zraid чем мерять на каких дисках быстрее,
Я вижу, что твой вариант костылей существенно более костыльный, чем мой,
и всё это только ради ZFS в виртуалке. А оно надо? :-P
Не совсем, я виртуалки никуда не раздаю, они мне в основном нужны для
тестирования. Ну там поднять OpenFire поверх постгресса
среплицированного bucardo на нескольки линуксах. Поэтому я посылаю на
фиг многие вещи чтобы получить прирост производительности, пусть и
небольшой. У нас просто цели разные.
Я создаю для каждой виртуалки отдельную фс, и диски виртуалки лежат там
как файлы.
могу тогда ещё рекомендовать recordsize=8k
Зачем так мало? Использую дефолтные 128K на хосте.
Потому что в виртуалке файлы пишутся кусками в 4k а на хосте по правилам
Copy-On-Write перезаписывается весь сектор в 128k. Та же проблема и с
базами данных: https://wiki.freebsd.org/ZFSTuningGuide
http://open-zfs.org/wiki/Performance_tuning
Ещё есть qemu и может он и умеет блочные устройства, но не думаю что
имеет смысл на него мигрировать.
мечтаю когда bhyve c qemu замутят.
А зачем qemu ожидать, когда есть bhyve - его ожидать куда интереснее (и
перспективнее). :-D
В qemu мне нравится возможность активно играться с девайсами и их
количество, помню сел в раскоряку, здесь флешки нету, есть флешка в
датацентре, но это 500км. Есть софт, который ляпает на флешку самотык
для обновления фирмвари, но только на флешку и никак иначе. Создал
виртуальный диск, подбросил в qemu как флешку - и на ура.
Раньше в qemu был qemu-kmod который позволял выполнять уже
оттранслированый код на уровне ядра с куда большей производительностью.
Потом товарищ Морис его выкинул и начал использовать линуксовый kvm,
который по большому счёту то же самое что и bhyve - системный
минимальный набор для виртуализации. Насколько я понимаю bhyve более
самодостаточен, но от использования его как бекенда для исполнения
виртуалок с qemu в виде фронтенда для трансляции и работы с виртуальными
девайсами я бы не отказался. Незнаю насколько это реально, скорее мечта...
P.S. Ещё вопрос - зачем по 2 идентичных письма отсылать? Есть кнопочка
"ответить в рассылку". Если вдруг у вас какой-то чудной почтовый клиент,
и у него нет такой кнопочки, то можно после нажатия на "ответить всем"
удалить из копии все адреса кроме рассылки.
ок, учту.
--
Sphinx of black quartz judge my vow.
