Я использую распределенную файловую систему в пространстве пользователя (GlusterFS), и я хотел бы быть уверен, что процессы GlusterFS всегда будут иметь необходимую вычислительную мощность.
Каждый исполнительный узел моей сетки имеет 2 ЦП, с 4 ядрами на ЦП и 2 потоками на ядро (Linux видит 16 «процессоров»).
Моя цель - гарантировать, что процессы GlusterFS обладают достаточной вычислительной мощностью, чтобы быть надежными, отзывчивыми и быстрыми. (Здесь нет маркетинга, просто мечты сисадмина ;-)
Считаю два основных момента:
Я думал о привязке экземпляров GlusterFS к конкретному «процессору».
Хочу быть уверенным, что:
Но как насчет ввода-вывода? Поскольку мы обрабатываем огромный объем данных (несколько терабайт), у нас будет много прерываний.
Как я могу распределить эти операции по своим процессорам? Каковы «лучшие практики»?
Спасибо за ваши комментарии!
Вот почему я не хочу использовать файловые системы FUSE в производстве ... Вместо этого я использую PVFS2.
Привязка пользовательского пространства к конкретному процессору иногда может повысить его производительность; но не ядро. (чек набор задач)
если бы это было возможно, вы бы превратили переключатель пользовательского пространства / ядра (уже измеряемый фактор производительности ОС) в проблему межпроцессорной связи / синхронизации. На много порядков хуже.
редактировать: Теперь, когда вы убрали идею «закрепить ядро», она стала более разумной. Да, вы можете использовать набор задач для запуска всех процессов сетки и оставить один или два процессора свободными для GlusterFS. Для аналогичного примера в системах Xen считается «лучшей практикой» зарезервировать один процессор для Dom0, который обрабатывает все операции ввода-вывода.