ZFS нагрузка на один диск

Demis · Непрочитанное сообщение **Demis** » 2021-07-21 16:22:37

А на сколько заполнен пул в процентах?
(Что-то не увидел этой цифири...)

Хостинг HostFood.ru · **Хостинг HostFood.ru**

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

kharkov_max

+/- 75%

guest · Непрочитанное сообщение **guest** » 2021-07-22 10:32:14

+/- 75%

плюс минус 75% - это как? в смысле ноль?

~75% - неудивительно, примерно с такого %-та загруженности ZFS и начинаются
проблемы.

WD RE GOLD не плохи, но это WD:
- не быстрые
- греются
- после нагрева начинают тормозить
- ну после 6.5 лет на этих дисках, производительность легко может просесть

ps. Были шикарные диски HGST, хороший support, теперь остались только Seagate,
с support'ом от WD только на стенку лезть...

Neus · Непрочитанное сообщение **Neus** » 2021-07-22 13:53:36

Почему были?
HGST сейчас продаются под брендом WD.
Саппорт у них нормальный.
Нам меняли перегретые диски.

guest · Непрочитанное сообщение **guest** » 2021-07-22 19:02:38

Почему были?
HGST сейчас продаются под брендом WD.
Саппорт у них нормальный.

типа, Шкода - принадлежит концерну Фольксваген, но не производит автомобили фольксваген

В сравнении с HGST, саппорт = гавно.

Demis · Непрочитанное сообщение **Demis** » 2021-07-23 23:21:00

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

Примерно по такому пути:
Вынимаем диск 1.
Машину с пулом пускаем в работу.
Пул станет degraded, но жить должен.
Зануляем диск на другой машине (что-то типа gdisk 1 /diskwipe /dod, но это очень долго для 2Т, важно затереть нулями от корки до корки).
Возвращаем диск назад.
Возвращаем в пул.
Ждем ресинка.
По успешному завершении последнего переходим к диску 2.
И так все диски.

Цель этого самострела: данные начнут писаться с самого начала диска и будут идти подряд.
Почти дефрагментация...
Но нужно быть очень уверенным в железе.
Любой чих и данным капут...

guest · Непрочитанное сообщение **guest** » 2021-07-23 23:45:31

данные начнут писаться с самого начала диска и будут идти подряд

серьезно?

Demis · Непрочитанное сообщение **Demis** » 2021-07-24 2:10:52

А что смущает?
Наглядно, хоть и упрощенно, можно увидеть в статье: https://arstechnica.com/information-tec ... rformance/ .
Смотреть раздел "Copy-on-Write semantics" первую картинку в наборе.
Она из четырех частей. Первая анимация это как ведет себя обычная FS, а остальные, интереснее...

kharkov_max

Это временная лечилка, даже если это так...

Demis · Непрочитанное сообщение **Demis** » 2021-07-24 8:48:08

Согласен.
И тогда остается вариант замены всех дисков на бОльшие, скажем 4Т.
Вроде можно сделать по тому-же алгоритму, что я описывал выше, хотя и не только так...

guest · Непрочитанное сообщение **guest** » 2021-07-24 20:48:15

А что смущает?

данные начнут писаться с самого начала диска и будут идти подряд

где такое написано или нарисовано?!

Demis · Непрочитанное сообщение **Demis** » 2021-07-25 11:20:36

Это мои домыслы.

На чем они частично основаны?

Приведу аналогию:
Ванна, когда мы в нее наливаем воду, заполняется постепенно.
Вода не может находиться в середине или сверху.

Диск, когда новый, тоже условно пустой.
Условно потому, что опускаю ту или иную разметку, служебку и т.п.
Остается некое доступное место для записи.

Когда мы вставляем диск в массив, то крайне сомнительно, что инфо пула будет писаться где-то посередине или в конце диска.
CoW для нового диска не может на нем-же сделать свою первую функцию "Copy". Просто нечего копировать, железка еще пустая.
Хотя понятно, что в случае с ZFS "Copy" все-таки отработает, она просто возьмет данные с других дисков пула и запишет их на новый диск.

Конечно возникает вопрос "куда именно" запишет физически?
Ну предположим в середину диска, мол так записаны данные на остальных дисках.
Хм...
Ок, а если диски разного объема?
Ну а новый в четыре раза больше...
Фигня получается.
Хотя с другой стороны мы помним, что новый большой диск сначала не весь используется, а только в пределах пула.
Этот момент говорит в пользу версии, что можно записать в то-же адресное место, что и на старых дисках пула.
Но тянет за собой необходимость отслеживания этой байды на уровне логики кода ZFS.
В принципе возможно, а оно надо?
Большой вопрос.

А также выше написанное объясняет, частично, почему после замены всех дисков по очереди, текущий пул может быть расширен.

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

Если теперь мою мысль разложить по дискам, то:
Ту картинку (вторую) разложить на физические диски, ну например 4 диска.
То просто мысленно добавляем диски ниже.
Схема движения потока останется та-же.
И пофиг пишется в начале или середине, границы потока не изменяются.

Как-то так.

Конечно хотелось-бы более конкрено получить знания как это на самом деле заложено разработчиками.
Но понимания нет.
Вроде где-то проскакивала лекция от Метью Аренса, где он это показывал.
Но подзабыл уже. Нужно пересматривать заново.

Demis · Непрочитанное сообщение **Demis** » 2021-07-25 15:23:42

Думаю нашел одно из таких видео by Matt Ahrens, наслаждайтесь :
https://www.youtube.com/watch?v=Njt82e_3qVo
Лучше пересмотреть несколько раз.
Опять-же там, для моего понимания, далеко не все, что хочется знать.
И опять-же нужно не забывать учитывать версию исходного софта на FreeBSD.
Пересмотрев, пришла в голову мысль, добавить ТС еще один диск в систему (только не SMR !!!).

kharkov_max

Эпопея продолжается, есть подобный диск, буду менять ...

kharkov_max

О как интересно.
Утром перегрузил сервер и после ребута нагрузка на все диски +/- одинаковая и этот проблемный диск ведет себя нормально, целый день - нет проблем ...
Буду дальше наблюдать ...

Neus · Непрочитанное сообщение **Neus** » 2021-09-03 22:34:28

kharkov_max

Чем дальше, тем интереснее.

Перегружаю сервер, опять нагрузка на диск 100%, бекап вместо 1:45 делается более 6 часов.
Перегружаю еще раз, диск в норме все летает ...
Между ребутами минимум времени.
Т.е. сервер работал сутки, перегружаю - нагрузка 100%, сразу захожу вижу что 100%, пускаю в повторный ребут и все норм.

Пока статистика через ребут ))))

Demis · Непрочитанное сообщение **Demis** » 2021-09-20 19:17:24

А не запускает-ли Ваш адаптер "само-сканер" поверхности диска???
Выставляется прямо в биосе адаптера дисков.
Бывает можно достучаться и из системы:

Код: Выделить всё

mfiutil show patrol
Operation Mode: disabled
Runs Completed: 213
Current State: stopped

run: mfiutil volume progress mfid0
No activity in progress for volume mfid0.
run: mfiutil volume progress mfid1
No activity in progress for volume mfid1.
run: mfiutil volume progress mfid2
No activity in progress for volume mfid2.
run: mfiutil volume progress mfid3
No activity in progress for volume mfid3.
run: mfiutil volume progress mfid4
No activity in progress for volume mfid4.
run: mfiutil volume progress mfid5
No activity in progress for volume mfid5.
run: mfiutil volume progress mfid6
No activity in progress for volume mfid6.

guest · Непрочитанное сообщение **guest** » 2021-09-21 16:55:54

А не запускает-ли Ваш адаптер "само-сканер" поверхности диска???

это зависит от модели диска, не на всех есть, а если есть не на всех отключается

kharkov_max

В общем обновился до 13/Release, проблема исчезла, более недели полет нормальный, нагрузка на диск который уходил в 100% такая же как и на остальные, zpool работает быстро, бекапы летают ...
Может обновление системы, может обновление софта повлияло на поведение, а может и снижение температуры.
Bios не правил.

kharkov_max

День добрый.
Не хочу создавать новой темы, вопрос пересекается, но уже с с софтом.

Снова обратил внимание что pool как то медленно работает, нагрузка на диски стабильно 30-40%.
Методом отключения сервисов было выявлено что виной подобной нагрузки и как следствие медленной работы по сети является jail с graylog, который лежит на этом пуле.

Т.е. останавливаю jail, pool что то еще делает мин 20, и потом его нагрузка падает до 2-3% и все чудно работает.
К примеру при запущенном graylog, время копирования бекапа в сеть длиться около часа.
При отключеном graylog - менее 15 мин.

С одной стороны да, graylog JVM, тяжелое подкружает проц и диск, по идее так и должно быть но !!!
Запускаю jail в котором включена служба mongod, elasticsearch, а graylog остановлен, нагрузка на диск минимальна - все летает.
Запускаю с включенным graylog, он чекает Shards и нагрузка на диски становиться 30-40%
Далее жду 1-2 часа - ни чего не меняется нагрузка 30-40%
Захожу в клетку и торможу службу graylog жду 1-2 часа и нагрузка не меняется, остается 30-40%

Вот и вопрос, что такого может дубасить elasticsearch при выключенной службе graylog !!!

skeletor

Может быть размер блока, которым пишется на диск. Представьте, данные можно записать блоками по 8К и по 128К. Разница между этими значениями 16 раз. То есть, в 16 раз больше идёт количество обращений к диску.
Можно через dtrace узнать размер блока, которым пишутся данные. Под Solaris есть скрипт, возможно и под FreeBSD тоже будет работать.

forum.lissyara.su