iostat -dx 1

и секунд 10

т.е. в этот момент из дисков должны бы выжиматься все соки. а по факту хз что происходит

ща посмотрим, выжимаются ли

если нет команды такой - apt-get install sysstat

странно что никакой разницы 😃

Значит быстрее оно не может.. :) отсюда и тормоза при увеличении нагрузки

ща увидим все

т.е. в этот момент из дисков должны бы выжиматься все соки. а по факту хз что происходит

если надо смотреть в динамике, а не усредненное то zpool iostat -v 1

Кстати.. воможно проблему решит sync=disabled в этом случае синхронные запросы, которые в обычном случае вешают IO до момента завершении каждой операции записи, не будут этого делать)) данные на диск будут скидываться сразу огромными пачками. То есть система не будет ждать реального завершения записи данных на диски. Если свет рубанет, ZFS откатит последнюю пачку транзакций.

если нет команды такой - apt-get install sysstat

Это убило сервак. Лоол )

Пришлось ребутнуться

как это могло убить :)

Хз все ио повисло

а...

тогда сам зфс подвис

Даж терминал повис

может там диск стучит, послушай

Не, диски ок.

В атопе видно что нагружаются равномерно

zfs set sync=disabled имя пула.. попробуй, должно полететь

zfs set sync=disabled имя пула.. попробуй, должно полететь

Ну это неправильно

Ну это неправильно

по идее это не правильно только если у тебя кластер со связанными данными. Т.к тогда данные придут в неконсистентное состояние

скорее всего, было примерно следующее.

сначала забился большой файл

потом файл был удалён, и датасет начал освобождаться.

и эта процедура в некоторых случаях при освобождении большого объёма рекордов может подвесить ощутимо всё ио по зфс

zfs set sync=disabled имя пула.. попробуй, должно полететь

хреновая затея для сохранности данных

врут? http://www.oug.org/files/presentations/zfszilsynchronicity.pdf

и эта процедура в некоторых случаях при освобождении большого объёма рекордов может подвесить ощутимо всё ио по зфс

ну я полез смотреть че так всё тормозит. увидел, что пул забит и вспомнил что zfs такоэ не любит.

потом удалил файл, место быстро появилось.

и потом карточный домик начал рушиться, верно?

по скорости

до полнго нуля

и потом карточный домик начал рушиться, верно?

нет

хуже не стало после удаления

хост на мониторинге не стоит?

нет

хуже не стало после удаления

первое время всегда так.

только прокс и атоп из мониторингов )

потом ачинает валиться потихоньку

сейчас тогда надо будет провести такой же второй тест

потом ачинает валиться потихоньку

ну сейчас как итог стало лучше

но не совсем так хорошо, как было раньше

хреновая затея для сохранности данных

https://wiki.freebsd.org/ZFSTuningGuide

а выше написано "Disabling ZIL is not recommended where data consistency is required (such as database servers) but will not result in file system corruption"

сейчас тогда надо будет провести такой же второй тест

так а с sysstat что делать ?

atop,кстати обычно нагрузку не более 30% на диски рисует.

обычно она около 0

короче казалось бы любых ресурсов хватает. процы не загружены на 100%, памяти свободной от кэшей 25%, и диски на пике нагрузки показывали до 32% (хотя наверно при рандомном доступе информация от atop не очень актуальна).

короче казалось бы любых ресурсов хватает. процы не загружены на 100%, памяти свободной от кэшей 25%, и диски на пике нагрузки показывали до 32% (хотя наверно при рандомном доступе информация от atop не очень актуальна).

если вы про 30% вот сдесь - то это дофига как много. И при таких цифрах всегда тормозит

не, я про atop

и это в самом-самом пике нагрузки

сейчас iodelay стал ещё меньше

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

сейчас уже поздно смотреть.

iostat -dx 1

проблема исчезла с перезагрузкой

самое нагруженое что отловилось.

кстати, для zfs желательно hdparm -W 0 делать ?

думаю если сделаю, скорость совсем упадет

а -W это что там?

кеш?

да, дисковый кэш

-W Get/set the IDE/SATA drive´s write-caching feature.

если диск используется полностью, в коде опензфс вроде написано, что автоматом использовать кеш

он его автоматом включает

это я открыл студию в вм 😃

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

они так и останутся, пока не будут заново перелиты

они так и останутся, пока не будут заново перелиты

у меня есть хитрый план 😃

виндовый дефраг

благо он показывает 70% фрагментации из-за маленького размера массива.

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

или нет ?

не факт.

оно так и так из за cow пишется нелинейно и разбрасывается по своим законам

оно так и так из за cow пишется нелинейно и разбрасывается по своим законам

это да. но обычно головам диска нужно лететь ближе, чем в текущей ситуации