LINUX.ORG.RU

12309 - продолжаем наблюдения

 , ,


0

2

наблюдение 1 - ядро от постфактума помогло частично
наблюдение 2 - с cfq такого не было. но его выкинули из апстрима
наблюдение 3 - кажется, эта проблема возникла, после того, как подключил жёсткий диск, собственно, поэтому создал тему в /hardware - есть подозрение на кривое железо и херовый южный мост (gigabyte ga-970A-UD3P), который херово обрабатывает несколько сата устройств(после подключения выше опред. числа оных начинает колбасить?). Ещё там пара ссд висят в btrfs-raid1, может южник захлёбывается, хотя не должен на SB950 (6 x SATA 6Gb/s connectors) Самое злобное, что никаких рекомендаций в книжке по материнской плате не даётся, как лучше подключить устройства с raid. то есть тоже пофиг по идее.

Как проявляется?: при высоком io на hdd (например скачивание или обновление игры в стиме на другом HDD) начинает заикаться хром (хотя / и /home юзера на ssd raid). Появляются задержки в серфинге страниц. Южник вроде не перегревается. Совсем не понимаю, на что грешить.

★★★★★

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

Ответ на: комментарий от Eddy_Em

Да, от 12309 только SSD спасает, но поди-ка напасись этих дорогущих игрушек!

Не спасает. Я его лишь на SSD и увидел в первый раз 😀 (причём SSD топовые). Но копирование на USB 2.0 флешку сделало своё дело, что остальное стало тормозить.

fornlr ★★★★★
()
Последнее исправление: fornlr (всего исправлений: 1)
Ответ на: комментарий от anonymous
free -m
              total        used        free      shared  buff/cache   available
Mem:          16075        6136        3871         479        6066        9125
Swap:             0           0           0
darkenshvein ★★★★★
() автор топика
Ответ на: комментарий от fornlr

причём здесь флешка, тоже непонятно.
то есть почему она влияет на операции с / разделом.
кто так талантливо код писал...

darkenshvein ★★★★★
() автор топика
21 апреля 2021 г.

Я сомневаюсь, что 12309 еще остался. Скорей, это — группа дыр в ядре, из-за которой высокая дисковая активность вызывает зависоны компьютера, сколько бы у тебя не было ядер и оперативы. У нас, вон, сервак как-то «зависал», когда я запустил компиляцию в 128 потоков — с полчаса не мог к нему по ssh пробиться.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от slackwarrior

Да легко. Запись на медленное устройство и большой кэш под dirty. Когда он заполняется - получаете состояние гонки. Всё. Нивелировать можно уменшив dirty_bytes до нескольких мегабайт к примеру (у многих там при большом количестве ОЗУ гигабайты - 20% от моей памяти будет около 3 гигабайт). А ядро от постфактума - глючное дерьмище.

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

Копирование на медленное устройство при нехватке памяти. Грязный кэш файлов вытесняет чистый и все, приехали. Само по себе вздутие грязного кэша при копировании вызывает нехватку.

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

Я сомневаюсь, что 12309 еще остался

Воспроизводил с 5.10.

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

Скорей, это — группа дыр в ядре

Первая дыра - хреновая обработка нехватки памяти как таковой: ядро не запрещает вытеснять чистый кэш файлов.

Вторая дыра - огромный dirty_ratio по умолчанию может вызывать нехватку памяти и провоцировать проблему №1.

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

Есть такое. На рабочем компе 32ГБ оперативки, но и то при компилировании чего-либо сверхжирного проявляются признаки 12309. Другое дело, что это уже давно не 12309, ЕМНИП, еще несколько лет назад разрабы ядра уверяли, что избавились от этой проблемы.

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

Запись на медленное устройство

у меня был raid0 на сата ssd тогда
не понтовые ssd, но и не медленные.
я бы сказал, ядро/фс умудряется как то даже немедленные устройства заткнуть до состояния медленных.

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

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

31.07.19
с года два назад.

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

Нет, не все и не пофиксили. Открываются новые способы эксплуатации.

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

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

Релиз ядра Linux 4.10 20.02.2017 07:03

Среди наиболее заметных изменений: решение проблемы с подвисаниями при интенсивном копировании на медленные USB-носители

https://www.opennet.ru/opennews/art.shtml?num=46035

На самом деле часть проблемы решена. С 4.9 при нехватке памяти блокировался своппинг во время копирования.

anonymous
()

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

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

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

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

в 2.6.39 ядре линукса избавились. изя как обычно узнал новое слово и пошёл херню фантазировать

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

на FreeBSD не избавились полностью:

FreeBSD still has support for the Giant mutex,[8]

только

performance-critical core components have long been converted to use finer-grained locking.[1]

в OpenBSD and NetBSD всё ещё не избавились вообще

anonymous
()

яб на старые ядра свалил, но теперь у меня райзен - хрен свалишь

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