Назад | Перейти на главную страницу

Как я могу проверить, есть ли у меня эти улучшения масштабируемости метаданных XFS на CentOS6?

Похоже, у нас проблемы с производительностью обновления метаданных в CentOS6, поэтому я проверяю, есть ли у нас улучшения, упомянутые в этой презентации Дейва Чиннера:

http://xfs.org/images/d/d1/Xfs-scalability-lca2012.pdf

В нем упоминаются эти исторические проблемы:

Проблемы с метаданными XFS

Чтение и поиск метаданных выполняется быстро и хорошо масштабируется.
Производительность модификации метаданных УЖАСНАЯ.
Превосходный параллелизм выполнения транзакций, небольшой параллелизм фиксации транзакций.
Обычно не масштабируется выше одного процессора.
Пропускная способность фиксации транзакции ограничена пропускной способностью журнала.
Обратная запись метаданных вызывает штормы ввода-вывода.
Много замков, с которыми нужно разобраться.

Я не могу найти, какой была бы машина выпуска, чтобы отслеживать исправления, которые он представляет.

CentOS6 / RHEL6 справедливо работает с довольно старым ядром 2.6.32, и я хотел бы определить, выполняем ли мы улучшения, упомянутые в презентации.

Больше информации:

$ modinfo /lib/modules/2.6.32-642.6.2.el6.x86_64/kernel/fs/xfs/xfs.ko
filename:       /lib/modules/2.6.32-642.6.2.el6.x86_64/kernel/fs/xfs/xfs.ko
license:        GPL
description:    SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled
author:         Silicon Graphics, Inc.
srcversion:     67725EF8353DC29370566C8
depends:        exportfs
vermagic:       2.6.32-642.6.2.el6.x86_64 SMP mod_unload modversions

Разрешите пояснить:

Я не прошу совета по разрешению проблемы с производительностью в этом вопросе. я только спрашивая, как определить, находится ли исправление XFS, описанное в связанной презентации, в текущей файловой системе XFS или нет.

Изменение алгоритма, указанное как решение этих проблем с метаданными XFS, - это отложенное ведение журнала, как в слайд-шоу linux.conf.au 2012, так и в LWN написать об этом.

Зафиксировать история документации показывает, что экспериментальный флаг был удален в 5d0af85. Поскольку это было примерно в октябре 2010 года, Linux 2.6.37:

xfs: удалить экспериментальный тег из параметра delaylog

Мы обещали сделать это для 2.6.37, и код выглядит достаточно стабильным, чтобы выполнить это обещание.

Так что нет, это не в 2.6.32. Я не совсем уверен, что Red Hat сделала это, но сомневаюсь, что это серьезное изменение.

Сосредоточьте свои усилия на обновлении ядра. Поскольку у EL6 осталось 16 месяцев до обновлений безопасности, сделайте это с обновлением ОС. Новые ядра или переключение файловых систем возможно с EL6, но это меняет ваши процедуры, когда вы должны обновляться.