Записки лінуксовода

[bytebuster]

Капець.
В Лінуксовому ядрі, починаючи з 2007 року, сидить бага, яку ніяк не можуть відловити.
Якщо система вижирає усю RAM+swap (або просто RAM, якщо своп вимкнено), все мерзне насмерть. До красної кнопки.
Пісєц же! У вінди навіть приснопам'ятної 95-ї все було нормально. Ну, гальмувало, але ж не висло до фізичного ресету!

Баг від 2007: System freeze on high memory usage
Численні реінкарнації:
2013: System freeze on high memory usage
2015: System freeze/restart on high memory usage
AskUbuntu.SE: Computer freezing on almost full RAM, possibly disk cache problem

Так це ще не все! Виявляється, що воно ще й страждає від фрагментації своп-файлу! Йоханий бабай, а я-то думаю, чому у мене iotop показує 700kb/s швидкості свопа при страшенному шарудінні механічним винтом…
Unix&Linux.SE: How can swapoff be that slow?

Йомайо, як так можна жити?! Ці дєтські болєзні вінда вилікувала ще у минулому тисячолітті, блін! І клава/миша лишалися responsive під час навіть сильного свопу (особливо, якщо UDMA; ну так 21 століття на дворі).

Карочє, я в афігєнії. Як люди з цим живуть?!

Натомість, відкрив для себе zram та irqbalance. Тепер на 8 Гб фізичних до свопу не лізе навіть при використаних 11 Гб. Хоч щось.

Comments

...

[balu]

Відбивати malloc?
Не варіант, оскільки нема можливості нормальної обробки такої ситуації.
Падати аплікаціями?
Якими саме аплікаціями, бо їх може бути тисячі? Я б волів щоб була червона кнопка, замість довільних незрозумілих падінь.

Так, що миша не рухається.
Миша не рухається по тій причіні, що у графічної підсистеми такий же приорітет, що і у іншого користувацького процеса. У мене таке теж буває, як процесор завантажений на 100%. На вінді таке саме. Що на вінді краще - миша менш чутлива до тормозів через роботу з винтом, але описане тобою трапляється під час мережевих затримок.

Лінух такий усічка-пусічка, працює на 512М памʼяті і не страждає.
Дивлячись який лінух. У мене вже давно 16Г стоїть.

...

[bytebuster]

> > Відбивати malloc?
> Не варіант, оскільки нема можливості нормальної обробки такої ситуації.

Неправда. Інше діло, якщо систему написано у 1970-му році і не запилено можливості повернути null. Ну тоді йой. Вінда 1983-го, на 13 років молодша, тому в ній таке буває. :)

> > Падати аплікаціями?
> Якими саме аплікаціями, бо їх може бути тисячі?

Процес отримує malloc()=null, а далі якщо програмер не лінивий, то обробляє, а інакше крашиться по NPE.
Або зробити все так само, як зараз робиться при segfault. До речі, і на цю ситуацію також цілком можна хук повісити.

> Я б волів щоб була червона кнопка, замість довільних незрозумілих падінь.

Окей, червона кнопка + штатний засіб індикації аварійного стану?

> Миша не рухається по тій причіні, що у графічної підсистеми такий же приорітет, що і у іншого користувацького процеса.

Ну канєшно. i7 @8 віртуальних ядер, свопить 2-3 процеси, причому там iowait, а значить cpu idle, а для миші не вистачає процесора. Логічно. :-))

Я у вінди не бачив мерзлої миші з моменту, коли 20 років тому уперше пересів на Dual Pentium Pro.
До речі, ще й досі десь на горищі у Києві валяється Intel PR440FX "Providence": Dual Pentuim Pro, 2 фізичних камня, 4×32 Мб памʼяті 9-бітної з ECC, набортовий Adaptec Ultrawide SCSI + додатковий Adaptec AHA-2940AU і RAID із чотирьох Seagate Barracuda аж по 1 Гб.
Ех… сумую за ним. Скільки зарплат я на нього угрохав, навіть не питайте… :)

...

[balu]

Процес отримує malloc()=null, а далі якщо програмер не лінивий, то обробляє
1) Для корректної обробки вже нема пам'яті, у тебе вона вся вижрана. 0 байтів вільно.
2) Зараз купа програм написана на мовах, що самі керують пам'яттю.

Окей, червона кнопка + штатний засіб індикації аварійного стану?
Гном 2 мені колись щось таке пропонував, коли своп майже закінчився.

...

[bytebuster]

> Для корректної обробки вже нема пам'яті, у тебе вона вся вижрана. 0 байтів вільно.

Не все так погано. Відбито malloc(), це heap. А ще є стек.
Окрім того, з найбільшою ймовірністю відібʼється якийсь великий malloc() або new X(), який тягне всередині багато маленьких mallocʼів.

> Гном 2 мені колись щось таке пропонував,

О, так значить, не все пропало! :)

...

[balu]

В любому випадкові ми впираємось в:
1) вичерпання пам'яті - це аварійна ситуація, яка потребує реакції і від ОС, і від розробника.
2) далеко не всі програми взагалі матимуть змогу цю ситуацію коректно обробити.

Враховуючи те, що така ситуація досить рідкісна, то з цим можна не морочитись і робити більш цікаві задачі.

...

[bytebuster]

Я розумію вашу точку зору, але не можу погодитися з оцим:

> вичерпання пам'яті - це аварійна ситуація

НМД, нестача ресурсу — штатна ситуація, яка виникала регулярно з часів появи обчислювальної техніки. А нестача ресусу-памʼяті, напевно, — найбільш поширена серед усіх нестач будь-яких інших ресурсів.

І вигадувати вигадки, що памʼять дешева — це відображати ситуацію, яка склалася лише в минулі 10 років, на всю історію IT, якій вже бодай 70.

Ізвіняюся, я отримав юзернейм саме за те, що багаторазово переписував цілком кілька-кілобайтні модулі заради економії в кількадесят байт, бо інакше не лізло. :)

...

[balu]

Там, де є нестача якогось ресурсу неодмінно формуються певні практики розробки. Наприклад, в мобайл девелопменті це червоною ниткою проходить через архітектуру програм.
Якщо говорити про проблему обробки раптової нестачі пам'яті, то у юнікс-культурі не сформувалось відповідних практик. Навпаки, з самого моменту появи юніксів широко розповсюдженою практикою було використовувати мови, де програміст не турбувався про керування пам'яттю (дивись Unix Way).

...

[bytebuster]

Напевне, так і є.
Але «програміст не турбувався про керування пам'яттю» — це означає, що він не переймається *моментом* виділення і звільнення ресурсу.
І для того *є* механізми — а саме, ctor/dtor, а також область видимості стекових змінних.

Для файлової системи, відповідно, також є open/close, які можна загорнути в ctor/dtor або в using(){} або lock(){}, і на виході з «{}» відбувається звільнення ресурсу.

Але навіть у цьому випадку, ctor може пофейлитися і повернути null. Як і malloc(). І якщо програміст не обробляє такої ситуації, то винен — криворукий програміст, і не треба звалювати на Unix Way. :-)

...

[balu]

1) Оброби таке на bash-ові
2) Власне ти і підкреслив мою тезу: там, де це є дійсною проблемою, там і обробляється.

...

[bytebuster]

> 1) Оброби таке на bash-ові

З повагою, але — ні.
Ви зараз придумали окремий псевдо-контрприклад, за допомогою якого намагаєтеся спростувати усю ідею.
Баш — не мова програмування. Це високорівнева, скриптова мова. Інтерпретована. Там нема і не може бути управління ресурсами. Взагалі ніякого.

> там, де це є дійсною проблемою, там і обробляється.

Де обробляється?
На сраному 8-бітному Z80, якщо просиш malloc(0xFFFF байт), можна було запросто отримати null.
Я можу налаштувати Пінгвіна так, щоб у простому Ц при виконанні malloc(gigaz warez) я отримував null?

...

[balu]

Баш — не мова програмування. Це високорівнева, скриптова мова.
І що? Це все рівно мова, причому, Тьюрінг-повна. На якій написано тони коду. А те, що воно потребує інтерпретатора не є аргументом.

Де обробляється?
Наприклад, в java я задовбуюсь орбробляти потенційні проблеми з, наприклад, файловою системою. В Python теж автоматично обробляються такі випадки.

...

[balu]

У мене миша не рухалась коли проц на 100% зайнятий розрахунками.

Я у вінди не бачив мерзлої миші з моменту
Не так давно я бачив мерзлу клаву на сімці.