Прожорливый Arch

xfilx
где-то на сайте арча было что-то в духе: "простаивающая память - потерянная память". Может быть поэтому процессы и стараются захавать побольше для более эффективной работы) я бы проверял использование памяти на одинаковых конфигурациях

вот если у меня допустим minecraft-у требуется 1,7 из моих 2 (при включении всяких модов и высоких настройках) гигабайта памяти то "простаивающая память" - не "потерянная память" а та память которая будет сейчас заполнена. И мне не нужно чтоб какие либо приложения кушали больше чем им надо. в итоге игра пытаясь скушать памяти для себя начинает её кушать быстрее чем приложения ей освобождают и всё сразу начинает свопится, в результате чего запуск может продлится очень долго а то и вообще случится вылет.
Вообще-то есть в этом вопросе какая-то недосказанность. Вот сейчас посмотрел... Комп на работе, дефолтное ядро i686, памяти 3.2Г видно, из них (не считая буферов) занято более 1Г.
Обычный десктопный комп, иксы запущены при помощи xdm-archlinux, раб. стол XFCE, Firefox с тремя вкладками - почта gmail, и две с этого форума. Терминал и Tux Commander тоже просто запущены только что и бездействуют для референса.
Firefox - 418 Mb, xfce terminal - 42 Mb!! xfce4-xkb-plugin - 35 Mb, микшер - 43 Mb и так далее. Это жесть какая-то... Всё, что запущено в иксах, жрёт десятки мегабайт! Насколько я понимаю, любая программа потребляет столько памяти, сколько необходимо для её алгоритмов и данных. О какой такой эффективности системы может идти речь, если реально программы занимают столько памяти? Она ведь потребоваться может тому, кому реально надо. Придётся высвобождать, перемещать, двигать - что с учётом объёма, не очень-то и быстро. Всё же не понимаю, как так можно было написать программу терминала, что она в пустом виде занимает в памяти 42 мегабайта?! Или какого-то плагина для переключения раскладок...
А в других дистрах те же проги так же расточительны в плане памяти?
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
nafanja
А в других дистрах те же проги так же расточительны в плане памяти?
У меня нет других дистров. Хорошо бы спросить их владельцев. Зайти, например, к убунтоводам или ещё куда, и спросить с пристрастием.
В гугле читал, что может быть неточность отображения потребления памяти программами типа htop, смысл которого в том, что общие библиотеки по нескольку раз используются в этих подсчётах. Но если бы это было так, тогда бы общий объём не складывался арифметически из суммы потреблений, да и память бы так быстро не заканчивалась. Либо... ну это какой-то совсем суровый баг. Даже страшно подумать...
На самом деле не стоит считать разработчиков ядра дураками. Все не так просто, как кажется, и в то же время, не так все плохо, как выглядит. Сразу приведу пример: у меня, судя по показаниям ps или htop, firefox с некоторым количеством открытых вкладок, занимает 957М при общей физической памяти 2G. То есть, можно сказать - половину всей памяти или ~1G. Попробуйте скопировать файл 1G на диск. У меня это получилось так:
$ dd if=/dev/zero of=test.1G bs=4M count=258
258+0 записей получено
258+0 записей отправлено
 скопировано 1082130432 байта (1,1 GB), 9,26589 c, 117 MB/c
Почти 10 секунд.
Запускаю виртуальную машину на qemu - в процессах занимает 1324М. Притом, что общая используемая (used) память до и после осталась 1.9G. По прямолинейной логике 957*1024+1355808=2335776 - явно превышает мою физическую память, следовательно, кто-то должен слиться в swap. Обе программы не могут одновременно находиться в памяти. И, к тому же, при запуске qemu я должен не менее 10 секунд ждать, пока firefox сольется в своп на диск.
Ничего этого не происходит. Обе программы спокойно себе висят в памяти и я свободно могу обращаться и к той, и к другой. И без ожидаемых тормозов.
А все потому, что в линуксе используется "оптимистический" метод выделения памяти. Операционная система по запросу программы (malloc) не проверяет, сколько памяти есть в данный момент в наличии, а просто помечает у себя в блокнотике и говорит программе "ОК".
А той самой программе может и в жизни не понадобится вся заказанная память. А если вдруг понадобится, операционная система берет на себя обязательство с этим разобраться своими методами. В том числе, если понадобится, и свопнуть кого-то, и кильнуть.
В общем, не надо брать в голову, сколько кто памяти пытается хапнуть. Задумываться надо только тогда, когда действительно начнутся тормоза и отклик системы станет недопустимо низок. А в остальных случаях - это все онанизм.
kurych
На самом деле не стоит считать разработчиков ядра дураками.
Запускаю виртуальную машину на qemu - в процессах занимает 1324М. Притом, что общая используемая (used) память до и после осталась 1.9G. По прямолинейной логике 957*1024+1355808=2335776 - явно превышает мою физическую память, следовательно, кто-то должен слиться в swap. Обе программы не могут одновременно находиться в памяти. И, к тому же, при запуске qemu я должен не менее 10 секунд ждать, пока firefox сольется в своп на диск.
Ничего этого не происходит. Обе программы спокойно себе висят в памяти и я свободно могу обращаться и к той, и к другой. И без ожидаемых тормозов.
А все потому, что в линуксе используется "оптимистический" метод выделения памяти. Операционная система по запросу программы (malloc) не проверяет, сколько памяти есть в данный момент в наличии, а просто помечает у себя в блокнотике и говорит программе "ОК".
Никто никого дураками не считает. Просто хочется разобраться.
То есть, выходит так, что одновременно в top, например, присутствует и firefox на 900М, и qemu на 1.3Г+ при общем объёме 2Г? Всё-таки, складывая память каждой программы, мы выходим за пределы доступной оперативки, или нет? Если нет, то всё честно. Просто, приложения, не будем стесняться этого, тупо жрут немерянно память. Вот я сейчас запустил firefox и пишу каммент, а он (firefox) сразу сидит в памяти на все 400+Мб. И неважно, медленно ли, быстро он пойдёт в своп, но пойдёт в полном объёме, и когда своп закончится, как полагается будут убиты иксы со всей непосильно нажитой работой за день без малейшего предупреждения. И не в свопе дело, у меня, например, свопа нет совсем, просто почему-то слишком быстро расходуется память там, где казалось бы и не должна. Я не знаю как можно написать плагин переключения раскладок, чтоб он занимал 35 Мб, а простейший звуковой микшер с убогими ползунками - 43 Мб. Наверняка тут что-то не так, ну не могли разработчики так облажаться, я в это не верю. Либо top что-то не то показывает, либо всё это хозяйство как-то не так запускается, "прихватывая" лишнего.

Насчёт тормозов... Я порылся в гугле по сабжу, и видел много аналогичных обсуждений, где народ не просто "размышляет на тему", но конкретно испытывает эти самые пресловутые тормоза. Испытывает в полном объёме, несмотря на очень замечательный и умный malloc и почти совершенный диспетчер памяти. Вот в чём дело... Вплоть до того, что человек не мог на 1Г памяти запустить firefox с оффисом плюс что-то ещё по мелочи. Это не нормально, я считаю...
alexdsp, вот честно, никак не могу понять для чего вы все это пишите. Свалили в кучу проблемы отдельной программы, неизвестного пользователя (с неизвестной ОС), вообще потребление памяти и много еще чего. Если вы видите, что какая-то программа заимела непомерный аппетит - что мешает найти более легковесный аналог? Кто мешает вам использовать своп и, при этом, настроить под свои нужды vm.swappiness? Вообще не понятно - вы просто рассуждаете или пытаетесь найти решение проблемы.
vadik
alexdsp, вот честно, никак не могу понять для чего вы все это пишите. Свалили в кучу проблемы отдельной программы, неизвестного пользователя (с неизвестной ОС), вообще потребление памяти и много еще чего. Если вы видите, что какая-то программа заимела непомерный аппетит - что мешает найти более легковесный аналог? Кто мешает вам использовать своп и, при этом, настроить под свои нужды vm.swappiness? Вообще не понятно - вы просто рассуждаете или пытаетесь найти решение проблемы.
Я пишу это для того, чтобы те, кто может найти решение проблемы, возможно, начали бы его искать.
Хотя в общем-то и дальше можно жить, я с вами согласен. Надо просто смириться с некоторыми вещами, представить, что всё хорошо. Не так ли?
Про своп и своппинесс - не смешно... ну совершенно. В духе канонического - "Новая ОС тормозит? Не заморачивайся! Просто купи новый комп!" Или вы считаете, что настроив своп, можно решить проблему расхода памяти? (Если не понятно о чём писал ТС, я повторю - именно об этом. О повышенном расходе памяти.) Неужели после настройки свопа переключатель раскладок сразу как-то магическим образом умерит свои аппетиты?
Царь
Да ты, я вижу, холоп, не уймешься! (С)
(ничего личного ;-) )
Нет никакой проблемы. Только надуманные и высосанные из пальца. Линукс прекрасно работает на самом разношерстном железе: от hi-end серверов до нетбуков и планшетников. И везде справляется с задачами. А те случаи ужасной работы и тормозов, которыми, по Вашей информации, кишит гугл - частные случаи, с которыми и надо разбираться отдельно. Часто - это просто глючное железо, или вася пупкин решил решил стать оверклокером, прочитав одну статейку в журнале "Какер".
Вот если Вы скажете, что на данном конкретном железе и в данной конфигурации софта имеете перманентные проблемы с памятью и лагами системы - то есть смысл разбираться, кто в этом виноват и как этого избежать. Может и железо глючить, может и софт.
А вот так умозрительно клеймить все подряд - это нелепо.
И да, то, что показывает htop, free и т.п. не всегда отвечает реальному состоянию памяти. Я уже показывал на примере, как две программы, которые явно не могут уместиться в памяти, спокойно там себе сосуществуют.
И вот еще пример: запустите htop. Полоска памяти двухцветная. Зеленая часть - достаточно маленькая, по идее это та часть памяти, которая реально задействована в работающих процессах и программах. Остальная часть - кэш. Он без потерь может быть освобожден в любое время под любые нужды системы.
UPD: И еще: то, что какой-то элемент управления громкостью может по показаниям приборов жрать много памяти - это скорее всего следствие того, что он использует общие для данной графической среды библиотеки. Вот выделенный для функций и объектов этой библиотеки объем данных добавляется, по всей видимости, к объему памяти всех программ, пользующихся ей.
kurych
И да, то, что показывает htop, free и т.п. не всегда отвечает реальному состоянию памяти.
То есть, получается, что они работают неверно? Поясните пожалуйста. Я всегда считал, что уж эти программы вылизаны достаточно хорошо. Только не надо ещё три раза писать про кэш и буферы. А так, да... линукс прекрасен в каждом байте, и у него нет и никогда не было никаких проблем :) Даже вот этой тоже не было - http://lurkmore.to/12309 и многих других. Беспокоится не о чем.
kurych
И еще: то, что какой-то элемент управления громкостью может по показаниям приборов жрать много памяти - это скорее всего следствие того, что он использует общие для данной графической среды библиотеки. Вот выделенный для функций и объектов этой библиотеки объем данных добавляется, по всей видимости, к объему памяти всех программ, пользующихся ей.
Неужели статическая линковка? Очень хочется верить, что это и есть причина, хотя, наверняка, это не так. Если бы это было так, то объём добавлялся бы к общему общёму занятой памяти всего один раз, а ощущение, что почти всё запущенное в иксах (xfce) имеет некую "прокладку" в 20-30 Мб. Впрочем, без хорошего дебага не разобраться. Пока лишь можно констатировать большой расход памяти и не более того. Топикстартер уже привёл конкретные цифры. Можете, конечно, их просто проигнорировать...
 
Зарегистрироваться или войдите чтобы оставить сообщение.