Лог жизни

Архивы за Апрель, 2013

В процессе разработки одного проекта появилось требование хранить множество файлов (более 4 млн. штук). И в процессе количество файлов постоянно росло. Когда из количество перевалило через 6 млн. появилась проблема с работой с этими файлами. Даже разложив их по каталогам и создав разветвлённое дерево обход даже части этих каталогов стал занимать часы. Разумеется вначале никто не задумался над тем как это будут хранить и использовали обычный винт и ext4. В какой-то момент скорость чтения с этого раздела достигла 9MB/sec. Это слишком медленно. Экспериментальный переход на btrfs поднял в результате эту скорость до 13MB… Хотя это тоже не впечатляет. ssd для этого никто не собирался использовать да и объём уже перевалил через 1TB. Т.е. всё шло к использованию райдов. Поскольку коммерческий успех проекта остаётся под сомнением, то стоимость должна быть минимальной. А значит реализация должна быть программной.

Итак, нужно небольшое хранилище — на одном сервере/компьютере, т.е. до 4х дисков. Хранить нужно небольшие файлы — 1-3Mb каждый.
btrfs в нашем случае уже оказалась быстрее ext4, поэтому она и будет использоваться.
Кандидатами на управление хранилищем стали raid0 и raid10. Raid0 очевидно и объективно самый быстрый. Нередко утверждение, что самый быстрый raid10. Если подумать, то raid10 теоретически может быть таким же быстрым как и raid0 при чтении. Но вот для записи — очень сомнительно. Да и без особого труда можно найти различные тесты производительности аппаратных raid’ов.
Очевидное преимущество raid10 — надежность — не так уж и очевидно для не очень важных данных. Тем не менее, если надо хранить много, то используют либо raid, либо lvm. Можно и по старинке — вручную разделить данные по винтам. Надёжность везде одинаковая. Теряем винчестер — теряем данные. В raid0 размер strip’а (chunk) настраивается, поэтому при небольшом размере файлов большую часть данных можно будет таки восстановить.

В качестве подобытных были взяты 4 hdd Western Digital Caviar Blue 1TB
Пожалуй, один из самых быстрых среди имеющихся в свободном доступе без завышения цены.

raid0 собираем совершенно штатным образом:

mdadm -v —create /dev/md0 —level=raid0 —raid-devices=4 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1

Создание происходит мгновенно, ибо копировать и переразмечать нечего.
Сохраняем конфиг, чтоб при перезагрузке массив остался:

mdadm —examine —scan —config=mdadm.conf >> /etc/mdadm.conf

Создаём файловую систему:

#mkfs.btrfs -Lraid0 /dev/md0

WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using

fs created label raid0 on /dev/md0
        nodesize 4096 leafsize 4096 sectorsize 4096 size 3.64TB
Btrfs Btrfs v0.19

Интересно то, что FS всё еще экспериментальная. Впрочем это нисколько не помешало разработчикам Fedora 18 сделать btrfs файловой системой по умолчанию.

Проведём быстрый тест на скорость:

# hdparm -t /dev/md0

/dev/md0:
 Timing buffered disk reads: 2008 MB in  3.00 seconds = 669.11 MB/sec

В общем-то скорость линейного чтения колеблется от 650 до 690MB/sec.
Это, для сравнения, быстрее чем любой sata3 ssd ибо скорость больше чем способна пропустить sata3.
Полезный объём устройства 3,7T
Двух дневный тест показал устойчивую скорость и произвольного чтения и произвольной записи в 202MB/sec и 220MB/sec при операциях с файлами. Если ограничиться только чтением или только записью, то получаем 560MB/sec. Это устойчивые средние значения.
Весьма неплохо. Кстати, многие домашние ssd до этого не дотягивают.
Скорость весьма приличная на текущий момент. Поэтому собственно на нём и остановились. В случае, если один из винтов начнёт сыпаться, то придётся остановить весь raid, скопировать посекторно данные на новый винт и вернуть raid в активное состояние. Вполне допустимо для не очень важного хранилища. Если оно внезапно станет важным, то можно будет повысить его надежность и общую отказоустойчивость при помощи drbd.
В процессе тестирования нередко наблюдались пиковые скорости чтения и записи в 700MB/sec. Но поскольку файлы у нас маленькие, то такие пики возникали при параллельном чтении множества файлов. Видимо сказывается размер chunk’а.

Для очистки совести проведём те же тесты с raid10.
Создание raid10:

mdadm -v —create /dev/md0 —level=raid10 —raid-devices=4 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1

Но тут придётся подождать какое-то время. Пару-тройку часов.
В результате имеем следующее:

# hdparm -t /dev/md0

/dev/md0:
Timing buffered disk reads: 1080 MB in 3.01 seconds = 359.07 MB/sec

Мягко говоря разочаровывает. Точно такие же результаты были на raid0 с двумя дисками. Теоретическая возможность чтения с 4х винтов в данном случае не проявляется.
Но линейная скорость хоть и показательна, но не так важна для нас. Важнее произвольный доступ к файлам.
И он составил 190MB/sec на чтение и 125MB/sec на запись.
Полное разочарование с записью. Скорость чтения же сравнима с raid0. Напомню, что при этом мы еще и половину объёма дисков потеряем.

Есть еще один вариант программной реализации raid0, но уже средствами самой btrfs. С документации есть два параметра, которые могут повлиять на быстродействие и надёжность. data type — способ хранения данных. Влияет и на скорость доступа и на надёжность сохранения данных. Есть варианты: raid0, raid1, raid10 и single. И metadata profile — способ хранения метаданных. Он в большей степени влияет на возможность восстановления данных в случае мелких сбоев. Есть варианты: raid0, raid1, raid10, single и dup. Собственно, наблюдаем уже знакомые raid0 и raid10. Третий параметр, который скромно заявляет о возможном росте производительности при работе с файлами до 1GB — mixed. Для нас его влияние не очевидно.
Параметры задаются при создании файловой системы.

# mkfs.btrfs -d raid0 -m raid1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1

WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using

adding device /dev/sdd1 id 2
adding device /dev/sde1 id 3
adding device /dev/sdf1 id 4
fs created label (null) on /dev/sdc1
        nodesize 4096 leafsize 4096 sectorsize 4096 size 3.64TB
Btrfs Btrfs v0.19

Если надумаете использовать mixed, то учтите, что типы хранения данных и метаданных должны быть одинаковыми.
Обратите внимание, что единого устройства как при использовании raid здесь не получается. Монтировать можно любой раздел из использованных для файловой системы. Например, mount /dev/sdc1 /mnt/raid0

В общем-то, цифры получились весьма похожие с raid0 в исполнении md. Чтение 198MB/sec и запись 216MB/sec. Пики чтения чуть меньше 700MB/sec. Средняя скорость только чтения или только записи 660MB/sec, что очень приятно удивило.

При создании раздела с -m raid0 скорости совместного доступа немного возрастают. Чтение 203MB/sec и запись 219MB/sec. А вот раздельные чтение/запись немного уменьшились 654MB/sec.

В общем и целом можно рекомендовать использовать чистый btrfs без дополнительных прослоек, которые могут быть и точками отказа.

Еще существует возможность хранения данных в lvm в режиме striping. Это очень близкий аналог raid0. Однако, у автора с lvm не складываются отношения уже не первый год. Поэтому такой вариант повышения производительности не рассматривался чисто по субъективным причинам.

Ну и напоследок неудачный эксперимент с raid10 в btrfs:

# mkfs.btrfs -L raid10 -d raid10 -m raid10 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/
sdf1

WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using

adding device /dev/sdd1 id 2
adding device /dev/sde1 id 3
adding device /dev/sdf1 id 4
fs created label raid10 on /dev/sdc1
        nodesize 4096 leafsize 4096 sectorsize 4096 size 3.64TB
Btrfs Btrfs v0.19

Порадовало то, что создание заняло пару секунд. Это вызывает скорее вопросы, нежели радость.
Чтение 122MB/sec и запись 127MB/sec. Раздельные чтение/запись 657MB/sec. Т.е. не годится для нашей задачи, хотя скорость раздельных операций и удивляет и радует.

Для душевного успокоения коллег был проведён тест с ext4 поверх raid0. Результаты ожидаемы.

# mkfs.ext4 /dev/md0 -L raid0
mke2fs 1.42.5 (29-Jul-2012)
Filesystem label=raid0
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=256 blocks, Stripe width=1024 blocks
244195328 inodes, 976760832 blocks
48838041 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
29809 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000, 214990848, 512000000, 550731776, 644972544

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

Проведём небольшой тюнинг, который благоприятно повлияет на производительность:

tune2fs -O extents,uninit_bg,dir_index /dev/md0
tune2fs -o journal_data_writeback
tune2fs -m 0 /dev/md0
mount /dev/md0 raid0 -o acl,user_xattr,noatime,nodiratime,barrier=0,commit=0

Результаты плачевные для нашей задачи. Чтение и запись: 60MB/sec и 86MB/sec. Только чтение/запись 535MB/sec.

Выводы очевидны. Btrfs намного выгоднее для нашей задачи чем ext4, а raid0 быстрее raid10.

Осталось только добавить, что кроме рабочих обработчиков данных использовались и сторонние утилиты.
Для синтетических тестов использовались stress и bonnie++
Фактические данные о чтении/записи собирались при помощи sysstat.

Купил сегодня винт WD Scorpio Black WD7500BPKT, 750Гб, HDD, SATA II:

Disk /dev/sdc: 750.2 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders, всего 1465149168 секторов
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xf8326998

Создадим раздельчик:

Команда (m для справки): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): p
Номер раздела (1-4, по умолчанию 1): 
Используется значение по умолчанию 1
Первый sector (2048-1465149167, по умолчанию 2048): 
Используется значение по умолчанию 2048
Last sector, +sectors or +size{K,M,G} (2048-1465149167, по умолчанию 1465149167): +700G
Значение за пределами диапазона.
Last sector, +sectors or +size{K,M,G} (2048-1465149167, по умолчанию 1465149167): 680G
Значение за пределами диапазона.
Last sector, +sectors or +size{K,M,G} (2048-1465149167, по умолчанию 1465149167): +650G
Partition 1 of type Linux and of size 650 GiB is set

Сабж!
Заявлено 1465149168 секторов, причём первые 2048 нельзя заюзать.
Итого (1465149168 — 2048) / 2 = 732573560 килобайт. Уже на глазок нет 750Gb. Делим на 1024 и еще раз на 1024 и получаем 698,636Gb.
-7% Неслабо…