BCache + выполнение MDADM чрезвычайно медленного
Я имею 3x Toshiba, на 14 ТБ управляет mdadm-редактором (/dev/md0) совершите рейд 5'd вместе, которые являются установкой как bcache. У меня есть быстрый SSD на 256 ГБ как передняя сторона ловильного колокола.
обратная запись включена на bcache.
После нескольких дней, устройство (/dev/bcache0) становится чрезвычайно медленным. Я имею в виду как 1000-й из, его - нормальная скорость.
Мои 2 вопроса:
Для/dev/md0, какую настройку я должен сделать для тех дисков Toshiba? Это - блоки 4k 64k блоки.
Там какой-либо bcache настраивается, я мог сделать?
Я даже не действительно уверен, что другую информацию я должен поместить здесь. Но если Вы спросите, то я обновлю это сообщение.Спасибо!
Обновите 1-моих IOSTAT при получении 100mb/sec чтения, только 3mb/sec запись: https://pastebin.com/wKKf4LTq
Компьютер является AMD 2990wx w/32gb поршень. ЦП не является проблемой.
Мой старый 3770k от 2010ish получил бы трудно лучшее чтение и скорости записи, чем это. Это получено, чтобы быть своего рода установкой или настройкой.Спасибо!
Обновите 2-, В то время как система работает обычно, ниже вывод hdparm. hdparm берет к долго для выполнения, когда он не работает обычно.
/dev/md0:
Timing cached reads: 11148 MB in 2.00 seconds = 5578.33 MB/sec
Timing buffered disk reads: 1372 MB in 3.00 seconds = 456.84 MB/sec
/dev/bcache0:
Timing cached reads: 12564 MB in 2.00 seconds = 6286.57 MB/sec
Timing buffered disk reads: 1226 MB in 3.00 seconds = 408.66 MB/sec
Спасибо!
2 ответа
С Samsung память TLC я придерживался бы 512k размера блока. Это выровняется с размером страницы для каждых 3 блоков (обычно, Вы соответствовали бы наоборот, но нет никакого нормального способа выровнять 1.5 МБ с любым размером блока = 2^n). Используйте размер сектора 4k. BTW: Это принимает, Samsung, TLC использует размер страницы 1.5 МБ, но это официально не документируется где-нибудь. Но 512k является все еще безопасным значением также для размера страницы 2 МБ, потому что это выровняло бы каждые 4 блока.
Кроме того, выровняйте свое смещение данных с Вашей установкой RAID5. bcache документы дают некоторые подсказки для этого. Очень важно разобраться в этом. Лично, я еще не попробовал такую установку, но я предполагаю [sysfs]/bdev*/partial_stripes_expensive может также быть интересным в RAID-5.
Я также предполагаю, что замедление обнаруживается, когда кэш заполнился. Необходимо отключить отбрасывание для кэша, это - синхронная операция для многих дисков из-за микропрограммных ошибок. Вместо этого удалите bcache cdev, обрежьте целый раздел, затем измените размер раздела к 80-90% его первоначального размера, выровняйте его к границе 2 МБ и воссоздайте bcache. Затем никогда не касайтесь этого свободного пространства раздела, оно позволяет диску сделать фоновое выравнивание износа, отбрасывание больше не необходимо затем. Вы могли создать защитный раздел для резервирования этого пространства, это делает также легким обрезать зарезервированное пространство.
Для воссоздания устройства кэша отсоедините его от отступающего устройства через sysfs, ожидайте завершения, затем не зарегистрируйте его, выполните шаги для воссоздания его правильно, затем присоедините отступающее устройство назад к новому кэшу. Это может все быть сделано онлайн без перезагрузки. Но если Вы не довольны им, сделайте резервные копии сначала.
Это должно было все еще создавать или повторно индексировать или что-то. Из не, где, это начало работать очень быстро.
Таким образом, кто-либо еще, который имеет эту проблему, смотрит на Ваше mdadm состояние. Если это делает что-нибудь, которое могло бы быть причиной. Кроме того, по умолчанию это повторно индексирует первое воскресенье каждого месяца.