Прожорливый Arch
| nafanja |
|
Темы:
94
Сообщения:
9252
Участник с: 02 июня 2012
заблокирован
|
поддержу alexdsp, Чисто ради интереса зпустил 2 лайф дистра PuppyRus и Knoppix. Так там те же проги на много меньше памяти хавают...
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874 |
| kurych |
|
|
Темы:
0
Сообщения:
1395
Участник с: 06 ноября 2011
|
Да нет, верно они работают. Только интерпретировать их показания надо с учетом (как бы загнуть?) философии управления виртуальной памятью в линуксе. То есть, программа справедливо считает, что для оптимальной работы все ее объекты и данные желательно расположить в непрерывной области оперативной памяти. На основе каких-то своих соображений она запрашивает (с запасом на будущее) у операционной системы некоторое количество памяти. Ядро линукса, в свою очередь самонадеянно говорит: "ок, выделил, как просили",- надеясь на то, что когда придет время - сумеет разобраться с вопросом. (Напоминает наших отечественных недопровайдеров, предлагающих задешево безлимитный трафик на огромной скорости всем подряд). Но реально память не выделена. Она будет выделена только если программа действительно попытается записать туда данные или считать. Это, конечно, грубое приближение. На самом деле там все сложнее и существует далеко не единственный алгоритм управления памятью. И вот пришли к ситуации, когда с точки зрения процесса(программы) он занимает значительный объем оперативки. Это видение процесса отображается напротив имени и id процесса в top(htop). А ядру пофигу, что думает отдельный процесс. Оно сообщает зелененьким цветом, сколько на данный момент выделено на самом деле. Это гораздо меньше, чем если складывать цифры для каждого процесса. Пример: htop показывает (прямо у меня сейчас) firefox - 1167MДумаю, хватит, т.к. уже набрался объем больше, чем в два раза превышающий мои 2 Гига. (в сумме 4235М). Там еще на гиг-полтора наберется по мелочи. При этом, как free, так и htop говорят, что реально используется только ~568M памяти. Это всего четверть моей памяти. И каждый, по-своему, прав. PS: на самом деле, в htop надо еще смотреть на колонки M_RESIDENT и M_SHARE. Это дает более реалистичную оценку используемой процессами памяти. |
| kurych |
|
|
Темы:
0
Сообщения:
1395
Участник с: 06 ноября 2011
|
nafanjaДумаю, можно сравнить содержимое файлов /proc/sys/vm/* арчлинукса и сравниваемых дистрибутивов. Возможно, там что-то в этом направлении подкручено. Не без основания предполагаю, что если в файл /proc/sys/vm/overcommit_memory прописать 2, то расход памяти для процессов сильно уменьшится. |
| honaht |
|
Темы:
5
Сообщения:
266
Участник с: 04 февраля 2011
|
Я просто оставлю это здесь: http://www.welinux.ru/post/2388/
gentoo
|
| alexdsp |
|
|
Темы:
22
Сообщения:
307
Участник с: 07 февраля 2008
|
honahtСпасибо. Очень ценная статья. Действительо, оказывается, что оно просто "так отображается". Вместе со всеми библиотеками... Осталось разобраться, почему в разных дистрибутивах существенно разные числа, хотя ответ наполовину уже получен. |
| kurych |
|
|
Темы:
0
Сообщения:
1395
Участник с: 06 ноября 2011
|
honahtO! То, что надо! (А я в очередной раз убедился, что краткость - не моя сестра ;-)) |
| bobart |
|
|
Темы:
38
Сообщения:
2537
Участник с: 28 ноября 2009
|
kurychПросто добавлю для экспериментаторов: Делаем # sysctl vm.overcommit_memory=2 ... -bash: fork: Cannot allocate memory По-крайней мере, это справедливо для RAM 2Gb и swap 2Gb, только что проверил. Поэтому: # sysctl vm.overcommit_memory=2 # sysctl vm.overcommit_ratio=100 |
| kurych |
|
|
Темы:
0
Сообщения:
1395
Участник с: 06 ноября 2011
|
bobartНемного недопонял вывод, к чему стремились? Что касается эксперимента, то я вчера, пока дискутировал на эту тему, выставил у себя vm.overcommit_memory=2 с дефолтным vm.overcommit_ratio=50. Графическую среду, естественно, перезапустил, что бы оно с новыми параметрами память отжирало. Уже почти сутки - никаких проблем. RAM - 2GБ, swap - 2G, но пока даже не используется |
| bobart |
|
|
Темы:
38
Сообщения:
2537
Участник с: 28 ноября 2009
|
Немного недопонял вывод, к чему стремились?Я тоже не вполне понял, но вроде стремились к сокращению выделения памяти для *процессов. Просто я провёл эксперимент по первому "образцу" и получил "Cannot allocate memory" в баше и граф. окно аналогичного содержания (что-то о невозможности выделения памяти для процесса) при попытке запустить Opera и ещё что-то из графики. Поэтому и привёл, так сказать, более корректный метод насилия над менедж. памяти или как его там. При выполнении без ребута # echo 2 > /proc/sys/vm/overcommit_memory При этом, насколько я понял, 50 - это дефолт для vm.overcommit_ratio, справедливый при vm.overcommit_memory=0 (то есть, всё по дефолту). И что-же выходит, если это так, то при одинаковых параметрах мы с тобой получаем разный результат? Кстати, а каким образом ты присваивал "2-ку" - через # echo 2 > ... или через # sysctl параметр=значение ? |
| kurych |
|
|
Темы:
0
Сообщения:
1395
Участник с: 06 ноября 2011
|
vm.overcommit_ratio=50 - величина по умолчанию. Этот параметр используется только при overcommit_memory=2 (подробности в "man 5 proc"). Я выставлял через "echo 2 >..." Памяти действительно выделяется поменьше. Разные результаты, наверно, потому, что я KDE не использую, а сижу на менее прожорливом Openbox. Думаю, что в случае KDE/Gnome более правильным экспериментом было бы выставить этот параметр при загрузке через /etc/sysctl.conf или /etc/sysctl.d/. Но в любом случае до поднятия графики. Тем не менее, считаю, что этот эксперимент только для того, что бы увидеть, что и арчлинукс может вести себя как все. А в повседневной жизни не вижу смысла ужимать аппетиты программ до тех пор, пока памяти достаточно и не наблюдается конфликтов. Формулу обратной зависимости оптимизации производительности от объема используемой памяти еще никто пока не отменил. |