У мене є господар виробництва, нижче:

Система використовує 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, то більшість часу.

Також варто відзначити, що цією попередньою заміною можна керувати за допомогою налаштування ядра. Файл /proc/sys/vm/swappinessмістить число від 0 до 100, яке вказує ядру, як агресивно змінювати пам'ять. Прокрутіть файл, щоб побачити, для чого це встановлено. За замовчуванням у більшості дистрибутивів 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 і тому активність на машинах з тоннами ОЗУ смертельна , тому що означає , що система бореться з самим собою для оперативної пам'яті. Що відбувається, так це те, що диски, навіть великі сховища занадто повільні в порівнянні з оперативною пам’яттю. Агресивний своп сприяє кеш-диску диска ядра над даними програми і є найпоширенішим джерелом боротьби за оперативну пам'ять. Оскільки ОС доведеться звільняти кеш диска на кожен si , час для використання додаткового кешу, який надає своп, занадто низький, щоб бути корисним у будь-якому випадку. Результат полягає в тому, що ви приймаєте пропускну здатність диска для зберігання кешу, який, ймовірно, не буде використовуватися, і призупиняє ваші програми, очікуючи сторінки si . Мається на увазі, що споживає багато критичних ресурсів з малою користю для додатків або зовсім не має.

Зверніть увагу на заголовок відповіді "багато операцій підкачки на серверах з великою кількістю ОЗУ". Це не стосується машин із періодичною активністю si. Це може не застосовуватися в майбутньому, якщо в ОС розробляються розумніші алгоритми заміни.

Редагувати 3: "холодні" сторінки

Люди романтизують алгоритм заміни. Деякі кажуть, що «потрібно менше використовуваних сторінок оперативної пам’яті», але це зовсім не те, що ядро ​​робить. Справа важко зрозуміти про своп - ядро ​​не знає, що таке "холодна сторінка". Ядро не має хорошої метрики, щоб визначити, чи використовується сторінка або вона буде використана найближчим часом. Щоб обійти те, що ядро ​​ставить сторінки в своп більш-менш випадковим чином, а сторінки, які не потрібні, залишаються там. Проблема цього алгоритму полягає в тому, що сторінки повинні перейти на своп, щоб знати, чи потрібні вони додаткам. А це означає, що багато "гарячих" сторінок підуть на своп. Проблема в тому, що диски занадто повільно порівняно з оперативною пам'яттю.

Я створив власний орієнтир, який є реалістичним сценарієм, дуже поширеним для багатьох програм із пристойним обсягом. З моїх тестів я не бачив переваг щодо пропускної здатності або затримки під час використання свопів. Далеко від цього. Коли заміна починається, вона сповільнює як пропускну здатність, так і затримку принаймні на порядок.

Хочу трохи далі про це: я розумію, що своп не для обробки. Обміни призначені лише для надзвичайних ситуацій. Ті моменти, коли одночасно запускається занадто багато додатків, і ви отримуєте сплеск пам’яті. Без заміни це може призвести до помилок, що знаходяться поза пам'яттю. Я вважаю використання swap невдачею команд розвитку та виробництва. Це лише думка, яка виходить за рамки того, що ми тут обговорювали, але це те, що я думаю. Звичайно, мої програми мають відмінне управління пам'яттю самі по собі.

Це не відповідь на ваше запитання; а скоріше лише додаткова інформація, яка допоможе вам прийняти обгрунтоване рішення

Якщо ви хочете дізнатися, які саме процеси використовують, скільки 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 (або насправді будь-якої іншої СУБД) ви не хочете бачити жодного I / O у вашому просторі обміну. ​​Масштабування розміру кешу (за допомогою 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/