Потребление памяти Kubuntu 16.04.1 - кому верить ? [Решено]
AlexBezz - 12 Сентябрь, 2016 - 16:21
Приветствую форумчане !
Вот такой вопрос на ваше рассмотрение. Установил виджет "Просмотр нагрузки на систему", и обнаружил, что согласно его показателям вся опертивная память загружена по самое нехочу. Но система то не тормозит, своп не наполняется. Открыл монитор системы - а согласно его показателям, свободно больше половины ОЗУ.
Ничего не понимаю ? Кому верить ? Сколько реально потребляется памяти в момент зафиксированый скрином ?
Или виджет показывает то что не показывает монитор системы ?
Растолкуйте плз.
free -mНеплохо бы посмотреть
topcat /proc/meminfoв виджете используется значение всей памяти, включая буфера и кеши.
в проге - только занятой. Буфера и кеш не включаются, ибо их может система при необходимости освободить. (правда, не всегда у нее это получается...)
Вижу, что таки виджет учитывает буфера и кеши
Спасибо.
Завсегда пожалуйста. :-)
Кстати я, например не совсем понимаю, как правильно, ибо с точки зрения системы - эта память все же занята, хотя и может быть освобождена.
У меня лично нет ответа на вопрос - как правильно показывать занятую память.
Это два правильных варианта. Просто первый - правильный для пользователя, ему показывают память занятую самими программами и системой (в т.ч. системными процессами), но за вычетом кеша и буферов, которые используются для ускорения работы приложений.
И второй вариант - правильный для админов, где полностью расписано как и чем занята память.
Я присмотрелся - на виджете столбик состоит из двух цветов, один на пол-оттенка светлее. Выходит, что тот который темнее - соответствует первому варианту, а свелее - показывает буфера и кеш
Оба варианта - неточные =)
Ибо ни один из них не ответит на вопрос типа: "сможет ли ОС выдать 1Гб приложению при free - в 2Гб?"
Гмм, а что именно может на этот вопрос ответить?:-)
Я не спрашиваю кто, я спрашиваю что?
Ядро может =) Только оно может в конкретный момент времени точно "знать" состояние кучи (heap), насколько она фрагментирована и т.д. А отвечает оно когда "просят" сишные *alloc(), new, placement new и т.д.
Я всего лишь хотел сказать, что наличие достаточного количества свободных физических ячеек еще не означает, что оно может быть выдано (без особых проблем или вообще) какому-нибудь приложению, например, когда требуется непрерывная область.
гмм, а есть способ спросить у ядра эту возможность?:-)
Раз уж ты у нас такой знаток в этом вопросе...:-)
Я же писал выше:
Бессмысленно использовать данные системные вызовы просто для получения данных визуально, поскольку состояние может меняться тысячи раз за секунду и выведенные значения будут неактуальными уже в момент отображения.
Поэтому ответ на данный вопрос необходим в момент попытки выделения памяти. Вот на примере malloc.
Начинающие разработчики часто не проверяют успешность выделения памяти и очень сильно удивляются, поймав краш. Аналогичное может произойти с пользователем, когда free показывает достаточное свободное количество, а запускаемая софтина падает или не работает как положено.
Насколько я знаю, с современным ядром malloc выделяет память, даже когда свободной совсем нет, и проверка указателя ничего не даёт. Если же указатель нулевой, значит, системе настолько плохо, что краш программы уже не будет иметь никакого значения.
Думаю, для вас не составит труда проверить (и, возможно, опровергнуть) первое утверждение.
Да, если включен memory overcommit (задается в /proc/sys/vm/overcommit_memory), то так и будет происходить. Правда, в ряде случаев, отъем у разработчика средств контроля вносит еще большую неразбериху и бывает нужен тюнинг или отключение, например.
В ядре вообще касаемо памяти, как я понял, очень много всяких читов и костылей. Но и свобода выбора по их настройке.
Возвращаясь к начальной теме, например, при виртуальном адресном пространстве вообще нет никакой гарантии, что выделение произойдет в RAM, а не в свопе.
Тем не менее, проверки указателей еще актуальны. В том числе на встраиваемых системах, использующих ядро Linux, а также на Android и iOS, с приложений для которых я каждый день вижу отчеты по крашам и 90% из них - по памяти. Свои недоработки и лишние манипуляции с кучей еще команда поправить может, но вот если проприетарная сторонняя библиотека или SDK - остается только вздохнуть.
Отправить комментарий