bonnie оцените результат.

Мне тут говорили что бичмарки не показатель..))) А ОС хоста какая? Я сам хочу подобное настроить, жду когда освободят железку...

Бенчмарки - очень даже показатель, в оценочном сравнении. Т.е. - берём одну железку. Запускаем тест. Берём другую - запускаем такой же тест. Усреднённая разница скажет о производительности железок. Во многих остальных смыслах - да, в целом бенчмарки не всегда могут показать адекватные результаты.

Моё ИМХО, конечно.

P.S. ОС хоста, debian 8

Ну, наверное это круто, но тестирование идёт поверх кучи разных слоёв и вообще на ФС. Если нужно как-то привязать результат к железу, я бы погонял fio на всех блочных устройствах по очереди

Бенчмарки - очень даже

dbench -s -D /tmp 100 & iostat -x 1

Спасибище! Забавный результат.

Сам kvm, работает в режиме: nocache. Т.е. DIRECT_IO на файловой системе.

Видимо отрабатывает lvmcache. И в моих SSD (Intel), хороший кеш. И сперва я проваливаюсь, видимо, в него 947.13 MB/sec.

Смотри:

~# dbench -s -D /tmp 100
dbench version 4.00 - Copyright Andrew Tridgell 1999-2004

Running for 600 seconds with load '/usr/share/dbench/client.txt' and minimum warmup 120 secs
99 of 100 processes prepared for launch   0 sec
100 of 100 processes prepared for launch   0 sec
releasing clients
 100       250   947.13 MB/sec  warmup   1 sec  latency 88.516 ms
 100       352   631.53 MB/sec  warmup   2 sec  latency 197.176 ms
 100       410   482.66 MB/sec  warmup   3 sec  latency 192.894 ms
 100       466   407.50 MB/sec  warmup   4 sec  latency 171.197 ms
 100       555   380.72 MB/sec  warmup   5 sec  latency 186.077 ms
 100       820   356.44 MB/sec  warmup   6 sec  latency 132.631 ms
 100      1086   329.26 MB/sec  warmup   7 sec  latency 145.681 ms
 100      1749   324.35 MB/sec  warmup   8 sec  latency 124.345 ms
 100      2947   363.64 MB/sec  warmup   9 sec  latency 131.915 ms
 100      3828   386.92 MB/sec  warmup  10 sec  latency 105.469 ms
 100      4617   381.61 MB/sec  warmup  11 sec  latency 145.609 ms
 100      5439   378.91 MB/sec  warmup  12 sec  latency 134.072 ms
 100      6329   387.44 MB/sec  warmup  13 sec  latency 105.085 ms
 100      7181   404.83 MB/sec  warmup  14 sec  latency 206.053 ms
 100      8217   408.90 MB/sec  warmup  15 sec  latency 222.189 ms
 100      9542   422.14 MB/sec  warmup  16 sec  latency 70.421 ms
 100     10419   432.72 MB/sec  warmup  17 sec  latency 70.215 ms
 100     11456   439.44 MB/sec  warmup  18 sec  latency 88.365 ms

Вывод iostat:

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0,00 26425,00    0,00 19547,00     0,00 443160,00    45,34     7,50    0,38    0,00    0,38   0,05  92,40

Теперь делаем так:

# dbench -s -D /tmp 2
dbench version 4.00 - Copyright Andrew Tridgell 1999-2004

Running for 600 seconds with load '/usr/share/dbench/client.txt' and minimum warmup 120 secs
0 of 2 processes prepared for launch   0 sec
2 of 2 processes prepared for launch   0 sec
releasing clients
   2      4481    81.76 MB/sec  warmup   1 sec  latency 141.679 ms
   2     20698   129.09 MB/sec  warmup   2 sec  latency 69.897 ms
   2     40183   155.55 MB/sec  warmup   3 sec  latency 116.246 ms
   2     64117   182.24 MB/sec  warmup   4 sec  latency 70.568 ms
   2     83977   187.07 MB/sec  warmup   5 sec  latency 92.839 ms
   2    112468   207.08 MB/sec  warmup   6 sec  latency 78.784 ms
   2    132482   208.99 MB/sec  warmup   7 sec  latency 135.871 ms
   2    155669   214.08 MB/sec  warmup   8 sec  latency 85.012 ms
   2    171179   208.88 MB/sec  warmup   9 sec  latency 167.859 ms
   2    194080   212.23 MB/sec  warmup  10 sec  latency 158.886 ms

Удивительное - рядом. lvmcache - бросает меня напрямую в HDD? Забавно.

Ну мне важна производительность бутерброда всего. Вот и не очень уверен, насколько это круто или нет. Проверил тестилкой на Windows, проверил производительность 1С. - Гилёв, по 30-35 попугаев отдаёт.

Но знаешь почему я заморочился производительностью в linux?

Вот что меня повергло в шок:

root@alfresco-dev1:~# hdparm -t /dev/vda

/dev/vda:
 Timing buffered disk reads: 4956 MB in  3.01 seconds = 1645.28 MB/sec
root@alfresco-dev1:~# hdparm -t /dev/vda

/dev/vda:
 Timing buffered disk reads: 1004 MB in  3.00 seconds = 334.65 MB/sec

А иногда, проваливается и до 80!!! Ну 1645.28 - может вычитывает из cache SSD накопителя (ибо kvm в nocache). Фиг знает, чего думать.

Так вы хотите на этом «бутерброде» 1С держать?

В частности - да. Конечно было бы не плохо, выкинуть оттуда: ext4+raw. Но... lvmcache, умеет кешировать только lvol, тогда придётся для каждой vm, городить свой lvmcache, что не гуд.

А как на счет zfs и zvol напрямую приатаченными к виртуалкам, не рассматривали или не доверяете zfsonlinux??

zfs kvm windows тормоза при записи (комментарий)

Уже увидел Ваш пост про zfs..))

Угу. В общем то сей пост всё ещё актуален. Смотрю в баг треккер zfs on linux - zvol, всё же пугает. Так, что пока остаюсь на lvmcache

lvmcache

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

какой режим кэширования и как настраивал кэш ? так

Example
       0. Create an origin LV we wish to cache
       # lvcreate -L 10G -n lv1 vg /dev/slow_devs

       1. Create a 2-way RAID1 cache data LV
       # lvcreate --type raid1 -m 1 -L 1G -n cache1 vg \
            /dev/fast1 /dev/fast2

       2. Create a 2-way RAID1 cache metadata LV
       # lvcreate --type raid1 -m 1 -L 8M -n cache1meta vg \
            /dev/fast1 /dev/fast2

       3. Create a cache pool LV combining cache data LV and cache metadata LV
       # lvconvert --type cache-pool --poolmetadata vg/cache1meta vg/cache1

       4. Create a cached LV by combining the cache pool LV and origin LV
       # lvconvert --type cache --cachepool vg/cache1 vg/lv1

или так

 Example
       0. Create an origin LV we wish to cache (yours may already exist)
       # lvcreate -L 10G -n lv1 vg /dev/slow

       1. Create a cache data LV
       # lvcreate -L 1G -n cache1 vg /dev/fast

       2. Create a cache metadata LV
       # lvcreate -L 8M -n cache1meta vg /dev/fast

       3. Create a cache pool LV
       # lvconvert --type cache-pool --poolmetadata vg/cache1meta vg/cache1

       4. Create a cache LV by combining the cache pool LV and origin LV,
          and use the writethrough cache mode.
       # lvconvert --type cache --cachepool vg/cache1 \
            --cachemode writethrough vg/lv1

1С держать?

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

я бы не рискнул, капризная штука 1с-ка, держу ее только на железных серверах и БД на аппаратных массивах сасах, любит она быстрые диски и оперу и процы с большой тактовой

Считаю данное утверждение, ни чем не обоснованным. Сейчас есть куча IaaS и даже SaaS провайдеров, которые дают 1С. Уже все давно опровергли миф о том, что 1С - только на железе может работать. Так или иначе, я уже год работаю на kvm+1C - всё работает. Но стоит оговориться, у меня нагрузки не большие.

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

какой режим кэширования и как настраивал кэш ?

smq политика, режим: writeback. Но надо учесть, что под writeback должны быть SSD с конденсатором (я уже сперва накупил SSD без оного, и выкинул потом их). При пропадании питания, cache «остынет» (насколько я понял), но всё же, всё что хранится в нём и не было записано на HDD, будет спокойно до записано.

Да, создавал cache, примерно так, как описано в мануале.

миф о том, что 1С - только на железе может работать.
куча IaaS и даже SaaS провайдеров, которые дают 1С

да не, это только для ИП-шек всяких, или для баз где движухи почти нет, у нас заявки волготорг, пятерочка кучей шлет по почте, а накладные на основе писем автоматом бьются, плюс операторы хреначат накладные, плюс бухи отчеты, перекачки, плюс полно любителей обороток по сто раз на дню запустить, юзеров сто в пике, да и плюс количество терминальных сессий не ограничено, да и база не одна, железо загибается, какие там виртуалки. Ну ставил я С-ку в линукс на виртуалку на постгрее, с вебмордой через nginx на побаловаться, а бухам дал толстого для тренировки, вощем скорости не впечатлили, совсем.

Считаю данное утверждение, ни чем не обоснованным.

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

винты хоть ssd ?

SSD с конденсатором

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

ssd сметесь шоль, только сас!

да не, это только для ИП-шек всяких, или для баз где движухи почти нет

В целом согласен. По всему остальному не могу ничего говорить, ибо не плавал. :)

Не ужели много ОЗУ + SSD, не позволяют работать 1С по человечески? Мне кажется, что если тот же MSSQL накормить приличном кол-вом ОЗУ (32гб+), и поставить SSD - уж 100-300 человек должно потянуть 1С. Да и, кстати, 1С, вроде умеет масштабирование же... MSSQL - думаю тоже можно отмасштабировать. Не уж то всё настолько плохо?

интересно а диск как-нибудь рапортует если его кондюк отойдет в мир иной?

Есть команды SMART для теста «капаситора». То есть тестить руками можно точно.

А если ssd с кэшем накроется с незавершенными транзакциями в БД

Будет неконсистент, никто ничего не гарантирует. По сему для кеширующих SSD, можно делать raid любого приемлемого уровня. В этом плане мне нравится zfs, которая очень бережно к ssd относится, и по-умолчанию в zil пишет только direct_sync данные.

10 лет с С-кой парюсь, гавеней софтины в мире наверное нет, она кстати и на ровном месте может упасть превратив БД в невосстановимый кусок Г., были случаи в практике, чудом из воды выходил сухим, но стресняк конкретный был.

То что 1С - УГ, спора нету. Но у меня обратные случаи были - падало железо. Резко. Внезапно. - 1С данные не теряла. Тьфу-тьфу... Но да, у меня нагрузка ни об чёмная.

Железо тоже заваливалось, рейд контроллер накрывался, диски умирали, но БД при этом выжили, а вот принудительный обрыв прогером_1с юзерской терминальной сессии превращал БД в тыкву

Еще был случай когда при свертке огромной БД она вошла в бесконечный цикл, вот жопа была тогда