У меня есть ведущий производства, ниже:

Система использует 1 ГБ подкачки, сохраняя при этом почти 40 ГБ свободной неиспользуемой памяти. Должен ли я беспокоиться об этом, или это в основном нормально?

Это не проблема и, скорее всего, нормально. Множество кода (и, возможно, данных) используется очень редко, поэтому система выгрузит его, чтобы освободить память.

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

Если вы хотите контролировать свою активность подкачки, вы можете использовать несколько утилит, но vmstatобычно это очень полезно, например

$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 348256  73540 274600    0    0     1     9    9    6  2  0 98  0  0
 0  0      0 348240  73544 274620    0    0     0    16   28   26  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   29   33  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   21   23  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   24   26  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   23   23  0  0 100  0  0

Игнорируйте первую строку, так как это действие с момента запуска системы. Обратите внимание на siи soстолбцы под ---swap--; обычно они должны быть довольно маленькими, если не равны 0 в большинстве случаев.

Также стоит упомянуть, что этим преимущественным обменом можно управлять с помощью настроек ядра. Файл at /proc/sys/vm/swappinessсодержит число от 0 до 100, которое указывает ядру, как агрессивно выменять память. Cat файл, чтобы увидеть, что это установлено. По умолчанию в большинстве дистрибутивов Linux по умолчанию установлено значение 60, но если вы не хотите, чтобы какая-либо перестановка происходила до исчерпания памяти, введите в файл 0:

echo 0 >/proc/sys/vm/swappiness

Это можно сделать постоянным, добавив

vm.swappiness = 0

к /etc/sysctl.conf.

Linux будет преимущественно записывать страницы на диск, если у него нет ничего лучше. Это не значит, что он изгонит эти страницы из памяти. Просто в случае, если когда- нибудь в будущем он должен будет удалить эти страницы, ему не нужно ждать, пока они будут записаны на диск, потому что они уже есть.

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

По той же причине ваша память всегда должна быть полной. Страницы памяти, кеш файловой системы, tmpfsв памяти может храниться так много всего. На самом деле, вы должны быть обеспокоены, если ваша память пуста; в конце концов, вы заплатили за это много денег (по крайней мере, по сравнению с тем же объемом дискового пространства), так что лучше его использовать!

Используемый своп - это неплохо, но много

  vmstat 1
  procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
  6  0 521040 114564   6688 377308    8   13   639   173    0 1100  5  4 90  0
  1  0 521040 114964   6688 377448    0    0   256     0    0 1826  3  4 94  0
  0  0 521040 115956   6688 377448    0    0     0     0    0 1182  7  3 90  0
  0  0 521036 115992   6688 377448    4    0    16     0    0 1154 10  2 88  0
  3  0 521036 114628   6696 377640    0    0   928   224    0 1503 15 17 67  1

Столбец swapd вообще не проблема. Ненулевые значения в столбцах si и т. Д. Смертельны для производительности сервера. Особенно те, с большим количеством оперативной памяти.

Лучше всего отключить обмен на компьютерах с несколькими ГБ ОЗУ:

sysctl -w vm.swappiness=0

Это не отключит своп. Он будет только инструктировать Linux использовать своп в качестве крайней меры. Это приведет к потере нескольких МБ программ, которые не обязательно должны быть в ОЗУ ... Но предпочтительнее, если вы переполните свои очереди доступа к диску.

Редактировать 1: почему значение по умолчанию для подкачки не является оптимальным

Мы должны помнить, что два десятилетия назад большой 486 имел только 32 МБ ОЗУ. Алгоритмы обмена были разработаны, когда вся оперативная память могла быть перемещена на диск за небольшую долю секунды. Даже с более медленными дисками того времени. Вот почему политики обмена по умолчанию так агрессивны. В те дни ОЗУ было узким местом. С тех пор объем оперативной памяти увеличился более чем в 10000 раз, а скорость дисков менее чем в 10 раз. Это сместило узкое место на пропускную способность диска.

Редактировать 2: почему такая активность смертельна для серверов?

Si и поэтому активность на машинах с тоннами ОЗУ смертельна , потому что означает , что система борется с самим собой для оперативной памяти. Что происходит, так это то, что диски, даже большие хранилища, работают слишком медленно по сравнению с ОЗУ. Агрессивный своп предпочитает кеш диска диска данным приложения и является наиболее распространенным источником борьбы за оперативную память. Так как операционная система будет иметь в свободном дисковом кэше на каждой си , время жить в дополнительной кэш - памяти , что обеспечивает обмен слишком мала , чтобы быть полезным в любом случае. В результате вы используете пропускную способность диска для хранения кэша, который, вероятно, не будет использоваться, и приостанавливаете работу ваших программ в ожидании страниц si . Это означает, что потребляет много критически важных ресурсов с минимальными или нулевыми преимуществами для приложений.

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

Редактировать 3: «холодные» страницы

Люди романтизируют алгоритм обмена. Некоторые говорят, что «он занимает меньше используемых страниц оперативной памяти», но это совсем не то, что делает ядро. В swap трудно понять, что ядро ​​не знает, что такое «холодная страница». Ядро не имеет хорошего показателя, чтобы определить, будет ли страница использоваться или может быть использована в ближайшем будущем. Чтобы обойти это, ядро ​​более или менее случайным образом помещает страницы в файл подкачки, а ненужные страницы остаются там. Проблема этого алгоритма заключается в том, что страницы должны перейти в раздел подкачки, чтобы узнать, нужны ли они приложениям. А это значит, что многие «горячие» страницы перейдут на своп. Проблема в том, что диски слишком медленные по сравнению с оперативной памятью.

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

Я иду немного дальше об этом: я понимаю, что своп не для обработки. Свопы предназначены только для экстренных случаев. Те моменты, когда одновременно запускается слишком много приложений, и вы получаете всплеск памяти. Без свопа это приведет к ошибкам нехватки памяти. Я считаю использование свопа неудачей команд разработчиков и разработчиков. Это просто мнение, которое выходит за рамки того, что мы здесь обсуждали, но это то, что я думаю. Конечно, мои приложения имеют отличное управление памятью.

Это не ответ на ваш вопрос; скорее, просто дополнительная информация, которая поможет вам принять обоснованное решение.

Если вы хотите узнать, какие процессы конкретно используют объем обмена, вот небольшой сценарий оболочки:

#!/bin/bash

set -o posix
set -u

OVERALL=0
for DIR in `find /proc/ -maxdepth 1 -type d -regex "^/proc/[0-9]+"` ; do
  PID=`echo $DIR | cut -d / -f 3`
  PROGNAME=`ps -p $PID -o comm --no-headers`

  SUM=0
  for SWAP in `grep Swap $DIR/smaps 2>/dev/null| awk '{ print $2 }'` ; do
    let SUM=$SUM+$SWAP
  done
  echo "PID=$PID - Swap used: $SUM - ($PROGNAME )"

  let OVERALL=$OVERALL+$SUM
done
echo "Overall swap used: $OVERALL"

Я должен также добавить, что tmpfs также поменяется. Это чаще встречается в современных системах Linux, использующих systemd, которые создают оверлеи пространства пользователя / tmp с помощью tmpfs.

Я заметил, что репликация MySQL Cluster замедляется или дает сбой, когда агенты сильно меняются. Может быть, некоторые приложения не возражают или даже могут извлечь выгоду из некоторого обмена, но базы данных действительно страдают от этого. Тем не менее, многие дискуссии, которые я видел на форумах, обсуждают обмен деконтекстуализированными с конкретной рабочей нагрузки.

В мире DBA консенсус выглядит так: «Здравый смысл заключается в том, что когда вы работаете с MySQL (или с любой другой СУБД), вы не хотите видеть какие-либо операции ввода-вывода в пространстве подкачки. Масштабирование размера кеша (с использованием innodb_buffer_pool_size (в случае MySQL) - это стандартная практика, чтобы убедиться, что свободной памяти достаточно, чтобы подкачка не требовалась.

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

Я надеюсь, что читатели найдут следующие ссылки по поводу.

https://www.percona.com/blog/2017/01/13/impact-of-swapping-on-mysql-performance/

https://www.percona.com/blog/2010/01/18/why-swapping-is-bad-for-mysql-performance/