Выделение памяти (общиий вопрос (не С ;)))

[LMZ]

Привет всем!

занимаясь численными метода, столкнулся с проблемой выделением всей доступной вообще памяти. Как я понял, когда процесс ужирает "слишком много" OOM Killer его прибивает. Прочитав этот пост: http://linux-mm.org/OOM_Killer , оом_киллер теперь не убивает мою программу а Terminal (который этот процесс и породил). Подскажите что делать!!! горю!

[/dev/random]

Привет всем!

занимаясь численными метода, столкнулся с проблемой выделением всей доступной вообще памяти. Как я понял, когда процесс ужирает "слишком много" OOM Killer его прибивает. Прочитав этот пост: http://linux-mm.org/OOM_Killer , оом_киллер теперь не убивает мою программу а Terminal (который этот процесс и породил). Подскажите что делать!!! горю!

А что нужно-то? Чтобы OOM Killer вообще ничего не убивал? Так это невозможно. Когда кончается память, её нужно немедленно освободить любыми средствами, иначе рухнет вся система. Этим OOM Killer и занимается. Единственная возможность этого избежать - переписать программу так, чтобы она бережнее расходовала память. Либо купить ещё памяти. Других вариантов нет.

[LMZ]

нужно что-бы оомкиллер не убивал только запущенную программу (конкретную). Я так понимаю что как память (когда заканчивается физическая) используется свап?

ЗЫ: не жгите на костре, а если попробовать в венде запустить, что с ней будет (программа полностью переносимая)?!

[/dev/random]

Я так понимаю что как память (когда заканчивается физическая) используется свап?

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

[v04bvs]

http://www.redhat.com/docs/manuals/enterpr...roc-sys-vm.html

Про overcommit_memory почитайте, вроде то, что надо.

[LMZ]

извините за большую паузу, собирался с мыслями.
А понадобилась столько памяти для решения задачи типа Пуассона, методом конечных разностей. Там внутренняя решётка (без начальных и граничных) получилась, например 38х38х38, то есть, матрица линейных уравнений (38х38х38)^2, да это ещё на 80 бит (тип real в языке D). Вот и считайте:
((38х38х38)^2)*80/(8*1024^2) == 28714.5 метра... вроде всё правильно...

[Galaxy Master]

28714.5 метра... вроде всё правильно...

все не правильно!

и не правильно одно из двух: или совершенствуйте свою мат.модель под имеющееся железо или покупайте соответствующее железо с десятками гигов, если уверены, что ваш метод расчетов единственно-верный на земле.

и не морочьте себе голову как из 1-4Гб ОЗУ сшить 28Гб ОЗУ.

[/dev/random]

Кстати, я где-то сталкивался с программой решения гигантских СЛАУ, расходующей очень мало памяти. Сейчас я её вспомнить не могу, но, возможно, поможет гугл. Там весь фокус в том, что функция, генерирующая матрицу (задающаяся пользователем), не сохраняет найденные элементы в память, а сразу предает функции, решающей её, причём в специальном порядке (по запросу: сказали выдать элемент ij, она его выдала), а та хранит в памяти лишь минимум данных, при необходимости запрашивая их у генератора повторно.

[LMZ]

посоветовали смотреть в сторону методов решения СЛАУ для разряженных матриц (sparse matrix). Если у кого то есть литература или опыт - делитесь товарищи!

[Serg79]

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