LINUX.ORG.RU

12309?

 ,


0

1

На i5/32gb ram / ssd root при копировании через dd iso-образа дистрибутива на старый usb flash накопитель поймал 12309 - подлагивало курсор мыши, скроллинг в хроме педалил.Как еще можно воспроизвести этот баг, чтобы уже точно? В vmstat wa ~ 60-70 было.

Никаких прочих дисковых операций не было.

★★★★★

Последнее исправление: cetjs2 (всего исправлений: 3)

Как вызвать этот баг — забить всю оперативную память приложениями и начать копирование на флешку или другой съемный носитель.

Но зачем? Чтобы побороть этот баг, надо пересобрать ядро с патчами, тут всё зависит от конкретного компьютера, но для чего его нужно вызывать ещё раз? Даже если во второй раз произойдет настоящий 12309, это не значит, что в первый раз это был он.

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

У меня 27 гб свободной памяти. Нет дисковых операций. В iotop скорость записи была 4 мб/с. И я поймал его :)

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

Мля. У тебя поди dirty.ratio значения большие, только и делов. Это ты думаешь, что ты поймал баг, а на самом деле у тебя просто криво настроена система.

anonymous
()

Бро, бобро бомжаловать в клуб свистетелей ЕГО ЭТ САМОГО!

Да, оно самое.
у меня выскочило при копировании между блинам 2.5" сата.

да, / был на вертексе4, такие дела. [xeon1230/z97/32]

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

Тогда повара Убунты - кривые настройщики системы.
14.04 на тот момент.

что в ней настраивать?
накатил и забыл.
или ты предлагаешь ведро конпелять?

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

Нахрен конпелять ядро не надо. Надо просто подправить ratio кешей в сторону уменьшения, тогда ядро не будет жестоко тупить и попёрдывать от охренения. Алгоритмы рассчитаны на более слабые машины, а подправить сейчас либо тяму не хватает у народа, либо никому это не надо особо.

В кратце, это, конечно, похоже на 12309, но по факту трабла возникает из-за слишком больших кэшей, которые система просто начинает сбрасывать на медленное устройство и тупит. Пользуйтесь sysctl. Вообще на 27 игах оперативки 10% dirty data (пусть даже и от кол-ва общей свободной памяти) как-то овердохера. И вот когда эти 2 гектара начинают сбрасыаться на тупую флэху со скоростью в 10 метров в секунду - наступает оверзвездец, пока не сбросятся. Дело в том, что буфер пытается наполниться быстрее. А из-за особенностей алгоритма система еще и в своп может уйти. Проще всего в такой момент приостановить копирование, дождаться окончания сброса dirty на диск и продолжить операцию, или держать побольше памяти занятой (/me вспоминает сброс кэша в 16 гиг на медленный девайс на большой машинке и нервно хихикает).

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

А ты кукарекал бы еще больше. Эта проблема by design большей частью. И сказанное мной не отрицает того факта, что системе всё равно надо урезать объем dirty на большом количестве ОЗУ.

anonymous
()
Ответ на: комментарий от CHIPOK

Вот анонимус выше описал вроде толково появление сего лаго-глюка.
Но и от нтфс никуда не убежать. Даже если венды нет, то ФС вполне может быть нужна.

Deleted
()
Ответ на: комментарий от CHIPOK

насколько статья релевантна?
прошло уже 5 лет с момента публикации 1апр2011.

т.е. кто-то же должен был запостить репорт по профилю.

Deleted
()
Ответ на: комментарий от slaykovsky

Правда штоле?

# cat /proc/cmdline
BOOT_IMAGE=../vmlinuz-4.5-x86_64 root=/dev/sda2 rootflags=subvol=root/manjaro-embryo,compress=lzo rw scsi_mod.use_blk_mq=1 zswap.enabled=1 quiet nosplash initrd=../initramfs-4.5-x86_64.img
Deleted
()

спуфинг-моде:

хипстота, понакупает ядер с гектарами, а потом плачется... со своими кремний-проблемами.

мониторы, мониторы покупать надо!!!

Deleted
()
Ответ на: комментарий от anonymous

То, что там написали - моим словам никак не противоречит на данный момент. В новых ядрах фиксится.

anonymous
()
Ответ на: комментарий от Deleted

Если у тебя _очень_ медленные устройства - тебе поможет только специальный патч. Есть в составе pf. Можешь еще увеличить таймауты сброса грязных данных на диск. Чтобы одновременно писалось только в один поток. Тогда увеличивай dirty ratio. Проблема заключается в том, что устройство, на которое идёт запись получает тонну одновременных запросов, а ядро тупит из-за особенностей этого алгоритма. Всё, что можно сделать - наложить патч соответствующий или попытаться минимизировать проблему за счет установки адекватных параметров через sysctl.

anonymous
()
Ответ на: комментарий от Deleted

zswap.enabled=1

Поражаюсь. А эта дрянь может и еще больше усугубить баг (почему - предлагаю догадаться самому). Ну так, к сведению. Кроме того, смысл в ней вообще сомнителен без большого кол-ва RAM (от 8 Гб и выше). То же относится и к zram.

anonymous
()
Ответ на: комментарий от Deleted

У меня даже при активной работе с ssd фризы начинаются.

И будут, пока noop вместо планировщика не поставишь.

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

Ставил, только ещё хуже было. Сейчас вообще без планировщика. Стало получше, но всё равно.

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

Ставил, только ещё хуже было. Сейчас вообще без планировщика. Стало получше, но всё равно.

Вообще-то noop - это и есть отсутствие планировщика. Скорее, у тебя SSD работает с особенностями и жёстко снижает скорость записи время от время от времени. Тогда интересны юзкейсы.

anonymous
()
Ответ на: комментарий от Deleted

Может. Это еще один буфер в ОЗУ. С которыми у линуха и так не очень в отдельные моменты времени. Понимаешь, проблема в ядре, которое не умеет нормально приоритеты сброса на блочное устройство. Можешь ядрышко и посвежее собрать, скажем так.

it basically won't start before the buffered writeback is done

Собственно, запись в своп - тоже еще один поток, если у тебя пространство в оперативке под zswap закончилось - лови 12309.

anonymous
()

сушайте, я тут уже проникся идеей быстрофикса.

втулить 2 планки по 4ГБ и все само собой заработает.

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

Если у него проседает скорость записи перед скоростью чтения (а такое возможно, когда trim еще не успел отработать, а запись идёт в блоки, которые нужно очистить - SSD вместо операции записи выполняет чтение -> стирание -> запись), тогда при переполнении буферов происходит как раз оно же самое. Ну и плюс ко всему, запись в общем-то медленнее. Можно вместо ratio (оно, кстати, считается не от объема всей памяти) установить вменяемое vm.dirty_background_bytes = 0 - ну, метров 100 скажем.Тогда тупить будет много меньше, т.к. writeback будет завершаться до того, как система словит тупняк.

anonymous
()
Ответ на: комментарий от Deleted

Чем больше оперативки - тем больше вероятности словить эту хрень.

anonymous
()
Ответ на: комментарий от post-factum

Да-да. Вот именно об этом я и говорю.

anonymous
()

Добавлю:

я писал с помощью dd — т.е. никаких фс не использовал на накопителе:

dd if=myiso.iso of=/dev/sdX
int13h ★★★★★
() автор топика
Ответ на: комментарий от int13h

Это не на уровне ФС баг. Совсем не на уровне ФС. Можешь глядеть atop к примеру, в этот момент и увидеть, после какого момента у тебя dirty data достигает максимального значения и запись начинает идти не в один поток, а в несколько.

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

Можно vm.dirty_background сделать _больше чем vm.dirty - это решает проблему несколько другим способом.

anonymous
()
Ответ на: комментарий от Deleted

Неа, он как zram работает, только менее костыльно и с испралением недочётов.

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

Позже сниму скринкаст с поведением системы при копировании большого файла с HDD на SSD и обратно.

Deleted
()

Странно, проблем на рабочей машине не обнаружил

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

с HDD на SSD и обратно.

А еще cat /proc/meminfo sysctl -a | grep swap sysctl -a | grep dirty

и размер копируемых файлов.

В любом случае, пища к размышлению здесь: https://lwn.net/Articles/682582/

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.