LINUX.ORG.RU
решено ФорумAdmin

xfs: optimal allocation group count

 


0

2

Господа, скоро будет создаваться xfs размазанная по 16 x 3.2TB SSD в RAID-10. Есть рекомендации на тему agcount? Под нагрузкой будет не меньше сотни simultaneous writers (если это имеет значение). Склоняюсь к 1024, но был бы рад услышать любые советы. Заранее спасибо.

★★★★★

Что-то мне подсказывает я что-то сделал не так. Может случайно анонимам запретил комментировать (не хотел - случайность чес слово, если кто-то из админов может поправить я только рад буду), что-то. Может это какая-то супер секретная know how, не понятно. Ну да ладно. Всех с праздничком если чего! И исполнения всех желаний!

bugfixer ★★★★★
() автор топика

Склоняюсь к 1024

Это абсурд. Их в любом случае должно быть не (сильно) больше, чем процессорных ядер в системе/кластере. Рекомендую оставить дефолт, убедившись, что он не слишком большой.

i586 ★★★★★
()
Ответ на: комментарий от i586

Хм, дефолт как то не сильно вяжется с предложением «группа на 4-8Gb» которое регулярно встречаю на форумах. Чем плох большой agcount?

bugfixer ★★★★★
() автор топика

Вот что у редхата написано по этому поводу:

https://access.redhat.com/solutions/2532271

The xfs filesystem chooses the appropriate Allocation Group number depending on the Stripe Width and Stripe unit provided during the filesystem creation. For manually deciding the number of optimum allocation number in an environment where the stripe width and stripe unit are unknown, Select the allocation number such that allocation-groups/CPU-core ratio to be <= 1 . This will minimize CPU contention for XFS per Allocation group locks etc.
bigbit ★★★★★
()
Ответ на: комментарий от bigbit

Оно на десятках терабайт сваливается в 32. 32 однозначно мало, учитывая MQ и тому подобные новомодные плюшки.

bugfixer ★★★★★
() автор топика
Ответ на: комментарий от bugfixer

32 однозначно мало

Да и ядер на этой конкретной машинке - 80, после HT…

bugfixer ★★★★★
() автор топика
Ответ на: комментарий от bugfixer

«группа на 4-8Gb» которое регулярно встречаю на форумах.

Это не так. ~32TB в массиве => должно быть ~32 ag по дефолту. Это вполне нормально при 40 ядрах.

i586 ★★★★★
()
Последнее исправление: i586 (всего исправлений: 1)
Ответ на: комментарий от i586

Это не так. ~32TB в массиве => должно быть ~32 по дефолту.

Имеется аргументация сильнее чем «патаму што»? Мне не очевидно, от слова совсем…

bugfixer ★★★★★
() автор топика
Ответ на: комментарий от i586

Это не так. ~32TB в массиве => должно быть ~32 ag по дефолту.

Расковырял чуть глубже: в старые времена agsize походу была ограничена 4GB, отсюда и «растут ножки» более ранних рекомендаций - «группа на 3GB» (I’m still puzzled почему дефолтам не доверять?). Нынче размер ограничен 1TB. Для 32TB+ volumes mkfs.xfs сваливается в «размер / 1TB» for group count (что понянтно). Что интересно - для volumes меньшего размера (но большего 512GB) agcount «гвоздями прибит» к 32ум, и мне совсем неочевидно почему - цифра с потолка взята, кмк… Typical core count, may be?

В нашем случае будет открыто в каждый конкретный момент времени порядка 1k файлов на запись, будем писать примерно 3TB/day (according to iostat) при заполнении fs примерно 80%, из которых 1.5-2TB это appends ~1kb each, остальное это randomly spread short updates (WAF accounted for). Собственно поэтому agcount в 1k и казался разумным - была надежда что fragmantation будет меньше (хотя на SSD - пофиг, кмк).

В общем - придётся таки походу заныривать в сорсы ядра ещё глубже…

bugfixer ★★★★★
() автор топика
Последнее исправление: bugfixer (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.