- Используемая память в Linux 32bit и Linux 64bit
- Как узнать, какая установлена оперативная память и сколько слотов RAM занято в Linux
- Как использовать dmidecode для получения информации об установленной в системе оперативной памяти. Что означает вывод dmidecode
- Как с помощью lshw посмотреть информацию об оперативной памяти
- Как правильно посмотреть сколько оперативной памяти потребляет процесс
- Понимание использования памяти в Linux
- Что сообщает ps
- Почему ps «неправильный»
- Просмотр карты памяти процесса
- Что все это значит?
- Так как тогда посчитать, сколько реально памяти занимает процесс в Linux?
- Виртуальная память в Linux не складывается?
Используемая память в Linux 32bit и Linux 64bit
Заметил одну странность. На компе 32гб памяти. Поставил на него 32битный дебиан. По понятным причинам памяти он увидел около 4гб. С помощью top я замерил объям занятой памяти в чистой базовой инсталляции — примерно 30мб.
Далее сношу 32битный дебиан и ставлю 64битный. Отличий в конфигурации нет, всё та-же базовая инсталляция. После установки top показывает что доступно все 32гб памяти. Однако занято уже не 30 а около 140 мегабайт. При этом 32битный udevd хавал 3мб vsz а 64битный аш 20.
Но после первого и второго варианта инсталляции я не устанавливал никакого дополнительного софта да и вообще ничего не менял.
В чём отличия? Почему 64битный линукс жрёт в разы больше памяти чем 32битный? Единственное объяснение которое приходит в голову — процессы видят что памяти чуть больше чем дохрена и не стесняются требовать у системы больший объём.
Почему 64битный линукс жрёт в разы больше памяти чем 32битный?
Единственное объяснение которое приходит в голову — процессы видят что памяти чуть больше чем дохрена и не стесняются требовать у системы больший объём.
Не совсем так. Ядро резервирует больше памяти. Для процессов в пользовательском пространстве разница обычно объясняется принципиальными особенностями архитектуры amd64 (длиной указателя, например).
Почему 64битный линукс жрёт в разы больше памяти чем 32битный?
Обычно 64-разрядный занимает памяти лишь немногим больше, на несколько %, а почему у тебя в разы — ХЗ.
Потому, что ядро и программы видят больше памяти и стремятся её использовать. Многие размеры буферов и пр задаются в %. Проверяется загрузкой с параметром ядра mem=64m.
Проведи ещё один эксперимент. Выдерни часть памяти, оставив 4ГБ, и поставь 64-битный Дебиан.
Почему-то никто не посоветовал поставить ядро с PAE на 32bit дебиан.
1) VSZ — это не занятая память.
2) Free memory — wasted memory. Многие программы в линуксе действительно используют больше памяти при увеличении доступной памяти.
Из 15-и слотов выдернуть, в 16-м оставить?
Там скорее всего 32+32 или 16+16+16+16.
Но ведь 64 бита ставят для использования > 4gb озу. Стоит ли размениваться на какие-то десятки мегабайт при таких обьемах памяти?
Немного больше подробностей о моих экспериментах. Я поставил 64битный дебиан на виртуалку (virtualbox). На виртуалке было 1гб памяти. Далее сделал копию hdd и tar’ом запаковал всё содержимое корневой директории в архив. Этот архив залил в отформатированную файловую систему на мощном компе (с 32гб памяти). Т.е. что на компе, что на виртуалке файловая система была идентична.
А теперь самое интересное. Только что запустил виртуалку, на ней занято 49мб памяти. А на компе по прежнему 147.
В общем думаю моя догадка подтверждается экспериментально. Процессы берут больше памяти когда её много. Как сказал анонимус, в процентах.
Однако: udevd как на виртуалке, так и на компе занимают одинаково 20мб памяти.
Про PAE — спс что напомнил. Буду экспериментировать с 32битным линуксом.
Источник
Как узнать, какая установлена оперативная память и сколько слотов RAM занято в Linux
Если вы хотите добавить память в компьютер или ноутбук либо заменить на более быструю, то нужно знать характеристики оперативной памяти, с которой ваша система может работать. Если вы хотите увеличить количество оперативной памяти, то важно подобрать модуль RAM со схожими характеристиками.
С настольными компьютерами это обычно нетрудно — можно снять крышку и посмотреть, какая модель памяти установлена, а затем поискать её характеристики в Интернете. Но с ноутбуками всё не так — довольно часто предустановленная оперативная память труднодоступна, даже если свободный слот для дополнительной памяти находится под люком быстрого доступа на задней крышке.
Итак, в этой статье мы научимся, как узнать, какая модель оперативной памяти установлена, какие у неё характеристики и сколько слотов занято в Linux. Мы познакомимся с несколькими программами для показа информации об оперативной памяти в Linux.
Если у вас Windows, то аналогичную инструкцию смотрите по ссылке «Как выбрать дополнительную оперативную память». Кстати, эта статья рекомендуется и пользователям Linux, если вы не можете найти в точности такую же модель RAM — в статье даются советы, на какие характеристики оперативной памяти особенно нужно обратить внимание при выборе дополнительных модулей ОЗУ.
Как использовать dmidecode для получения информации об установленной в системе оперативной памяти. Что означает вывод dmidecode
Первая утилита, с которой мы познакомимся, называется dmidecode. Если она отсутствует в вашей системе, то в Debian, Linux Mint, Ubuntu, Kali Linux и их производные программа устанавливается следующим образом:
В Arch Linux, BlackArch и производные утилита устанавливается так:
Для получения более расширенной информации об оперативной памяти запустите команду следующим образом:
Для более сжатой информации, выполните команду:
В этом выводе значение строк следующее:
- Maximum Capacity — максимально поддерживаемое системой количество оперативной памяти
- Number Of Devices — количество устройств, то есть сколько слотов памяти имеется. Будьте осторожны с этими значениями, особенно на ноутбуках, поскольку это значение берётся как количество слотов, которое может поддерживать материнская плата. Но производители могут принять решение, что вместо 4 возможных слотов RAM, они паяют только 2 слота. То есть в реальности слотов может быть меньшше.
- Size — объём оперативной памяти
- Form Factor — тип модуля, например, SODIMM — это оперативная память для ноутбуков (уменьшенный размер)
- Type — тип памяти, например, DDR4
- Speed — скорость, например, 2667 MT/s
- Manufacturer — производитель, например, Samsung
- Part Number — точное название модели оперативной памяти, например, M471A2K43CB1-CTD
- Minimum Voltage — минимальный вольтаж, например, 1.2 V
- Maximum Voltage — максимальный вольтаж, например, 1.2 V
- Configured Voltag — настроенный вольтаж, например, 1.2 V
Как с помощью lshw посмотреть информацию об оперативной памяти
Вторая программа, которая показывает модель оперативной памяти в Linux, это lshw. Если она отсутствует в вашей системе, то в Debian, Linux Mint, Ubuntu, Kali Linux и их производные программа устанавливается следующим образом:
В Arch Linux, BlackArch и производные утилита устанавливается так:
Чтобы показать модель, производителя и характеристики ОЗУ в Linux выполните команду:
Пример вывода информации об ОЗУ:
- size — это общий размер оперативной памяти в системе, либо размер данного модуля
- product — это точная модель ОЗУ, установленной в Linux
- vendor — производитель
- clock — частота
Как можно увидеть, имеется четыре bank (с 0 до 4) — то есть программа показывает, что в системе может быть четыре модуля оперативной памяти. Но на данной модели ноутбука имеется только два слота, следовательно, материнская плата поддерживает 4 слота ОЗУ, а на практике возможно установить только 2.
- description: [empty] означает, что данный слот пустой.
Источник
Как правильно посмотреть сколько оперативной памяти потребляет процесс
В этой заметке мы узнаем, какое значение памяти, используемой процессом, является верным.
Понимание использования памяти в Linux
Эта запись для тех людей, которые когда-либо задавались вопросом: «Почему простой текстовый редактор KDE занимает 25 мегабайт памяти?» Многие люди думают, что многие приложения Linux, особенно программы KDE или Gnome, «раздуты» исключительно на основании того, что сообщают такие инструменты, как ps. Хотя это может быть правдой, а может и нет, в зависимости от программы, в целом это не так — многие программы намного эффективнее с точки зрения памяти, чем кажется.
Что сообщает ps
Инструмент ps может выводить различную информацию о процессе, такую как его идентификатор процесса, текущее состояние выполнения и использование ресурсов. Двумя возможными выходами являются VSZ и RSS, которые обозначают «virtual set size» и «resident set size», которые обычно используются компьютерщиками по всему миру, чтобы увидеть, сколько памяти занимают процессы.
Например, вот результат
для программы Writer из офисного пакета LibreOffice на моем компьютере:
Размер памяти приводится в килобайтах. Согласно ps, Writer имеет виртуальный размер около 12 гигабайт (!) и резидентный размер около 500 мегабайт (оба числа выше указаны в килобайтах). При этом в офисном пакете открыт не очень большой файл, в котором я в данный момент пишу. Похоже, что большинству людей нравится случайным образом выбирать одно из этих числе и использовать его как реальное использование памяти процессом. Я не собираюсь сейчас объяснять разницу между VSZ и RSS, но, разумеется, это неправильный подход; ни одно из чисел не даёт точного представления о том, какова стоимость памяти для работы Writer.
Почему ps «неправильный»
В зависимости от того, как вы на это смотрите, ps не сообщает о реальном использовании памяти процессами. На самом деле он показывает, сколько реальной памяти занял бы каждый процесс, если бы он был единственным запущенным процессом. Конечно, на типичной Linux-машине в любой момент времени выполняется несколько десятков процессов, а это означает, что числа VSZ и RSS, сообщаемые ps, почти определённо «неправильны». Чтобы понять почему, необходимо узнать, как Linux обрабатывает разделяемые библиотеки в программах.
Большинство основных программ в Linux используют общие библиотеки для облегчения определённых функций. Например, программа редактирования текста поставляемых с окружением рабочего стола KDE будет использовать несколько общих библиотек KDE (для обеспечения взаимодействия с другими компонентами KDE), несколько X-библиотек (для отображения изображений, копирования и вставки) и несколько общих системных библиотек (для выполнения основных операций). Многие из этих разделяемых библиотек, особенно часто используемые, такие как libc, используются многими программами, работающими в системе Linux. Благодаря этому совместному использованию Linux может использовать отличный трюк: он загружает одну копию разделяемых библиотек в память и использует эту копию для каждой программы, которая на неё ссылается.
Хорошо это или плохо, но многие инструменты не особо заботятся об этом очень распространённом приёме; они просто сообщают, сколько памяти использует процесс, независимо от того, используется ли эта память совместно с другими процессами. Таким образом, две программы могут использовать большую разделяемую библиотеку, но при этом её размер учитывается в обоих общих показателях использования памяти; библиотека подсчитывается дважды, что может ввести в заблуждение, если вы не знаете, что происходит.
К сожалению, нелегко получить идеальное представление об использовании памяти процессом. Вам нужно не только понять, как на самом деле работает система, но и решить, как вы хотите решать некоторые сложные вопросы. Следует ли учитывать общую библиотеку, которая требуется только для одного процесса, в использовании памяти этим процессом? Если общая библиотека используется моими несколькими процессами, следует ли равномерно распределять её использование памяти между различными процессами или просто игнорировать? Здесь нет жёсткого правила; у вас могут быть разные ответы в зависимости от ситуации, с которой вы столкнулись. Легко понять, почему ps не старается изо всех сил сообщать «правильные» итоги использования памяти, учитывая неоднозначность.
Просмотр карты памяти процесса
Хватит разговоров; давайте посмотрим, как обстоят дела с этим «огромным» процессом Writer. Чтобы увидеть, как выглядит память Writer, воспользуемся программой pmap (с флагом -d после которого идёт PID (идентификатор процесса)):
Я вырезал много вывода; остальное похоже на то, что показано. Даже без полного вывода мы можем увидеть некоторые очень интересные вещи. Важно отметить, что в выводе каждая разделяемая библиотека указана дважды; один раз для сегмента кода и один раз для сегмента данных. Сегменты кода имеют режим «r-x—», в то время как данные установлены на «rw—». Столбцы Kbytes, Mode и Mapping — единственные, о которых мы будем заботиться, так как остальные не важны для обсуждения.
Если вы просмотрите вывод, вы обнаружите, что строки с наибольшим количеством килобайт обычно являются сегментами кода включённых разделяемых библиотек (те, которые начинаются с «lib», являются разделяемыми библиотеками). Что замечательно в этом, так это то, что они могут быть разделены между процессами. Если вы вычлените все части, которые совместно используются процессами, вы получите общее количество «writeable/private», которое отображается в нижней части вывода.
Это то, что можно считать дополнительными затратами этого процесса без учёта разделяемых библиотек. Следовательно, стоимость запуска этого экземпляра Writer (при условии, что все общие библиотеки уже загружены) составляет около 1 гигабайта. Это совсем другая история по сравнению с 12 гигабайтами, о которых сообщила ps.
Что все это значит?
Мораль этой истории заключается в том, что использование памяти процессами в Linux — сложный вопрос; вы не можете просто запустить ps и знать, что происходит. Это особенно верно, когда вы имеете дело с программами, которые создают множество идентичных дочерних процессов, например Apache. ps может сообщить, что каждый процесс Apache использует 10 мегабайт памяти, в то время как на самом деле предельная стоимость каждого процесса Apache составляет 1 мегабайт памяти. Эта информация становится критически важной при настройке параметра Apache MaxClients, который определяет, сколько одновременных запросов может обрабатывать ваш сервер.
Это также показывает, что стоит как можно больше придерживаться программного обеспечения для одного рабочего стола. Если вы запускаете KDE для своего рабочего стола, но в основном используете приложения Gnome, вы платите большую цену за множество избыточных (но разных) разделяемых библиотек. Придерживаясь только приложений KDE или Gnome, насколько это возможно, вы сокращаете общее использование памяти за счёт снижения предельных затрат памяти при запуске новых приложений KDE или Gnome, что позволяет Linux использовать больше памяти для других интересных вещей (например, файловый кэш, который значительно ускоряет доступ к файлам).
Так как тогда посчитать, сколько реально памяти занимает процесс в Linux?
С помощью ps или аналогичных инструментов вы получите только количество страниц памяти, выделенных этим процессом. Это правильный номер, но:
- не отражает фактический объем памяти, используемый приложением, а только объем памяти, зарезервированной для него
- может вводить в заблуждение, если страницы используются совместно, например, несколькими потоками или с помощью динамически подключаемых библиотек.
В выводе программ обращайте внимание на поля RSS и RES.
RES — используемая оперативная память, является подмножеством VIRT, представляет физическую память, не помещённую в раздел подкачки, которую в текущий момент использует задача.
RSS — это «resident set size» — физическая память без подкачки, которую использовала задача (в килобайтах). Псевдоним rssize, rsz.
Для просмотра фактически используемой памяти попробуйте команду pmap:
Будут выведены поля
Обратите внимание на нижнюю строку начинающуюся с «total kB», это поле RSS.
В команде top ищите поле RES — вы можете сделать сортировку по данному полю, как это показано на скриншоте ниже:
Виртуальная память в Linux не складывается?
Я смотрел системный монитор в Linux и заметил, что Firefox использует 441 МБ памяти, а несколько других приложений используют 274, 257, 232 и т. д. (Добавляя до 3 ГБ виртуальной памяти). Итак, я перехожу на вкладку «Ресурсы», и там говорится, что я использую 462 МБ памяти и не раздел подкачки не задействован. Я в замешательстве. Что означает объем виртуальной памяти, если программы на самом деле её не используют. Я подумал, может быть, память они запросили, но не используют, но как ОС узнает об этом? Я не могу придумать ни одной функции «при котором данным процессам может понадобиться такое огромное количество памяти в будущем».
Во-первых, разделяемая память не совсем правильно подсчитывается методом команды top. Во-вторых, да, программа запрашивает права на память, а затем использует её, но она может никогда не коснуться выделенной ей памяти, и ОС это знает. Нет проблем если между всеми приложениями будет поделена вся доступная память вместе с разделом подкачки, по крайней мере до тех пор, пока они не пытаются всё это использовать.
Источник