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

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

#!/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.

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: почему значение swappiness по умолчанию не оптимально

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

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

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

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

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

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

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

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

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

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

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

Надеюсь, читатели найдут следующие ссылки apropos.

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/