Назад | Перейти на главную страницу

Какую метрику мне следует использовать, чтобы определить, когда серверу не хватает памяти?

Существует множество (сотни?) Различных показателей использования памяти на компьютере с Linux, но какую эвристику / метрику можно использовать, чтобы определить, требуется ли серверу больше памяти?

Некоторые идеи:

Глядя на MemTotal - Active - Inactive из / proc / meminfo как меру "проводной" памяти
Просмотр суммы значений RSS от всех процессов в ps
Глядя на Committed_AS в / proc / meminfo

linux memory

Ядро Linux 4.20 добавлен PSI, что означает «информация о остановке давления». Это дает вам больше информации о том, почему машина перегружена. И какой ресурс является узким местом.

Есть три новых файла под /proc/pressure:

/proc/pressure/cpu
/proc/pressure/memory
/proc/pressure/io

Цитировать из Отслеживание информации о срыве давления что касается /proc/pressure/memory:

Его вывод выглядит так:
some avg10=70.24 avg60=68.52 avg300=69.91 total=3559632828
full avg10=57.59 avg60=58.06 avg300=60.38 total=3300487258
В some Строка аналогична информации о процессоре: она отслеживает процент времени, в течение которого хотя бы один процесс мог бы работать, если бы он не ждал ресурсов памяти. В частности, таким образом отслеживается время, затрачиваемое на подкачку, поиск страниц из кэша страниц и выполнение прямого возврата. Таким образом, это хороший индикатор того, когда система перегружается из-за нехватки памяти.

В full строка немного отличается: она отслеживает время, в течение которого никто не может использовать ЦП для реальной работы из-за нехватки памяти. Если все процессы ожидают ввода-вывода подкачки, ЦП может выглядеть простаивающим, но это не из-за отсутствия работы. Если эти процессы выполняют восстановление памяти, конечный результат будет почти таким же; ЦП занят, но не выполняет ту работу, которую должен делать компьютер. Если full числа намного больше нуля, ясно, что системе не хватает памяти, необходимой для поддержки текущей рабочей нагрузки.

У меня еще нет доступа к производственному серверу с Linux 4.20, но вот небольшой эксперимент на моем рабочем столе (на котором не настроен свопинг). Изначально у меня вообще нет давления на память (все счетчики на 0):

$ cat /proc/pressure/memory
some avg10=0.00 avg60=0.00 avg300=0.00 total=0
full avg10=0.00 avg60=0.00 avg300=0.00 total=0

Затем я увеличил использование памяти до тех пор, пока у меня не закончилась память, что заморозило машину, пока OOM не убил некоторые процессы. До того, как замерз, давление на память увеличилось:

some avg10=0.00 avg60=0.00 avg300=0.00 total=0
full avg10=0.00 avg60=0.00 avg300=0.00 total=0

some avg10=0.00 avg60=0.00 avg300=0.00 total=47047
full avg10=0.00 avg60=0.00 avg300=0.00 total=32839

some avg10=0.00 avg60=0.00 avg300=0.00 total=116425
full avg10=0.00 avg60=0.00 avg300=0.00 total=81497

some avg10=1.26 avg60=0.22 avg300=0.04 total=183863
full avg10=0.72 avg60=0.13 avg300=0.02 total=127684

Теперь, после восстановления системы, давление памяти снова равно 0, а total счетчики больше не увеличиваются:

$ cat /proc/pressure/memory 
some avg10=0.00 avg60=0.00 avg300=0.07 total=53910568
full avg10=0.00 avg60=0.00 avg300=0.02 total=27766222

...

$ cat /proc/pressure/memory 
some avg10=0.00 avg60=0.00 avg300=0.05 total=53910568
full avg10=0.00 avg60=0.00 avg300=0.00 total=27766222

На это нет правильного ответа.

Питер прав, говоря, что значения, на которые вам нужно смотреть, указаны сверху и бесплатно (вы можете получить исходный код для пакета procps, который показывает, как получить эти значения из 'C', но для скриптов проще просто запустить 'бесплатно')

Если в системе есть неиспользуемая память (первая строка вывода из free), то вряд ли она станет намного быстрее, добавив больше памяти, но она может стать быстрее за счет уменьшения давления кеш-памяти VFS (хранить данные в кеше дольше).

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

В качестве отправной точки вы должны взглянуть на два значения свободной памяти, сообщаемые «свободным».

Я уже говорил об этом раньше, лучшая мера для получения требований к памяти в реальном времени - это наблюдать за полем COmmitted_AS в / proc / meminfo и сравнивать его во времени, чтобы увидеть, сколько памяти вам нужно.

Теоретически, если ваш Committed_AS всегда больше, чем (Memfree + swapfree), тогда все в порядке. Но если это меньше, и вы со временем накапливаете свою рабочую нагрузку в системе, вы приближаетесь к ситуации OOM. Значение Committed_AS определяет, сколько памяти требуется системе, если все запросы к памяти были предоставлены системе в этот самый момент.

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

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

Нехватка памяти идеальна, так как не нужно беспокоиться о кешировании страниц, подкачке или даже о том, сколько памяти у вас на самом деле.

Недостаток памяти - это фактически подсчет количества страниц, которые нужно пометить как активные в соответствии с / proc / meminfo. Ядро измеряет нагрузку на память, отслеживая, сколько страниц в таблице страниц переходят из состояния «неактивно» в состояние «активное». Значительное переключение между этими двумя состояниями указывает на то, что у вас, вероятно, недостаточно свободной памяти, чтобы сделать больше страниц активными.

На низкую нехватку памяти указывает очень небольшое количество переходов от неактивного к активному (поскольку в ядре явно достаточно места, чтобы активные страницы оставались активными).

Этот скрипт будет измерять давление каждые ПЕРИОДИЧЕСКИЕ секунды. Чем больше данных вы сможете собрать, тем лучше. Идея заключается в том, что вы наносите на график данные и вставляете ось Y с 0 в центре. В идеальных условиях на графике должна быть горизонтальная линия, следующая за нулем. Если линии регулярно выходят за пределы 0 (в частности, «Активный» является положительным или регулярно растет), нагрузка на память хоста высока, и было бы полезно больше памяти.

#!/usr/bin/python
import os
import sys
import re
import time

PERIODIC = 1
pgs = re.compile('Active:\s+([0-9]+) kB\nInactive:\s+([0-9]+) kB')
meminfo = open('/proc/meminfo')

def read_meminfo():
    content = meminfo.read(4096)
    m = pgs.search(content, re.M)
    active, inactive = int(m.group(1)), int(m.group(2))
    active = active / 4
    inactive = inactive / 4
    meminfo.seek(0, 0)
    return active,inactive  

if __name__ == "__main__":
    oldac, oldin = read_meminfo()
    while True:
        time.sleep(PERIODIC)
        active, inactive = read_meminfo()
        print "Inactive Pressure:\t%d" % (inactive - oldin)
        print "Active Pressure:\t%d" % (active - oldac)
        oldac = active
        oldin = inactive

Вы можете запустить команду top чтобы увидеть обзор всех основных компонентов Linux, включая использование памяти. При первом просмотре top обратите внимание, что используемая память включает буферы и кеш, если таковые имеются.

Также есть free команда для памяти. Вы можете выполнить как free -m для просмотра свободной памяти в мегабайтах.

Есть еще много инструментов, но я думаю, что это достаточно ответ на инструментальную часть вопроса.

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

На вашем месте я бы собирал данные о нагрузке, свободной памяти, free -m и основную характеристику производительности вашего сервера (например, задержку на запрос) и графически отображают в Calc / Excel, пытаясь различить «провал подкачки» для нескольких точек данных (конфигурации памяти - 8 ГБ, 16 ГБ, 32 ГБ и т. д.). Затем я пробовал различные регрессии, чтобы найти связь между «обрывом» и доступной памятью.

Поиск существующей литературы на CiteSeerX тоже поможет.