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

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

Если вы хотите контролировать свою своп-активность, вы можете использовать несколько утилит, но 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 большую часть времени.

Также стоит упомянуть, что этой вытесняющей заменой можно управлять с помощью настройки ядра. Файл на /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

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

Лучше всего отключить подкачку на машинах с несколькими ГБ оперативной памяти:

sysctl -w vm.swappiness=0

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

Изменить 1: почему значение swappiness по умолчанию не оптимально

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

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

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

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

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

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

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

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

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

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

#!/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 замедляется или выходит из строя, когда агенты сильно меняются местами. Может быть, некоторые приложения не возражают или даже выигрывают от подкачки, но базы данных, похоже, действительно страдают от этого. Однако многие дискуссии, которые я видел на форумах, обсуждают своп, деконтекстуализированный из обсуждения конкретной рабочей нагрузки.

В мире администраторов баз данных, по-видимому, существует консенсус в том, что «Здравый смысл заключается в том, что, когда вы используете 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/