Вопросы по эксплуатации lvm cache

Это уже в целом, похоже на SSD. Но нужно тестить на локальном диске, а не на samba.

Так в том то и дело что это нифига не ссд.. это все крутится в одном хосте - 2 виртуалки рядом... обе в кков2, то что они по сети связаны - это ж ничего не значит.. понятно, что там есть какието потери на протоколах.. но это не принципиально.. а крутится все это на одном 1тб сигейт 7200... что за чудо?

что за чудо?

Какие то кеши значит все же вступают в силу. Разбирайся с кешами ОЗУ.

Хорошо и качественно поболел... заодно почитал кучу всяких манов... и к чему пришел... узкое место у меня выходит SATA II :( тупо поднял рейд0 на мдадме и получил скорость записи в массив из 2х дисков равной 280-290 мб/сек... а тот же hdparm -Tt говорит на ссд теже 280мб/сек выходит не будет мне счастья от ссд кеширования в софтрейдовых системах без использования сата3 контроллера?

Не скажи, IOPSы будут огромными по сравнению с RAIDами. У себя на десктопе на SATA II после замены WD Black на SSD Kingston заметил значительную прибавку к скорости работы системы вцелом. Если на последовательной записи будет слабо заметно, то на случайной записи будет заметный выигрыш. А с SATA III будет ещё лучше.

Скорости SATA II , в 99 случаях из 100, вполне хватит. Последовательно читать и писать на серверах как правило - не нужно.

Уже это понял... ))) Собрал на тестовой машинке на мдадме рейд0 из 3х старых пятисоток, засунул его в лвм, туда же прицепил кусочек ССД на 50gb, на котором в этом же лвме развернул кеш. Гонял одну и ту же виртуалку на тестовой и рабочей машинках... Результаты - интересные. Позже сегодня выложу табличку.

Одинаковые параметры хостовых машин:
X8-DTTF, dual xeon e5645 (2.4ghz) 24GB Ram, 2х1GB lan, ssd ocz vertex-III, 60Gb, hdd 2*1TB st1000dm001

На обоих машинах:
Kernel Version - Linux 4.4.44-1-pve #1 SMP PVE 4.4.44-84
PVE Manager Version - pve-manager/4.4-13/7ea56165

Различия:
на машине 1 - сторедж (место где лежит qcow2 с виртуалкой) установлена на просто подмапленом одном из винтов
на машине 2 - сторедж (место где лежит qcow2 с виртуалкой) установлена на LVM разделе с ССД кешированием
(32Мб МЕта/32ГБ - кєш), который установлен, в свою очередь на софт рейд собраный при помощи МДАДМ.

На обоих хостах стоит один и тот же снапшот рабочей машины под управлением Win2k8R2, 4ядра, 4 Гига опеативки,
100 Гиг системный раздел. (естественно виртуальные жесткий диск, контроллеры и сеть - VIRTIO)
Виртуалки смонтированы с параметрами диска: cache=unsafe, iothread=1

Что получил после тестов CrystalDiskMark 5.2.1 x64
Test : 1024 MiB [C: 34.3% (34.3/99.9 GiB)] (x5) [Interval=5 sec]

Машина 1

   Sequential Read (Q= 32,T= 1) :  7710.650 MB/s
  Sequential Write (Q= 32,T= 1) :  1356.462 MB/s
  Random Read 4KiB (Q= 32,T= 1) :   507.335 MB/s [123861.1 IOPS]
 Random Write 4KiB (Q= 32,T= 1) :   191.506 MB/s [ 46754.4 IOPS]
         Sequential Read (T= 1) :  1521.551 MB/s
        Sequential Write (T= 1) :   334.707 MB/s
   Random Read 4KiB (Q= 1,T= 1) :    38.688 MB/s [  9445.3 IOPS]
  Random Write 4KiB (Q= 1,T= 1) :    24.509 MB/s [  5983.6 IOPS]

Машина 2

   Sequential Read (Q= 32,T= 1) :  7814.214 MB/s
  Sequential Write (Q= 32,T= 1) :  2497.474 MB/s
  Random Read 4KiB (Q= 32,T= 1) :   540.108 MB/s [131862.3 IOPS]
 Random Write 4KiB (Q= 32,T= 1) :   221.086 MB/s [ 53976.1 IOPS]
         Sequential Read (T= 1) :  1516.938 MB/s
        Sequential Write (T= 1) :  1414.121 MB/s
   Random Read 4KiB (Q= 1,T= 1) :    33.230 MB/s [  8112.8 IOPS]
  Random Write 4KiB (Q= 1,T= 1) :    25.400 MB/s [  6201.2 IOPS]

Виртуалки смонтированы с параметрами диска: cache=unsafe

Зачем? При таком параметре, если мне память не изменяет, у тебя kvm говорит, что я все записал, после того как у тебя данные попали в ОЗУ сервера, но никак не на диски. По этому и называется unsafe. Быстро, но не надёжно. Меняй параметр этот и перетестируй. Прочитай разницу этих параметров. Посмотри как создаёт proxmox Win машинку по-умолчанию. Поставь virtio - больше не трогай ничего.

iothread=1

Даже не знаю что это такое, но я бы убрал на значение по-умолчанию.

Исправил параметры диска: cache=writeback, iothread=1

Машина 1 (голый HDD)

   Sequential Read (Q= 32,T= 1) :  7231.524 MB/s
  Sequential Write (Q= 32,T= 1) :  1002.921 MB/s
  Random Read 4KiB (Q= 32,T= 1) :   519.597 MB/s [126854.7 IOPS]
 Random Write 4KiB (Q= 32,T= 1) :   198.579 MB/s [ 48481.2 IOPS]
         Sequential Read (T= 1) :  1573.306 MB/s
        Sequential Write (T= 1) :   981.280 MB/s
   Random Read 4KiB (Q= 1,T= 1) :    33.860 MB/s [  8266.6 IOPS]
  Random Write 4KiB (Q= 1,T= 1) :    22.039 MB/s [  5380.6 IOPS]

  Sequential Read (Q= 32,T= 1) :  7747.660 MB/s
  Sequential Write (Q= 32,T= 1) :  2392.856 MB/s
  Random Read 4KiB (Q= 32,T= 1) :   530.014 MB/s [129397.9 IOPS]
 Random Write 4KiB (Q= 32,T= 1) :   200.747 MB/s [ 49010.5 IOPS]
         Sequential Read (T= 1) :  1554.499 MB/s
        Sequential Write (T= 1) :  1530.302 MB/s
   Random Read 4KiB (Q= 1,T= 1) :    47.776 MB/s [ 11664.1 IOPS]
  Random Write 4KiB (Q= 1,T= 1) :    44.176 MB/s [ 10785.2 IOPS]

Исправил параметры диска: cache=writeback
на обоих машинах убрал iothread

Машина 1 (голый HDD)

   Sequential Read (Q= 32,T= 1) :  6636.662 MB/s
  Sequential Write (Q= 32,T= 1) :  1267.659 MB/s
  Random Read 4KiB (Q= 32,T= 1) :   506.402 MB/s [123633.3 IOPS]
 Random Write 4KiB (Q= 32,T= 1) :   168.603 MB/s [ 41162.8 IOPS]
         Sequential Read (T= 1) :  1613.175 MB/s
        Sequential Write (T= 1) :   904.485 MB/s
   Random Read 4KiB (Q= 1,T= 1) :    32.808 MB/s [  8009.8 IOPS]
  Random Write 4KiB (Q= 1,T= 1) :    21.104 MB/s [  5152.3 IOPS]

Машина 2 (LVM Cache)

   Sequential Read (Q= 32,T= 1) :  6300.115 MB/s
  Sequential Write (Q= 32,T= 1) :  2619.058 MB/s
  Random Read 4KiB (Q= 32,T= 1) :   433.777 MB/s [105902.6 IOPS]
 Random Write 4KiB (Q= 32,T= 1) :   178.397 MB/s [ 43554.0 IOPS]
         Sequential Read (T= 1) :  2208.846 MB/s
        Sequential Write (T= 1) :  1599.649 MB/s
   Random Read 4KiB (Q= 1,T= 1) :    53.293 MB/s [ 13011.0 IOPS]
  Random Write 4KiB (Q= 1,T= 1) :    25.654 MB/s [  6263.2 IOPS]

по результатам вернул параметр iothread в исходное состояние =1 :)

Какой программой тест то делается? Все как было через ОЗУ, так и остается (похоже). CrystalDiskMark предлагаю попробовать, как бы это не смотрелось банально. Тесты по 1 гб. прогона три-пять. - Только надо смотреть какой SLC кеш у SSD. Если он позволяет - больше, однозначно надо больше давать объема для тестов. Во вторых: надо посмотреть на статистику lvmcache. Чтобы оттуда точно было чтение. В каком режиме lvmcache работает? writeback или writethought?

Показывай статистику lvmcache + его параметр наполнения. Гоняй CrystalDiskMark, в приличном объеме.

Ну блин... дядька :)) я ж все написал тут :)

Что получил после тестов CrystalDiskMark 5.2.1 x64
Test : 1024 MiB [C: 34.3% (34.3/99.9 GiB)] (x5) [Interval=5 sec]

Ну и еще один вариант с режимом cache=directsync

   Sequential Read (Q= 32,T= 1) :   283.339 MB/s
  Sequential Write (Q= 32,T= 1) :    47.453 MB/s
  Random Read 4KiB (Q= 32,T= 1) :    56.739 MB/s [ 13852.3 IOPS]
 Random Write 4KiB (Q= 32,T= 1) :     2.043 MB/s [   498.8 IOPS]
         Sequential Read (T= 1) :   214.976 MB/s
        Sequential Write (T= 1) :    30.621 MB/s
   Random Read 4KiB (Q= 1,T= 1) :     9.624 MB/s [  2349.6 IOPS]
  Random Write 4KiB (Q= 1,T= 1) :     0.163 MB/s [    39.8 IOPS]

это для машины с лвм..
на машине без лвм пока бухгалтер работает и ругается что тормозит все во время текстов :)))

lvm cache стоит в writeback
(в роли батарейки - упс 3х киловатник с 100 амперной батарейкой)
а по поводу статистики - пардон.. как посмотреть-то ее правильно?? вот что дает lvs -a но это ж вроде не статистика?

root@node4d:~# lvs -a
  LV                VG          Attr       LSize  Pool       Origin            Data%  Meta%  Move Log Cpy%Sync Convert
  [lv_cache]        mbx_4d_data Cwi---C--- 33.13g                              100.00 17.59           0.00
  [lv_cache_cdata]  mbx_4d_data Cwi-ao---- 33.13g
  [lv_cache_cmeta]  mbx_4d_data ewi-ao---- 36.00m
  [lvol0_pmspare]   mbx_4d_data ewi------- 36.00m
  raid_data         mbx_4d_data Cwi-aoC---  1.86t [lv_cache] [raid_data_corig] 100.00 17.59           0.00
  [raid_data_corig] mbx_4d_data owi-aoC---  1.86t
  root              node4d-vg   -wi-ao---- 20.00g
  swap_1            node4d-vg   -wi-ao----  2.30g

а по поводу статистики - пардон... Как посмотреть-то ее правильно??

Отвечу твоими словами:

Ну блин... дядька :)) я ж все написал тут :)

https://www.linux.org.ru/forum/admin/13241776?cid=13243557 (комментарий)

Пересобрал массив на хосте.
Собрал из 2х двоек 4тб в страйпе (mdadm)

#mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Wed Mar 22 21:17:04 2017
     Raid Level : raid0
     Array Size : 3906766848 (3725.78 GiB 4000.53 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Wed Mar 22 21:47:04 2017
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

     Chunk Size : 512K

           Name : node4d:0  (local to host node4d)
           UUID : 0fcb808c:24032a8c:539090f5:f8906a09
         Events : 0

    Number   Major   Minor   RaidDevice State
       0       8       16        0      active sync   /dev/sdb
       1       8       32        1      active sync   /dev/sdc

Засунул его в lvm
прикрутил к нему лвм кеш с ссд на 33 гига...

#lvs -a
  LV                VG          Attr       LSize  Pool       Origin            Data%  Meta%  Move Log Cpy%Sync Convert
  [lv_cache]        mbx_4d_data Cwi---C--- 33.13g                              100.00 17.59           0.00
  [lv_cache_cdata]  mbx_4d_data Cwi-ao---- 33.13g
  [lv_cache_cmeta]  mbx_4d_data ewi-ao---- 36.00m
  [lvol0_pmspare]   mbx_4d_data ewi------- 36.00m
  raid_data         mbx_4d_data Cwi-aoC---  3.64t [lv_cache] [raid_data_corig] 100.00 17.59           0.00
  [raid_data_corig] mbx_4d_data owi-aoC---  3.64t
  root              node4d-vg   -wi-ao---- 20.00g
  swap_1            node4d-vg   -wi-ao----  2.30g

поработал недельку.
Собралось немного статистики, вот только не пойму, куда смотреть:

# uptime
14:13:55 up 6 days, 11:14

# lvs -o cache_read_hits,cache_read_misses
  CacheReadHits    CacheReadMisses
  1047826          3609453

Ну смотри:

# lvs -o cache_read_hits,cache_read_misses
  CacheReadHits    CacheReadMisses
  1047826          3609453

То есть, твои вирт. машины хотели читать, всего у них было запросов 4657279 (сумма CacheReadHits+CacheReadMisses) блоков. Из них из кеша SSD тебе было возвращено: 1047826, что соответствует чтения с кеша SSD 22.5%. Очень не плохой результат на мой взгляд. С тем учётом что у тебя всего 33гб SSD кеша.

У тебя я надеюсь не продуктивный сервер? Я так понял ты обычные жёсткие диски собираешь в RAID-0. Это опасно. Да и на продуктивном сервере кеш SSD, как минимум должен быть в RAID-1, а сами SSD, должны быть с конденсаторами (то есть с защитой от сбоя питания).

Ну... Как по мне, до продакшна далековато ( хотя и хочется побыстрее)...

Но мне почему-то подобная аппаратная конструкция казалась вполне приемлемой, учитывая нюанс в виде постоянного бекапа (инкрементального через rsync, например, раз в час на мой древний файловый сервер)ну и в дальнейшем подъёма ceph и ha кластера... ( благо ещё есть 3 аналогичные ноды)

Или я по-прежнему что-то недопонимаю?

Железо по правде гавенное... Это понимаю... Но имею то, что имею :(

Кстати пробовал рейд1... Скорость по записи откровенно унылая была. Даже мерять ничего не стал - на глаз тормозило весьма заметно!

И кстати, тот же хетцнер также порядочное гавнище тулит... Не только читал про это, но и видел своими глазами - товарищ там держит бухгалтерию... Обычный и5 с небуферизированной памятью на 1 вд блю..... Ну мне так Аида показала... Не исключаю, что это вполне себе правда.. Так что не такое код у меня и гавно ;))

что соответствует чтения с кеша SSD 22.5%. Очень не плохой результат на мой взгляд

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

В чем хреновость? Не вижу особой хреновости, кеш не адаптивный, так что все норм ИМХО. Может он много записывает, а потом это мало читает. Или может у него много ОЗУ.

Потому что, если cache miss, то надо прочитать с диска и записать на ссд, потом отдать, лишнее io на лицо, плюс вытеснение потенциально полезных блоков, не? И это только вершина айсберга, мне лень перепечатывать войну и мир, так что за самообразованием в инторнеты.

Может он много записывает, а потом это мало читает.

При таком раскладе точно ненужно.

Потому что, если cache miss, то надо прочитать с диска и записать на ссд, потом отдать, лишнее io на лицо, плюс вытеснение потенциально полезных блоков, не?

Неа, кеш не адаптивный ещё раз говорю.

Что неа, когда так оно и есть? И при чём здесь адаптивный/не адаптивный, поясни за свою теорию? Даже 70% уже весьма сомнительное мероприятие, а в случае попаданий меньше чем 50% я даже не буду рассматривать, потому что чем меньше попаданий, тем больше лишних io, ну и бонусом время доступа тоже увеличивается.

lvm cache, просто пропускает всю запись на HDD через SSD, не больше не меньше. Если нужно прочитать, запрос попадает на SSD, если там нету, идёт на HDD. Всё. Когда SSD переполняется старые блоки оттуда постепенно уходят. То есть, ничего с HDD, в SSD не кладётся. В целом примитивно, но как-то так.

А теперь, следи за руками: поступает запрос на чтение, на ссд нет, читаем с диска, стираем с ссд устаревший блок, пишем на ссд новый блок, отдаём запросившему, сам посчитаешь сколько накладных расходов? а если этот самый старый блок оказался на запись и ещё не попал на диск?

поступает запрос на чтение, на ссд нет, читаем с диска

Все. Больше lvmcache ничего не делает. Так и будет читать всегда с диска.

стираем с ссд устаревший блок, пишем на ссд новый блок

Такое будет только при записи новых данных. Если данные прерывистые. Если непрырывные - lvmcache должна сама напрямую начать пропускать их на HDD. Если данные прерывистые, то они насколько я понимаю, собираются в блоки, и по мере заполнения SSD выталкиваются непрерывным блоком на HDD.

небольшая статистика почти за месяц работы:

~# uptime
 22:46:43 up 27 days, 19:47,  2 users,  load average: 1.33, 1.32, 1.23

...

~# lvs -o cache_read_hits,cache_read_misses
  CacheReadHits    CacheReadMisses
           1347718         12718762
...

~# lvs -o cache_write_hits,cache_write_misses
  CacheWriteHits   CacheWriteMisses
          32706376         22477702

Получается, что по чтению, в кеш попадает всего около 10% :(
Зато по записи - почти 60%

В итоге получаю прирост в производительности по записи....

Как же можно поднять чтение?

Тут нужно разбираться как ты читаешь.

У тебя есть два случая чтения:

Ты можешь читать из ОЗУ. Можешь читать с дисков.

Так-как кеш не адаптивный, то тут есть моменты. Ты можешь читать не то что записываешь банально (и тут совет только я бы дал один/два: или уходить от lvmcache, или увеличивать ёмкость SSD). Я бы посоветовал второе. У тебя кажется SSD всего на 30 гб.

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

Походу большая часть чтения все-таки из памяти :(
Особенно учитывая виртуалки...
Проблему скорости решил не совсем спортивно: купил контроллер с аппаратной поддержкой ссд-кеширования и результат - честные 40% записи и 60% чтения реализованы аппаратно (проверял, глядя статистику - таки работают буржуйские проприетарные решения :) )

вернулся в свой первый топик

Походу большая часть чтения все-таки из памяти :(

Особенно учитывая виртуалки...

А чем это плохо?

Проблему скорости решил не совсем спортивно: купил контроллер с аппаратной поддержкой ссд-кеширования

Да в общем то, если есть бюджет, то почему бы и нет... :)

Плохо потому, что память не резиновая....

И если на ноде будет работать много людей и жрать память, то на кеши её не останется :)

Это я уже пробовал... Пока один в виртуалке - терпимо, а тормоза становятся заметны уже 3 человека активно что-то делают..