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

[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()=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 теж автоматично обробляються такі випадки.