VPF::Тормоза xfs - Форум программистов

nickless

Дата 11.5.2009, 19:27 (ссылка)

(нет голосов)

Загрузка ...

Гентозавр

Профиль
Группа: Участник Клуба
Сообщений: 2976
Регистрация: 29.8.2005
Где: Germany

Репутация: 41
Всего: 181

День добрый. Недавно заметил, что xfs стала работать заметно медленнее, провёл простенький тест, чтобы сравнить reiserfs, xfs и ext3:

Код


#!/bin/zsh

DEV=/dev/sda3
MNT=/mnt/other
FILE=/usr/portage/distfiles/thunderbird-2.0.0.21-source.tar.bz2
LABEL=hdd250_other

echo start

echo
echo reiserfs
echo format
mkfs.reiserfs -q -l $LABEL $DEV
mount $DEV $MNT -t reiserfs -o rw,noatime
for i in 1 2 3; do
    echo "run $i"
    sync
    df -h $MNT

    echo
    echo unpack
    time tar xj -C $MNT -f $FILE
    sync
    df -h $MNT

    echo
    echo remove
    time rm -rf $MNT/mozilla
    sync
done
umount $MNT

echo
echo xfs
echo format
mkfs.xfs -f -q -L $LABEL $DEV
mount $DEV $MNT -t xfs -o rw,noatime
for i in 1 2 3; do
    echo "run $i"
    sync
    df -h $MNT

    echo
    echo unpack
    time tar xj -C $MNT -f $FILE
    sync
    df -h $MNT

    echo
    echo remove
    time rm -rf $MNT/mozilla
    sync
done
umount $MNT

echo
echo ext3
echo format
mkfs.ext3 -q -L $LABEL $DEV
mount $DEV $MNT -t ext3 -o rw,noatime
for i in 1 2 3; do
    echo "run $i"
    sync
    df -h $MNT

    echo
    echo unpack
    time tar xj -C $MNT -f $FILE
    sync
    df -h $MNT

    echo
    echo remove
    time rm -rf $MNT/mozilla
    sync
done
umount $MNT

echo
echo finish

Принцип простой: форматируем раздел, монтируем его, 3 раза (замеряем скорость распаковки сорцов thunderbird и время на удаление етого всего).

Результат меня удивил, при примерно одинаковом использовании CPU и user time, распаковка архива на xfs длится в 6 (!) раз дольше чем на другие fs, причем в это время заметно тормозит вся система. Удаление созданой папки на xfs длится в 40 - 80 (!) раз дольше. И это при том, что пару лет назад, когда я сравнивал файловые системы примерно тем же способом, xfs была одной из лучших.

Код


real t | reiserfs  | xfs       | ext3
-------+-----------+-----------+------------
unpack | 32.78     | 185.07    | 29.09
remove | 2.43      | 86.77     | 0.74

Ядро 2.6.29-gentoo-r3, I/O scheduler CFQ, HDD Seagate Barracuda 7200.10 ST3250620A

Собственно вопросов два: что за smile

и как это лечить?

ЗЫ В гугле нашел пару вопросов насчет медленного удаления больших директорий на xfs, но ни одного ответа...

--------------------

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies
- Linus Torvalds

bilbobagginz

Дата 11.5.2009, 19:33 (ссылка)

(нет голосов)

Загрузка ...

Naughtius Maximus

Профиль
Группа: Экс. модератор
Сообщений: 8813
Регистрация: 2.3.2004
Где: Israel

Репутация: 113
Всего: 317

Цитата(nickless @ 11.5.2009, 19:27

)

И это при том, что пару лет назад, когда я сравнивал файловые системы примерно тем же способом, xfs была одной из лучших.

вопрос тогда как долго занимает dd if=/dev/zero of=/my/xfs/file bs=1024k count=1024
я тоже как раз пару лет сравнивал... только сейчас мой 1.4ТБ массив нельзя "перенести" просто так.
может придётся остановить работу....

Добавлено через 7 минут и 16 секунд
ну и др. вопросы:
какой у тя проц (/proc/cpuinfo), сколько памяти, может диск крошится.... смартд работает ?

--------------------

Я ещё не демон. Я только учусь.

nickless

Дата 11.5.2009, 20:07 (ссылка)

(нет голосов)

Загрузка ...

Гентозавр

Профиль
Группа: Участник Клуба
Сообщений: 2976
Регистрация: 29.8.2005
Где: Germany

Репутация: 41
Всего: 181

Цитата(bilbobagginz @ 11.5.2009, 18:33

)

вопрос тогда как долго занимает dd if=/dev/zero of=/my/xfs/file bs=1024k count=1024

Код


# dd if=/dev/zero of=/mnt/other/file bs=1024k count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 13.4953 s, 79.6 MB/s

# hdparm -tT /dev/sda3
/dev/sda3:
 Timing cached reads:   1730 MB in  2.00 seconds = 865.02 MB/sec
 Timing buffered disk reads:  238 MB in  3.02 seconds =  78.74 MB/sec

Цитата(bilbobagginz @ 11.5.2009, 18:33

)

какой у тя проц (/proc/cpuinfo), сколько памяти, может диск крошится.... смартд работает ?

AMD Athlon64 3500+, система 32bit, памяти 1G, диск крошится исключительно с xfs? смартд работает, пишет всё ок

Код


processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 47
model name      : AMD Athlon(tm) 64 Processor 3500+
stepping        : 2
cpu MHz         : 2200.000
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
                  clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm
bogomips        : 4620.44
clflush size    : 64
power management: ts fid vid ttp tm stc

Добавлено @ 20:20

Цитата(nickless @ 11.5.2009, 19:07

)

пишет всё ок

Ну в смысле за исключением этих заходов

Это сообщение отредактировал(а) nickless - 11.5.2009, 20:22

--------------------

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies
- Linus Torvalds

nickless

Дата 11.5.2009, 20:49 (ссылка)

(нет голосов)

Загрузка ...

Гентозавр

Профиль
Группа: Участник Клуба
Сообщений: 2976
Регистрация: 29.8.2005
Где: Germany

Репутация: 41
Всего: 181

Нарыл дискуссию насчет barriers в xfs:
http://oss.sgi.com/archives/xfs/2008-12/msg00219.html
http://oss.sgi.com/archives/xfs/2008-12/msg00161.html

Если примонтировать этот раздел с rw,noatime,nobarrier, тормоза проходят:

Код


# time tar xj -C /mnt/other -f /usr/portage/distfiles/thunderbird-2.0.0.21-source.tar.bz2

real            31.85
user            18.34
sys             3.51
CPU             68%

Вопрос только какой ценой.
Ушёл читать ссылки

--------------------

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies
- Linus Torvalds

bilbobagginz

Дата 11.5.2009, 21:15 (ссылка)

(нет голосов)

Загрузка ...

Naughtius Maximus

Профиль
Группа: Экс. модератор
Сообщений: 8813
Регистрация: 2.3.2004
Где: Israel

Репутация: 113
Всего: 317

Цитата(nickless @ 11.5.2009, 20:49

)

noatime,nobarrie

ноатайм ... это понятно.
у меня Core 2 Duo Е6400.
вот флажки:

Код


flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat 
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon 
pebs bts pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm

может при больших дисках есть какие-то флажки, которые помогают....

Это сообщение отредактировал(а) bilbobagginz - 11.5.2009, 21:27

--------------------

Я ещё не демон. Я только учусь.

nickless

Дата 12.5.2009, 23:17 (ссылка)

(нет голосов)

Загрузка ...

Гентозавр

Профиль
Группа: Участник Клуба
Сообщений: 2976
Регистрация: 29.8.2005
Где: Germany

Репутация: 41
Всего: 181

Цитата(bilbobagginz @ 11.5.2009, 20:15

)

может при больших дисках есть какие-то флажки, которые помогают....

Вряд ли, да и 20G - не много

Короче, выяснил следующее:
Где-то в начале года улучшилась поддержка I/O барьеров (Documentation/block/barrier.txt) в xfs, теперь xfs по дефолту использует барьеры, если они поддерживаются железом. Барьеры позволяют гарантировать порядок записи данных на диск, даже в случае современных дисков с большим кэшем. Это важно для сохранности данных при отключении питания, но значительно замедляет изменения метаданных, т.к. включеные барьеры пресекают все попытки оптимизации.

Как я понимаю, все другие файловые системы пока не используют барьеры, но это может изменится в будущем.

Ну а с XFS имеем 4 варианта из комбинаций write cache on/off + barriers on/off (см. флаг -W в man hdparm и опцию nobarrier в man mount):

1. write cache on, barriers off
Самый быстрый и небезопасный. Контроллер диска оптимирует запросы, изменяя порядок записи данных вне зависимости от ОСи. То есть контроллер сообщает ядру, что запись завершена, хотя данные еще в кэше (даже fsync не поможет), а из-за изменений порядка записи данные могут быть записаны позже метаданных, даже если запрос на запись метаданных пришел раньше.
Не рекоммендуется при больших размерах кэша (особенно для RAID, 4 диска с 32 метрами кэша каждый в RAID0 = 128 метров потерянных данных).
What is the problem with the write cache on journaled filesystems? в XFS FAQ

2. write cache off, barriers off
Примерно в 2 раза медленней чем вариант 1 при большом количестве запросов, самый безопасный. Контроллер ничего не кэширует.
Рекоммендуется для RAID со своим non-volatile кэшем (кэш дисков отключить, а кэш RAID контроллера включить).

3. write cache off, barriers on
Медленнее чем 2, но ни чем не лучше.

4. write cache on, barriers on
Это (в теории) идеальный вариант, кэш есть, но контроллер не может своевольничать когда не надо. При отключении питания данные из кэша будут потеряны, но по крайней мере журнал будет в порядке. Скорость этого варианта сильно зависит от контроллера и самого диска, (а еще не все диски поддерживают барьеры). Судя по всему это может быть от 1.5 до 15 раз медленнее чем вариант 1, как повезёт.

Для себя решил оставить барьеры на разделах для данных, всё равно туда редко пишу, а / переформатировал в reiserfs.

--------------------

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies
- Linus Torvalds

0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема \| *NIX системы: Общие вопросы \| Следующая тема »