LINUX.ORG.RU

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

 


1

6

По мотивам треда про calloc Calloc нынче ни на что не влияет что-ли? Без философий о том, кто ламер, кто не ламер и понимает современные технологии.

Чисто на практике. Хочется, чтобы:

Программа в процессе работы ГАРАНТИРОВАННО не падала от нехватки памяти при ее выделении и ее не прибивал OOM Killer (по крайней мере просто из-за выделения памяти), то есть, если в процессе работы обнаруживается ее нехватка, она могла бы сообщить об этом пользователю. Или хотя бы корректно завершиться, сохранив текущие данные.

Согласитесь, пользователь, которого вся эта философия оверкомитов, страниц памяти и настроек OOM Killer не волнует, вправе ожидать такого корректного для себя поведения программы. Ему просто хочется, например, редактировать видео и если он допустим при этом перебрал с чем-то жрущим память (например, слишком ресурсоемкий фильтр выбрал), получил сообщение об этом и продолжил работу.

Как правильно для этого работать с памятью? Естественно хотелось бы при этом, по-возможности, попроще и поуниверсальнее.

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

rustonelove

★★★★★

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

Программа в процессе работы ГАРАНТИРОВАННО не падала от нехватки памяти при ее выделении

Даже если она не упадёт, то на выдачу сообщения о том, что всё пропало и на сохранение данных тоже может понадобится память. А её уже нет. И это закрывая глаза на раскрутку стека.

настроек OOM Killer не волнует

Как раз его это и не волнует.

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

Откройте пару браузеров с сотней вкладок и пару виртуалок и посмотрите что произойдёт. На любой ОС. А ещё лучше swap отключить перед этим.

RazrFalcon ★★★★★
()

Как правильно для этого работать с памятью? Естественно хотелось бы при этом, по-возможности, попроще и поуниверсальнее.

Перед каждым выделением памяти:

  • спрашивать у системы о её текущем состоянии.
  • помолиться св. Патрику, чтобы это состояние внезапно не изменилось.
ugoday ★★★★★
()

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

Через прыщ на лбу.

anonymous
()

Согласитесь, пользователь, которого вся эта философия оверкомитов, страниц памяти и настроек OOM Killer не волнует, вправе ожидать такого корректного для себя поведения программы.

Выключи оверкоммит и будет как ты хочешь, только мало что работать будет. Второй вариант, для приложения, это использовать свой аллокатор который будет брать память mmap'ами + mlock.

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

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

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

Выключи оверкоммит и будет как ты хочешь, только мало что работать будет. Второй вариант, для приложения, это использовать свой аллокатор который будет брать память mmap'ами + mlock.

Вот тут наверное и притаилось зло. Оверкоммит должен был работать для НОВЫХ функций выделения памяти. А старый malloc честно возвращать null если памяти не хватило.

Второй вариант, для приложения, это использовать свой аллокатор который будет брать память mmap'ами + mlock.

Похоже наиболее реальное для жручего софта. Сразу за mmap-ить большой кусок и вариться в нем.

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

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

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

Даже если она не упадёт, то на выдачу сообщения о том, что всё пропало и на сохранение данных тоже может понадобится память. А её уже нет. И это закрывая глаза на раскрутку стека.

Можно заранее резервировать какой-то буфер для этой цели.

praseodim ★★★★★
() автор топика

Я отвечал на этот вопрос. mmap + map_populate. Если у тебя не хватит памяти - тебе вернётся ошибка из mmap. Ты получаешь поведение идентичное тому, которое хочешь.

Как это делать «поуниверсальнее» - никак, страдать. Хотя что тебе мешает написать пару ифдефов - мне непонятно.

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

Нормально.

Такое можно долго продолжать. А зачем нам кеш, когда любое падение системы/розетки теряет наши данные? Таковы свойства реальности.

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

Вот тут наверное и притаилось зло. Оверкоммит должен был работать для НОВЫХ функций выделения памяти. А старый malloc честно возвращать null если памяти не хватило.

Это никого не волнует по причине того, что маллок никакого отношения ни к системе, ни к памяти - не имеет. Как ты собрался что-то отслеживать?

rustonelove
()

Опять по второму кругу поехали?

Deleted
()

Как правильно для этого работать с памятью?

Т.е. все советы из предыдущей темы ты предпочел проигнорировать? Ясно.

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

Можно заранее резервировать какой-то буфер для этой цели.

Может ты сразу под RTOS начнешь писать тогда?

Большинство библиотек не умеют делать что-то разумное при нехватке памяти. Вон в glib (не путать с glibc) вообще зашиты «гарантированные аллокаторы», которые сразу убивают программу при отсутствии памяти. А поверх glib сидят стопицот библиотек и программ. По сути, весь десктопный линукс и часть серверного.

Тебе такая большая разница, ядро тебя убъет или glib?

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

Тут такое дело. Без телодвижений со своей стороны сложно что-то просить у системы. Может помочь бронь.

Если кратко, то выдели в самом начале работы своей программы достаточно большой кусок памяти. Назовем ее бронью. Потом, если во время основной работы как раз не хватит памяти при попытке выделить ее, то освободи эту бронь. Ну, а дальше по обстоятельствам. Можно попробовать корректно завершить свою программу, если никакой гад не отберет освободившуюся память, т.е. если повезет. Сам понимаешь, недетерминировано и непредсказуемо.

Только этот метод такой. От него такой же осадок остается как от использования electron. Вроде и интересный метод, но что-то здесь не так

З.Ы. первую тему не читал

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

Как и в Qt. Технически, Qt вернёт нулевой объект, но если это не проверить - прога упадёт. Да и не уверен что все Qt классы это проверяют. Знаю только что QImage проверяет результат malloc.

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

Только если вы не используете сторонние либы. Мало ли что они будут делать.

RazrFalcon ★★★★★
()

Редактировать видео как раз самое простое. Как делает фотошоп? В настройках указан размер свопа, его мапим и юзаем этот map в качестве памяти. А что делать...

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

java так работает, забирает при старте сразу 8 гиг памяти, а потом все орут как идиоты «ява жручая». Зато очень большой плюс - она не падает, просто никогда не падает.

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

Зато очень большой плюс - она не падает, просто никогда не падает.

Может вы на ней ничего серьезное не делаете? Вполне себе падает, прикладуха, когда в результате фрагментирования даже уборщик мусора не может склеить память для нового запроса.

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

java так работает, забирает при старте сразу 8 гиг памяти, а потом все орут как идиоты «ява жручая». Зато очень большой плюс - она не падает, просто никогда не падает.

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

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

Может просто писать уметь надо? Или аллокатор памяти в вашей системе отстой. У меня правда не очень большой опыт, но я ни разу не видела, чтобы на виндовс jvm упала.

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

Скорее всего( тут где-то в районе 100% вероятности), это просто побочный эффект. А источником такого поведения является ГЦ.

Зато очень большой плюс - она не падает, просто никогда не падает.

Что не падет? jvm? Она на крестах и такая же обыкновенная программа, как любая другая.

Жава не падает? Падает, только вот jvm ей не даёт упасть. И причина проста - системным процессом является jvm, а не твоя жава-программа. А уже из этого как следствие то, что система не может влиять на твою программу напрямую.

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

Или аллокатор памяти в вашей системе отстой.

Откуда они взялись, если аллокаций нет? Есть одна аллокация хипа. Всё. Да и для внутренних структур у jvm свой аллокатор.

У меня правда не очень большой опыт, но я ни разу не видела, чтобы на виндовс jvm упала.

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

Я то же не видел, чтобы плазма падала, но из этого мало что следует.

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

Хуже и тормазнее параши в этом мире нету

Только она рассчитана на нормальных людей. И в нужный момент скажет русским языком, «в системе не хватает памяти, закройте ненужные приложения». И только я решаю, что мне нужно, а что нет. В отличие от чудаков написавших OOM Killer, который вместо того, чтобы слить в свап самый низкоприоритетный процесс и отдать его память мне, прибивает мое самое ценное приложение. Что разве в юниксе с прошлого века задача распределения памяти не решена? Зачем лезть в хорошо работающие вещи своими кривыми культяпками?

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

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

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

Жава не падает? Падает, только вот jvm ей не даёт упасть.

Царская логика!

На ЛОРе уже столько девочек, а Царь все равно самый тупой.

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

Люди хотят удобства, чтобы если кончилась память, приложение могло грациозно завершиться с сохранением. Но большие дяди давно решили что безопасно универсально так не сделать, поэтому нефиг и пытаться. Пожтому в конкрентых случаях поступают по-разному, например пулят память, пишут свои malloc'и, конфигурят родной malloc, конфигурят overcommit, конфигурят glib (не смотря что это не в духе glib, бла-бла) и делают прочие такие вещи. Иногда им удается достичь нужных целей, иногда - нет. Да, и это сказки, что malloc не может вернуть NULL при включенном overcommit'е, есть вполне валидные случаи, так что проверять это таки надо. Истина как всегда где-то рядом...

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

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

Хотя бы тот, что программы писать только под overcommit=1, который даже не по умолчанию — явная глупость.

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

В стрекозе точно есть, оно мне прибивало системных демонов во время установки кучи пакетов и это на машине с 16 Гб рамы без свопа. На фряхе вроде тоже есть, но я не наблюдал похожего поведения, хотя компиляция по out of memory частенько вылетала.

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

Да нету никаких проблем. Если не заниматься странными вещами, всё как везде. Но так как в Linux можно многое покрутить некоторые крутят, потом удивляются странным вещам. Есть ещё разрабы, которые не доверяют ОС и пытаются выжрать максимально памяти на пулы и пытаются медеджить память самостоятельно. Это оправдано только в сильно особых случаях, когда приложению нужны немеряные объёмы рамы. Так как всё нужно делать руками, а это из юзерспейса часто не очень хорошо получается делать. Костылят юзерспейсных хуки к CMA, или пытаются из юзерспейса бороться с фрагментацией. Это всё хорошо на сервере или специализированном десктопе, где нет других приложений и всё специализировано и заточено. А если запустить 2 таких на обычном десктопе то эффективность решений сводится на нет.

Это всё краевые случаи. Если нет причин самому этого делать, не надо менеджить память руками - ОС справится лучше в 95% случаев. Если есть особые требования - mmap/mmap_populate или преаллоцированные файлы +mmap. Если надо выжрать всю системную память - это уже ближе к embedded, и может эффективнее будет запилить свой аллокатор в ядре.

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

Где вообще можно почитать про местных парней, ху из ху? :)

Почитай про Луговского. Тебе хватит.

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

Только она рассчитана на нормальных людей.

Ты перепутал домохозяек и нормальных людей.

И в нужный момент скажет русским языком, «в системе не хватает памяти, закройте ненужные приложения».

Это невозможно в принципе. В этом ещё одна проблема - откуда у тебя взялись все эти поверья про то, что тебе кто-то что-то скажет?

В отличие от чудаков написавших OOM Killer, который вместо того, чтобы слить в свап самый низкоприоритетный процесс и отдать его память мне, прибивает мое самое ценное приложение.

Вот тут сразу полный пакет. Во-первых, кто тебе сказал, что это так не работает? Своп является такой же памятью, которую, правда, никто не использует. А вот твоя маздайка без него не может.

Во-вторых, откуда у тебя вообще взялся какой-то «низкоприоритетный процесс» - кто ему задавал приоритет? Либастрал? Точно так же, если ты задашь приоритет, то твой процесс никто и никогда не убьёт.

Другое дело, что система встанет раком, если память кончиться, но кого это волнует. Главное не умереть.

Что разве в юниксе с прошлого века задача распределения памяти не решена? Зачем лезть в хорошо работающие вещи своими кривыми культяпками?

Если бы ты сидел на решениях задач из прошлого века - ты бы сидел на калькуляторах под досом.

И кривые культяпки, как и отсутствие хоть какого-то понимания - есть у тебя, а не у них. Если тебе нравиться сидеть в дерьме - сиди. Зачем ты других заставляешь? Вперёд в маздайку - там ты можешь заехать на винфак, встать на табуретку и вещать агитки хоть сутками.

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

Эдик давно пишет из-под анонима, но отлично опознается по стилю. Хз, почему не завел новый аккаунт. Легко обнаруживается по реакции на слова utf8, питон, пхп. На работе делает какие-то вычисления на сишечке и на GPU.

Царя часто банят, он заводит новые аккаунты. Все время обитает в темах про сишечку, вне раздела Development практически незаметен. Легко опознается по ПТУшной лексике.

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

Царская логика!

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

Но я объясню. Дело в том, что у нас сравнивается поведение процесса и некой внутренней логики в рамках этого процесса, которую жабисты называют «исполнением», которого на самом деле нет. И они апеллируют к тому, что «у нас всё по другому», хотя у вас - ничего нет.

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

Подобное ты можешь реализовать где угодно именно поэтому пхп и жвм работает, что она это поведение реализует. И это нет смысла сравнивать с дефолтным поведением процесса.

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

Но когда уровень твоего развития крайне мал, то ты не видишь этих нюансов. Ты как трёхлетний ребёнок, у которого есть «один» и «много».

Хотя я уже не раз рассказывал про механизмы работы подобное мышления. Когда за какими-то понятиями у тебя в черепушке пустота и потолок твоего анализа - это выкат агитки на знакомые ключевые слова, то да. Тут происходит путаница.

«не падает» и «падает» - я идиот и я не могу понять, что это существует в совершенно разных контекстах. Хотя что я амёбе пытаюсь объяснить.

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

Вот это меня всегда удивляло. Я ничего не знаю о теме, ничего не понимаю, не знаю как это работает на других платформах, но мне это не мешает делать заявления вида: «Почему у других все работает нормально?».

Это вся суть пациентов. При этом если бы он не прочитал эту тему - для него бы всё это работало «нормально», как это работает «нормально» для всех остальных.

rustonelove
()

Хочется, чтобы:
Программа в процессе работы ГАРАНТИРОВАННО не падала от нехватки памяти при ее выделении и ее не прибивал OOM Killer

Приложения, которым нужно много быстрой памяти и такие гарантии (в юзерспейсе) могут использовать и используют что-то вроде https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt

Ну, наверное считается, что это нужно далеко не всем, поэтому по дефолту оптимистичное выделение

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

А я и работаю на виндовс, и у меня честное слово все нормально. Про то что в линуксе есть проблемы с распределением памяти узнала 10 минут назад из этого треда. И удивилась как там вообще все работает?

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

А я и работаю на виндовс, и у меня честное слово все нормально.

Бесконечно много таких как ты работают под люнукс/хренинукс и у них то же «всё нормально». Только из этого ничего не следует.

У тебя нормально основано на твоей вере в то, что у тебя всё нормально. А вот есть и такие люди, основания для «нормально» у которых находятся за рамками веры.

В маздае таких почти нет. И ты там редко что-то подобное прочитаешь.

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

Ну прям типичная ситуация, о которой я рассказывал выше.

Если ты не знаешь - есть ли они у тебя, либо нет. Если ты не понимаешь того, что вообще тут обсуждается и что из этого следует. Зачем ты делаешь громкие заявления?

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

Если начнёшь - я тебе накидаю уже более сложных тестов. Всё же очень просто.

Просто пойди и проверь. Это же так просто.

И удивилась как там вообще все работает?

А с чего ты решила, что подобное поведение вообще на тебя как-то влияет? Оно не влияет на 95% и ничего - живут. И так же считаю, что «всё надёжно». В этом и проблема и суть обсуждений. Реальность и хочу/верю редко соотносятся.

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

Ты сможешь на маздае собрать маздайстудией С/С++ и запустить?

rustonelove
()

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

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

И они апеллируют к тому, что «у нас всё по другому», хотя у вас - ничего нет.

Что ты там лепечешь? Про процессы и виртуальные машины и без тебя известно.

Речь о том, что Java — надежная и безопасная технология, в отличие от твоих этюдов из веток и глины.

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

И он работать не будет. Отличный способ. Именно он в прошлую и эту тему обсуждался и назывался ненадёжным, но эксперты продолжают пребывать со своими куллидеями.

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

Что ты там лепечешь? Про процессы и виртуальные машины и без тебя известно.

Опять амёбы пытается ахинею нести. Тебя никто про процессы и виртуальные машины ничего не говорил. Тебе их приводили в примеры и естественно, что примеры должны быть тебе известны. Что же ты такой тупой, а?

Речь о том, что Java — надежная и безопасная технология, в отличие от твоих этюдов из веток и глины.

Опять несёт амёба ахинею. jvm насколько же надёжна, насколько надёжно любой пхп. Насколько надёжны любые этюды «из веток и глины», но ты, либо специально манипулируешь, либо просто невероятно туп и не понимаешь того уровня ахинеи, которую ретранслируешь несёшь.

Кстати, я кажись тебя помню. Ты та амёба, что мне вещала про жвм на жаве, когда я тебя макал в болото? Да ты ещё жив, какая печальная новость.

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

Не, царь — невменяемый клоун, этакий местный Жириновский. А Эдик вполне нормален.

У нормальных парней все в профиле написано. Большая часть остальных — это школота, упражняющаяся в словоблудии.

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

Тебе их приводили в примеры и естественно, что примеры должны быть тебе известны.

Лучше объясни, что такое «жава», и как это она «падает, но на самом деле не падает».

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