Падение производительности дисков после достижения объема в 75% места

Все написал! Кроме того, какие винты )

Так написал жеж - netapp e-series :) на ней SDB, SDA как толстый диск через вмваре, датастора на dorade 6000.

По сути - NL-SAS, но к её производительности вопросов нету. Там ДДП из 60 дисков. На другой системе мы её грузим до 700МБ\с без проседаний.

Так написал жеж - netapp e-series :) на ней SDB, SDA как толстый диск через вмваре, датастора на dorade 6000.

По сути - NL-SAS, но к её производительности вопросов нету.

Это все понятно

Там ДДП из 60 дисков.

Из каких?

На другой системе мы её грузим до 700МБ\с без проседаний.

при заполняемости >75% ?

Диски по 8ТБ, всего 330ТБ полезного. Больше на хранилке пока никого нету (потребителей)

Да, но там по сути 10 ВМ по 30ТБ и каждая пишет по 60-70МБ\с крупным блоком. И прокинута она через вмваре, а не напрямую. Там вплоть до 100% нет падения производительности.

Какие диски ты так и не ответил.

Что ты имеешь в виду какие диски? nl-sas, 8TB… Какая инфа еще может быть? Ну могу сказать что не подерживающие аппаратное шифрование, то есть обычные

Полное название модели диска. Например Жесткий диск IBM 1TB HS 7.2K 6G NL SAS LFF HDD [42D0777] модель диска конкретную. NL SAS это не модель, а отличие от обычных дисков.

Диски по 8ТБ, всего 330ТБ полезного. Больше на хранилке пока никого нету (потребителей)

Модель дисков-то какая?

На второй такие-же?

Да, но там

там - это на второй? Там тоже DDP?

по сути 10 ВМ по 30ТБ и каждая пишет по 60-70МБ\с крупным блоком. >И прокинута она через вмваре, а не напрямую.

т.е. на второй гипевизор ESXi?

Там вплоть до 100% нет падения производительности.

до 100% объема?

Чекните UniManager-ом event-log. Может там policy нарулены

ФС, основанные на allocation-группах, не рекомендуется забивать больше, чем на 80%. После этого начинает тратится много времени на поиск подходящей allocation-группы.

Кстати, RedHat не сертифицирует ext4 размером более 50TB. Попробуй XFS, там сертифицирванный объем 500TB.

Коллеги, я извиняюсь, но неужели тут есть люди, которые основываясь на модели дисков во внешнем СХД могут сказать, что из-за них проблемы? Нет, мне не проблема скинуть инфу - просто я потерялся, к чему она нужна. Capacity (TiB):7.14 Speed (RPM):7200 Current data rate:12 Gb/s Drive block size:512 Logical sector size (bytes):512 Physical sector size (bytes):4096 Product ID:HUS728T8TAL5204 Manufacturer:HGST

Давайте я наверное пояснение дам - под падением производительности дисков - я имел в виду дисковую подсистему в линуксе. Саму СХД проверили, её показатели идеальные.

По наруленному\накрученному - всё по дефолту. По сути чистая убунта. Установлен пцс, поднят кластер, добавлены ресурсы. Никакого вмешательства в настройки чего-либо не было, даже ФС маунтится без опций. Сразу скажу (-noatime и подобное эффекта не принесло)

Про другую СХД я упомянул для сравнения, что в железо мы не упираемся точно. Сами сервисы в разных цодах. Конфиги СХД одинаковые, разве что инициаторы в одном случае линукс-дм, а в другом esxi. Диск на 100ТБ через esxi не прокинуть, только если бить на кусочки + это не подойдет для организации кластера.

Спасибо за инфу, очень похоже, что он начинает искать куда аллоцировать.

По XFS - стремно. Как понимаете, вместе с записью предполагается время от времени удалять старое и xfs тут такой себе помощник по скорости. Плюс xfs как говорят слабо ремонтнопригоден.

Коллеги, я извиняюсь, но неужели тут есть люди, которые основываясь на модели дисков во внешнем СХД могут сказать, что из-за них проблемы? Нет, мне не проблема скинуть инфу - просто я потерялся, к чему она нужна.

да теперь уже ясно, что там LUN 30% от общего, так что не важно

Давайте я наверное пояснение дам - под падением производительности дисков - я имел в виду дисковую подсистему в линуксе. Саму СХД проверили, её показатели идеальные.

а вот мне, по фотографии, мнится что нетапп режет иопсы по достижении трешолда по объему. Чекните event-log на нетаппе

Есть по ним требование оставлять 10% не размеченным на ДДП, оно соответственно выполнено. По заполненности лунов такого нету точно, да и как я уже писал - на других наших системах таких приколов нету, но профиль и характер нагрузок там отличается.

Судя по ext4_mb_good_group, это оно и есть.

/*
 * This is also called BEFORE we load the buddy bitmap.
 * Returns either 1 or 0 indicating that the group is either suitable
 * for the allocation or not.
 */
static bool ext4_mb_good_group(struct ext4_allocation_context *ac,
				ext4_group_t group, int cr)

Не знаете как победить\обойти? Всё же странно, что подобное происходит, учитывая не сказать чтоб серьёзную нагрузку. Не хочется менять ФС, мы не любители экспериментов на проде :)

Нет, я на проде ФС такого большого размера никогда не использовал. Просто потому, что их нельзя забэкапить/восстановить за приемлемое время.

ну если уверены, что ext4 виновата, можно там debug включить не знаю только стоит ли на проде )

и vmstat поглядеть в динамике в момент инцидента

BTW, 8 RAM выглядят как-то скромно в таком сетапе. Может там kernel internals мнется

Я сказал, что похоже, что есть проблема с аллоцированием, но не уверен точно :)) Спасибо за советы, попробую глянуть.

по 8ГБ RAM - докидывал до 24, ничего не меняется.

как хинт - сделайте еще lun 100T +VM там же и потестируйте чем прод почем зря теребить

PS для начала - тупо dd в девайс, чтобы отбросить сомнения о фс

В btrfs есть b-деревья не только для занятого пространства но и для пустого.

Забивать 100тб файлами размером 120кб это какой то сюр. Вам надо в консерватории что то поправить.