Действительно ли Committed_AS в /proc/meminfo является правильным номером для выделенной виртуальной памяти в Linux? Здесь меньше чем MemTotal-MemAvailable

Эти коробки не находятся под значительным давлением памяти. Ни один не пейджинг (SwapFree). Второй блок составляет ~47 ГБ, всего 250 ГБ. 200 ГБ это много, чтобы играть с.

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

• Время отклика пользователя (приложения) ухудшается
• Скорость вывода страниц выше, чем вам удобно
• Убийца ООМ убивает некоторые процессы

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

Другие описания Comited_AS, которые недавно были в списке linux-mm, подчеркивают, что это оценка:

Committed_AS: An estimate of how much RAM you would need to make a
              99.99% guarantee that there never is OOM (out of memory)
              for this workload. Normally the kernel will overcommit
              memory. That means, say you do a 1GB malloc, nothing
              happens, really. Only when you start USING that malloc
              memory you will get real memory on demand, and just as
              much as you use. So you sort of take a mortgage and hope
              the bank doesn't go bust. Other cases might include when
              you mmap a file that's shared only when you write to it
              and you get a private copy of that data. While it normally
              is shared between processes. The Committed_AS is a
              guesstimate of how much RAM/swap you would need
              worst-case.

Вот еще один ответ исключительно о том, что он ниже «ожидаемого»:

Интересные строки из вашегоследующие:

      Active:          4854772 kB
Inactive:        5386896 kB
Active(anon):      33468 kB
Inactive(anon):   412616 kB
Active(file):    4821304 kB
Inactive(file):  4974280 kB
Mlocked:           10948 kB
AnonPages:        428460 kB
Shmem:             26336 kB
Committed_AS:    1488188 kB

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

Какподдерживается файлом, что не вызывает никакого повышения, поэтому практически единственные вещи, которые действительно повышают вашу ценность, - это+ ++ скачки использования памяти. Это объем памяти (ОЗУ + подкачка вместе), который система должна быть в состоянии предоставить запущенным в данный момент процессам, даже если все кеши и буферы сброшены на диск.

Если процесс делает(который обычно реализуется какилиза кулисами) ядро ​​увеличится, но не будет отображаться в других цифрах, поскольку ядро ​​фактически не резервирует реальную оперативную память до тех пор, пока память фактически не будет использована процессом. (Технически ядро ​​определило диапазон адресного пространства виртуальной памяти, который будет использоваться для процесса, но отображение виртуальной памяти для ЦП указывает на заполненную нулями страницу с флагом, который означает, что если процесс пытается что-либо записать, фактическая память должна быть выделена на лету. - это позволяет процессу считывать нули из виртуального адресного пространства без сбоев в работе ЦП, но запись данных в виртуально выделенную область памяти - это действие, которое фактически выделяет память по-настоящему.) Очень часто программы выделяют больше (виртуальной) памяти, чем на самом деле . use, так что это хорошая функция, но она, очевидно, усложняет понимание статистики памяти. Кажется, что в вашей системе в основном выполняются процессы, которые не занимают много памяти, которая фактически не используется, потому что ваше значение довольно низкое по сравнению с другими значениями.

Например, моя текущая система сейчас работает следующим образом:

      MemTotal:       32570748 kB
Active:         12571828 kB
AnonPages:       7689584 kB
Mlocked:           19788 kB
Shmem:           4481940 kB
Committed_AS:   44949856 kB

Обратите внимание на огромный объем (~45 ГБ) в моей системе, несмотря на общее количество анонимных страниц, заблокированной памяти плюситого около 12 ГБ. Поскольку я использую среду рабочего стола в этой системе, я предполагаю, что у меня есть множество процессов, которые выполняются после получения/использования большого количества оперативной памяти. В этом случае разветвленный процесс теоретически может изменить всю эту память без каких-либо явных выделений памяти, и вся эта раздвоенная память подсчитывается в сторону увеличения значения. В результате значение может вообще не отражать фактическое использование системной памяти.

TL;DR: оценивается выделенная виртуальная память, которая не резервируется какой-либо файловой системой , или максимальный объем памяти, который теоретически должен быть поддержан реальным хранилищем (ОЗУ + подкачка), чтобы текущие текущие процессы продолжали работать, если ничто не выделяет больше памяти в целая система.

Однако если система взаимодействует с внешним миром, даже входящие IP-пакеты могут привести к использованию большего объема памяти, поэтому вы не можете дать никаких гарантий относительно будущего поведения системы на основе этого числа. Также обратите внимание, что память стека всегда выделяется «на лету», поэтому, даже если ни один из ваших процессовили явно выделять память, использование памяти () может все равно увеличиться, когда процессы используют больше места в стеке.

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

По моему опыту, это было точнее, чем . Особенно при резкой нагрузке, это больше похоже на какое-то среднее значение, а не на истинное значение за короткие периоды времени.

Тем не менее, я не помню, чтобы использовал данные с ядрами старше версии 4.15, поэтому я не знаю, отличалось ли историческое поведение.

Оба иофициально являются эвристиками уровня ядра, поэтому ни одному из них не следует доверять как истинному факту.

Что касается рабочих нагрузок, которые я использую для запуска, я обычно начинаю испытывать проблемы с производительностью, когда реальный объем оперативной памяти превышает примерно 150%. Однако это, очевидно, сильно зависит от вашей рабочей нагрузки. Если у вас много процессов с утечкой и достаточно подкачки, вы можете продолжать подниматься вверх без проблем с производительностью, поскольку процессы вызывают утечку оперативной памяти, а ядро ​​заменяет протекшие области оперативной памяти на подкачку. Обратите внимание, что в таких случаях без каких-либо проблем может оказаться намного больше, чем общий объем ОЗУ + подкачка.

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

Если вы можете обеспечить достаточный объем подкачки, обычно имеет смысл увеличитьичтобы избежать задержки из-за замены. Однако важно понимать, что— это текущая выделенная память (память, запрашиваемая процессами пользовательского режима, но обычно не полностью используемая) и имеющая покрытие RAM+swap, которое должно обрабатывать все случаи, когда ни один процесс не выделяет новую память. Если только вы не используете какую-то очень экзотическую систему, несколько процессов постоянно выделяют новую память, поэтому не следует делать слишком строгие оценки будущего поведения системы. А если ваша рабочая нагрузка очень высока, текущие цифры очень мало говорят о будущем поведении системы.

В современных системах я бы сосредоточился на статистике, которая может включать в себя все самые высокие краткосрочные пики управления памятью. Я предполагаю, что хорошо сделанная программа статистики будет отслеживать события ядра черези собирать статистику в момент наибольшей нехватки памяти. Однако я не знаю ни одного статистического приложения, которое бы действительно это поддерживало. Любое статистическое приложение, которое собирает данные только за период выборки, определенный настенными часами, пропустит большинство краткосрочных всплесков использования оперативной памяти. Для математически правильных средних выборок необходим период выборки настенных часов, но понимание пиков важнее, чем наличие точных средних значений, потому что именно эти пики убивают ваши процессы/производительность, а не средние значения.