BCache + MDADM работает очень медленно
У меня есть 3x 14TB дисков toshiba mdadm -ed (/dev/md0) raid 5'd вместе, которые настроены как bcache. У меня есть быстрый SSD на 256 ГБ как фронт bache.
обратная запись включена в bcache.
Через несколько дней устройство (/dev/bcache0) становится чрезвычайно медленным Я имею в виду, как 1000-й от нормальной скорости.
Мои 2 вопроса:
Для /dev/md0, какую настройку я должен сделать для этих дисков toshiba? Это 4k блоков 64k блоков.
Могу ли я выполнить настройку bcache?
Я даже не совсем уверен, какую другую информацию я должен поместить здесь. Но если вы спросите, я буду обновлять этот пост. Спасибо!
Обновление 1- мой IOSTAT при чтении 100 МБ / с, только 3 МБ / с, запись: https://pastebin.com/wKKf4LTq
Компьютер является AMD 2990WX W /32 ГБ оперативной памяти. Процессор не проблема.
Мой старый 3770k от 2010-го года стал бы намного лучше, чем скорость чтения и записи. Это должна быть какая-то настройка или настройка. Спасибо!
Обновление 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 я бы придерживался размера 512 КБ. Это будет соответствовать размеру страницы для каждых 3 сегментов (как правило, вы подходите другим способом, но нет никакого разумного способа выровнять 1,5 МБ с любым размером сегмента = 2^n). Используйте размер сектора 4k. Кстати: это предполагает, что Samsung TLC использует размер страницы 1,5 МБ, но это где-то официально не задокументировано. Но 512 КБ все еще является безопасным значением для размера страницы 2 МБ, потому что он будет выравнивать каждые 4 сегмента.
Кроме того, выровняйте смещение данных в соответствии с настройкой RAID5. Документы bcache дают намеки на это. Очень важно понять это правильно. Лично я еще не пробовал такую настройку, но думаю [sysfs]/bdev*/partial_stripes_expensive также может быть интересен в RAID-5.
Я также предполагаю, что замедления появляются, когда кэш заполнен. Вы должны отключить сброс для кэша, это синхронная операция для многих дисков из-за ошибок прошивки. Вместо этого удалите bcache cdev, обрежьте весь раздел, затем измените размер раздела до 80-90% от его первоначального размера, выровняйте его по границе 2 МБ и заново создайте bcache. Затем, никогда не трогайте это свободное пространство раздела, это позволяет приводу выполнять выравнивание фонового износа, тогда удаление больше не требуется. Вы можете создать защитный раздел, чтобы зарезервировать это пространство, это также позволяет легко обрезать зарезервированное пространство.
Чтобы воссоздать устройство кэш-памяти, отсоедините его от резервного устройства с помощью sysfs, дождитесь завершения, затем отмените его регистрацию, выполните шаги по его правильному воссозданию, затем подключите вспомогательное устройство обратно к новому кэш-памяти. Это все можно сделать онлайн без перезагрузки. Но если вам это неудобно, сначала сделайте резервные копии.
Это должно было все еще быть создание или переиндексация или что-то еще. Из ниоткуда он начал работать очень быстро.
Поэтому, если у вас есть такая проблема, посмотрите на ваш статус mdadm. Если он что-то делает, это может быть причиной. Кроме того, по умолчанию он переиндексирует первое воскресенье каждого месяца.