LINUX.ORG.RU
ФорумAdmin

Bcache тормозит

 ,


0

2

Случилось мне на днях позаимствовать 8 терабайт винтов, чего как раз хватило на полный бэкап файлопомойки. Ну и решил я попробовать bcache - потому как тормоза при дампе кэша торрент-клиента изрядно надоели.

Изначально планировалось оставить имеющийся raid6, на него bcache, дальше dm-crypt, затем lvm, и туда уже ФС. Беглые тесты показали, что процессор dm-crypt не тянет (меньше 300мб/с записи, тогда как без него - чуть больше 600мб/с), в результате от шифрования решено было пока отказаться и попробовать собственно bcache.

Для тестов отказался от lvm и накатил ext4 сразу на bcache, скопировал данные, запустил живую нагрузку (5тб торрентов на 365-мбитном канале) и стал ждать. Сперва всё было очень хреново - iowait взлетел с 10-20% до 50+, скорость раздачи упала в 2 раза, тормоза в момент дампа сменились постоянными тормозами - скоростей порядка 3МБ/с я не видел уже очень давно.

Погоревал, да оставил - пусть греется. Грелось оно долго - уже прошли сутки, а из 215 гигов bcache занял всего 187.

А сейчас смотрю и не понимаю нихрена. Кэш уже почти полный, чтение с ssd я вижу, hit ratio - около 40%, что в целом неплохо для такого количества торрентов, вот только iowait упал с 50+ до 20-50 и на ssd нагрузка нет-нет, да бывает 100%. При этом если заполнение кэша отключить (cache_state none), то iowait моментально приходит в норму.

Это ssd такой убогий, или я у bcache не включил что-то очень важное?

Для начала:

1). echo deadline > /sys/block/sda/queue/scheduler на все HDD

2). echo 10000 > /sys/block/sda/queue/nr_requests на все HDD, можно больше — до 1000000

P.S. Запись идет какая-то?

chaos_dremel ★★
()
Ответ на: комментарий от chaos_dremel

Попробовал, 0 эффекта. Да и при чём тут HDD?

Ещё раз - делаю echo none > /sys/block/bcache0/bcache/cache_mode - всё хорошо, на ссд ничего не пишется, но чтение с него идёт. Меняю обратно на writeback/writethrough/writearound - всё плохо, но есть запись на ссд.

Запись в фс - не идёт, запись на ссд - идёт - кэш заполняется.

Вот как-то так это выглядит: http://i.imgur.com/eO4DsmY.png Слева - кэш отключен, справа - кэш включен. Разница между ними - когда кэш включен, то есть запись на ссд.

koi-sama
() автор топика
Ответ на: комментарий от koi-sama

Тогда по идее bcache по какой-то причине медленно пишет данные на себя и/или потом медленно их передаёт куда надо. Медленнее чем этого ожидают программы. Итого можно поиграться с задержками в параметрах bcache или с подсистемой ввода-вывода.

SSD всё ещё видится как блочное устройство?

Посмотри какой объем dirty буферов в системе (через atop например) и если их много снизь dirty_background_bytes до 2МБ

chaos_dremel ★★
()
Ответ на: комментарий от chaos_dremel

Пока что я вижу следующее - ссд тормозит на запись, чем блокирует bcache, что уже приводит к тормозам в софте. Пробовал менять congested_read/write_threshold_us - вроде помогает, но при этом заполнение кэша практически останавливается. Если раньше он худо-бедно за ночь наполовину прогревался, то после изменений за то же время было заполнено процентов 5, с соответствующими проблемами в виде никакого hit ratio. Ну и это всё равно медленнее, чем без кэша вообще.

Ещё я переразбил ssd - оставил почти 40% места контоллеру под его тормозные нужды. Не помогло. Ищу возможность отключить кэш без потери данных чтобы дать контроллеру время прибрать мусор. Пока нихрена не получается - или выключение записи (чтение остаётся), или отключение кэширующего устройства вообще, после чего bcache сходит с ума и показывает что кэш заполнен, но в то же время работает с ним как с пустым (т.е. ничего не читает и только пишет).

SSD видится - куда ж оно денется? Dirty кэша - килобайты, dirty_background_bytes - 0, ниже некуда.

koi-sama
() автор топика
Ответ на: комментарий от koi-sama

Там или dirty_background_ratio в процентах от свободной оперативы( или dirty_background_bytes (соответственно в байтах). Установка любого значения в один из них автоматом обнуляет в другом. По дефолту стоит dirty_background_ratio на 10. Через него сложно ставить малые значения. А нужно 2-8 метров максимум.

И ещё у bcache стратегия кешировать случайное чтение, и размер «случайного» блока можно выставить. По дефолту вроде метр. А у торрентов размер блока может легко быть больше метра ведь.

chaos_dremel ★★
()
Ответ на: комментарий от chaos_dremel

Поставил 2 метра, разницы не заметил.

Там сейчас отключено распознавание последовательного чтения, да и до этого кэшировалось то что надо. 40% попаданий в 200гб кэша на 5тб данных - это в целом неплохо.

Всё ведёт к тому, что диск - дешёвое УГ, и под кэш с постоянной нагрузкой не подходит.

koi-sama
() автор топика
Ответ на: комментарий от koi-sama

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

DALDON ★★★★★
()
Ответ на: комментарий от DALDON

Lvmcache, если не ошибаюсь, надстройка над dm-cache. Dm-cache «конкурент» bcache, так же присутствующий в ядре. Хороший повод протестировать: вдруг там, где слабость bcache, dm-cache зарулит.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

Все так, мне нравится как работает lvmcache.

DALDON ★★★★★
()
15 марта 2017 г.
Ответ на: комментарий от sanyock

Для данных которые пишутся через dirty кэш сам по себе этот параметр не влияет на потерю данных. Там теряется всё что было в dirty кэше, а это в разы больше. Для данных, которые пишутся на диск в режиме directIO (напрямую, без кеширования) это увеличивает количество данных которые могут быть потеряны при потере питания.

chaos_dremel ★★
()
Ответ на: комментарий от sanyock

какой эффект будет в ZFS от:

1). echo deadline > /sys/block/sda/queue/scheduler на все HDD

И+

2). echo 10000 > /sys/block/sda/queue/nr_requests на все HDD, можно больше — до 1000000

надежность? отклик?

Особенно интересно в случае нагрузки DBMS

если раздел данных ext3->iscsi->zvol->zpool->диски, которым можно выставить такие параметры очереди и планировщика

sanyock ★★
()
Последнее исправление: sanyock (всего исправлений: 1)
Ответ на: комментарий от sanyock

Планировщик deadline однозначно будет не лишним. (Собственно чем больше наверчено сверху (софт рейды) или снизу (хард рейды) дисков, тем больше смысла в простом планировщике.

С ростом nr_requests растёт пропускная способность (что хорошо), но при этом же растёт latency (что плохо), так что тут палка о двух концах.

Кроме того свои параметры есть и у iscsi.

Также есть block device queue (hdparm -Q /dev/sda), которая наравне с nr_requests влияет на пропускную способность и время отклика. Для некоторых «странных» дисков выставление её в 1 серьёзно поднимает производительность.

Ну и ext3 для БД это очень плохая идея. Ограничение на количество потоков записи в один файл и т.п. очень ограничивают производительность.

chaos_dremel ★★
()
Ответ на: комментарий от sanyock

какой эффект будет

echo 10000 > /sys/block/sda/queue/nr_requests на все HDD, можно больше — до 1000000

Ну во первых это круто. Во вторых можно насобирать очередь длиной до 4х гигабайт.
Высокий nr_request — это попытка просрать данные смержить максимальное количество запросов, перед отправкой к контроллеру.
Размен задержек на пропускную способность.

aidaho ★★★★★
()
Ответ на: комментарий от anonymous

У NVME и так утилизация всего несколько %, а вот для HDD утилизация упала при увеличении nr_requests, но вроде как утилизация зависит от длины очереди чисто формально (т.е. по формуле)?

sanyock ★★
()
Ответ на: комментарий от sanyock

Не очень понятна разница между avgrq-sz и avgqu-sz
в iostat -x N

Хотя бы одна из этих величин показывает сколько позиций заполнено в очереди команд диска до достижения nr_requests?

Если у меня avgrq-sz в пределах сотни и часто даже в разы меньше, то почему повлияло увеличение nr_requests до нескольких тысяч или просто совпало?

sanyock ★★
()
Последнее исправление: sanyock (всего исправлений: 1)
Ответ на: комментарий от anonymous

На nvme наверное только профит будет, задержки аппаратно очень низкие.

На ssd не удастся даже близко набрать такую очередь.

aidaho ★★★★★
()
Ответ на: комментарий от sanyock

Там есть пару нюансов:

1. Большой размер nr_requests обычно требуется если на HDD ведётся случайная запись/чтение, для того, чтобы минимизировать движение головок по диску. Да latancy становится больше, но на HDD это не так пренципиально

2. Большая очередь будет использоваться только при достаточно большой нагрузке на диск.

3. avgrq-sz и avgqu-sz показывают средние очереди за некий промежуток времени.Вполне возможно что в одну секунду есть пару очередей в 1000+ которые пишутся быстрее, чем раньше и улучшают статистику

4. В рейдовых конфигурациях, deadline обычно больше влияет на нагрузку, чем nr_requests

5. Планировщики и длинна очереди на клиенте тоже важны. Впрочем клиентскую очередь я бы уменьшал,по возможности.

6. Рекомендую ещё последить за объёмом dirty кеша на сервере и клиенте.

chaos_dremel ★★
()
Последнее исправление: chaos_dremel (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.