Как найти то, что использует linux swap или что находится в swap?

12

У меня есть виртуальный сервер Linux (Fedora 17) с 28 ГБ оперативной памяти и 2 ГБ подкачки. На сервере запущена БД MySQL, настроенная на использование большей части ОЗУ.

Через некоторое время сервер начинает использовать swap для замены неподдерживаемых страниц. Это нормально, так как моя перестановка по умолчанию равна 60, и это ожидаемое поведение.

Странно то, что число в top / meminfo не соответствует информации от процессов. Т.е. сервер сообщает эти цифры:

/proc/meminfo:
SwapCached:        24588 kB
SwapTotal:       2097148 kB
SwapFree:         865912 kB

top:
Mem:  28189800k total, 27583776k used,   606024k free,   163452k buffers
Swap:  2097148k total,  1231512k used,   865636k free,  6554356k cached

Если я использую скрипт из /server//a/423603/98204, он сообщает разумные числа (несколько МБ, замененных на bash'es, systemd и т. Д.) И одно большое выделение из MySQL (я пропустил много строк вывода ):

892        [2442] qmgr -l -t fifo -u
896        [2412] /usr/libexec/postfix/master
904        [28382] mysql -u root
976        [27559] -bash
984        [27637] -bash
992        [27931] SCREEN
1000       [27932] /bin/bash
1192       [27558] sshd: admin@pts/0
1196       [27556] sshd: admin [priv]
1244       [1] /usr/lib/systemd/systemd
9444       [26626] /usr/bin/perl /bin/innotop
413852     [31039] /usr/libexec/mysqld --basedir=/usr --datadir=/data/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/data/mysql/err --open-files-limit=8192 --pid-file=/data/mysql/pid --socket=/data/mysql/mysql.sock --port=3306
449264   Total Swap Used

Так что, если я получу правильный вывод скрипта, общее использование подкачки должно быть 449264K = ca. 440MB с MySQL, используя ок. 90% своп.

Вопрос в том, почему это так сильно отличается от верхних и чисел минминфо? Есть ли способ, как «сбросить» информацию о свопе, чтобы увидеть, что на самом деле в ней, вместо суммирования использования свопа во всех процессах?

При анализе проблемы у меня возникли разные идеи, но все они кажутся неправильными:

  1. Вывод скрипта не в КБ. Даже если он будет в 512 или 4 КБ, он не будет совпадать. На самом деле соотношение (1200: 440) составляет около 3: 1, что является «странным» числом.
  2. В swap есть несколько страниц, которые каким-то образом распределяются между процессами, как указано в /server//a/477664/98204 . Если это правда, как я могу найти фактическое количество используемой памяти? Я имею в виду, что это должно было бы сделать разницу около 800 МБ. И это не звучит правильно в этом сценарии.
  3. В swap есть несколько «старых» страниц, используемых процессами, которые уже закончили. Я бы не возражал, если бы мне удалось узнать, сколько стоит этот «бесплатный» своп.
  4. Есть страницы в разделе подкачки, которые были перекачаны обратно в память и находятся в режиме подкачки на тот случай, если они не изменились в ОЗУ и их необходимо заменить снова, как указано в /server//a/100636/98204 . Но значение SwapCached составляет всего 24 МБ.

Странно то, что использование свопа медленно увеличивается, а сумма вывода из скрипта примерно одинакова. За последние 3 дня объем используемого свопа увеличился с 1100 МБ до текущих 1230 МБ, а сумма увеличилась с 430 МБ до текущих 449 МБ (ок.).

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

Радек Хладик
источник
Как вы говорите, вы должны просто установить vm.swappiness = 0 (или 1) и swapoff && swapon
HTTP500
Но это не решило бы проблему. Я предполагаю, что своп снова начнет увеличиваться, если я установлю swappines обратно на 60 или не будет использоваться вообще, если я оставлю его на 0 или 1 (если серверу не
хватает
Если это сервер БД, он должен использовать своп только в чрезвычайной ситуации, поэтому вы всегда должны устанавливать его на 0 (или 1).
HTTP500
Это правда, и это, вероятно, то, что я собираюсь сделать, если я не найду причину этой проблемы ... С другой стороны, на сервере много маленьких БД, которые используются очень редко, и мне понравилась идея, что они меняются системой, когда они не используются ... Однако я предполагаю, что MySQL сможет справиться с этим самостоятельно ...
Radek Hladík
Mysql довольно хорошо справляется с управлением собственными кешами, но это основано на предположениях о том, что на самом деле находится в памяти, а что нет. Если вы попытаетесь угадать это с помощью подкачки памяти, вы просто ослабите способность mysql решать, что нужно кэшировать, а что нет. Выключи своп. Если вы нажали своп, это провал настройки. Отрегулируйте размеры кеша так, чтобы обмен никогда не происходил, но если не считать этого, вы хотите использовать всю доступную физическую память.
mc0e

Ответы:

9

Fedora 18 и выше есть smemв репо. Вы можете скачать скрипт Python и установить его из исходного кода .

Вот пример выходных данных (несколько снятых и анонимных) с моей машины:

# smem -s swap -t -k -n
  PID User     Command                         Swap      USS      PSS      RSS 
20917 1001     bash                               0     1.1M     1.1M     1.9M 
28329 0        python /bin/smem -s swap -t        0     6.3M     6.5M     7.4M 
 2719 1001     gnome-pty-helper               16.0K    72.0K    73.0K   516.0K 
  619 0        @sbin/mdadm --monitor --sca    28.0K    72.0K    73.0K   248.0K 

[big snip]

32079 42       gnome-shell --mode=gdm         41.9M     1.9M     2.0M     5.0M 
32403 1001     /opt/google/chrome/chrome -    43.1M   118.5M   119.4M   132.3M 
 4844 1002     /opt/google/chrome/chrome      48.1M    38.1M    41.9M    51.9M 
 5411 1002     /opt/google/chrome/chrome -    54.6M    33.4M    33.5M    36.8M 
 5624 1002     /opt/google/chrome/chrome -    72.4M    54.9M    55.5M    65.7M 
24328 1002     /opt/Adobe/Reader9/Reader/i    77.5M     1.9M     2.0M     5.2M 
 4921 1002     /opt/google/chrome/chrome -   147.2M   258.4M   259.4M   272.0M 
-------------------------------------------------------------------------------
  214 14                                       1.1G     1.1G     1.2G     1.7G 

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

   To  capture  memory statistics on resource-constrained systems, the the
   smem source includes a utility named  smemcap.   smemcap  captures  all
   /proc entries required by smem and outputs them as an uncompressed .tar
   file to STDOUT.  smem can analyze the output using the --source option.
   smemcap is small and does not require Python.
rickhg12hs
источник
1
Smem из репозитория F17 не работал (показывал пустой список), но один из источника работал и показывает почти те же цифры, что и остальные :-) mysql 358.1M из общего числа 392.6M, в то время как топ показывает 1191224k, использованных
Radek Hladík
4

Вы должны проверить этот скрипт на другом компьютере, потому что моя система показывает правильное использование подкачки:

# Your_script.sh
111280   Total Swap Used
# free
Swap:     33551716     120368   33431348

Очень близко 111280 ~ = 120368.

Также посмотрите на этот скрипт:

для proc в / proc / *; do cat $ proc / smaps 2> / dev / null | awk '/ Swap / {swap + = $ 2} END {print swap "\ t' readlink $proc/exe'"}'; сделано | сортировать -n | awk '{total + = $ 1} / [0-9] /; END {print total "\ tTotal"}'

Из этой темы:

/unix/71714/linux-total-swap-used-swap-used-by-processes

нитка
источник
Упомянутый скрипт возвращает те же результаты ... 364920 / usr / libexec / mysqld 400372 Всего
Радек Хладик
Когда я попробовал скрипт на другом сервере с очень низким уровнем использования подкачки (50 МБ), он сообщил о сумме около 72 МБ :-) Мне нужно будет смоделировать его на каком-нибудь непроизводственном сервере позже ...
Радек Хладик