Як знайти те, що використовується підмінами linux або що є в свопі?


12

У мене є віртуальний сервер Linux (Fedora 17) з 28 Гб оперативної пам’яті та 2 Гб свопом. Сервер працює з базою даних MySQL, яка створена для використання більшості оперативної пам'яті.

Через деякий час запуску сервер починає використовувати swap для обміну незахищеними сторінками. Це нормально, оскільки моя замітка за замовчуванням 60, і це очікувана поведінка.

Дивна річ у тому, що число в топі / 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. 440 Мб з mysql, використовуючи ca. 90% свопу.

Питання полягає в тому, чому це так сильно відрізняється від верхніх та пам’ятних номерів? Чи є спосіб, як "скинути" інформацію про своп, щоб побачити, що насправді є, замість того, щоб підсумовувати звички своп з усіх процесів?

Аналізуючи проблему, я придумав різні ідеї, але всі вони, здається, помиляються:

  1. Вихід сценарію не в КБ. Навіть якщо вона буде в 512 або 4 КБ одиниць, вона не збігається. Насправді співвідношення (1200: 440) становить приблизно 3: 1, що є "дивним" числом.
  2. Є кілька сторінок у свопі, які якимось чином поділяються між процесами, як зазначено в /server//a/477664/98204 . Якщо це правда, як я можу знайти фактичну кількість пам’яті, що використовується таким чином? Я маю на увазі, що це повинно зробити різницю в cca 800MB. І це не правильно звучить у цьому сценарії.
  3. Є кілька "старих" сторінок в свопі, використовуваних процесами, які вже закінчилися. Я б не заперечував, що якби мені вдалося дізнатися, скільки коштує цей "безкоштовний" своп.
  4. Є сторінки в свопі, які були замінені назад в пам'ять і є в обміні на випадок, якщо вони не змінилися в оперативній пам’яті і їх потрібно буде знову поміняти, як зазначено в /server//a/100636/98204 . Але значення SwapCched становить лише 24 Мб.

Дивна річ у тому, що використання swap повільно збільшується, тоді як сума виводу зі сценарію приблизно однакова. За останні 3 дні використаний своп збільшився з 1100 МБ до поточних 1230 МБ, тоді як сума зросла з 430 МБ до поточних 449 МБ (ca.).

Сервер має достатньо вільної (здатної) оперативної пам’яті, щоб я міг просто вимкнути своп і повернути його знову. Або я, мабуть, міг би встановити заміщення на 0, щоб свопом звикнути, лише якщо це не інший спосіб. Але я хотів би вирішити питання або принаймні з’ясувати, в чому причина цього.


Як ви кажете, вам слід просто встановити vm.swappiness = 0 (або 1) та swapoff && swapon
HTTP500

Але це не вирішило б це питання. Я припускаю, що своп знову почне збільшуватися, якщо я встановив swappines назад до 60 або не використовувався б взагалі, якщо я зберігаю його на 0 або 1 (якщо сервер не залишиться в пам'яті)
Radek Hladík

Якщо це сервер DB, він повинен використовувати swap лише в надзвичайних ситуаціях, тому завжди слід встановлювати його на 0 (або 1).
HTTP500

Це правда, і це, мабуть, те, що я буду робити, якщо я не знайду причину цього питання ... З іншого боку, на сервері є багато невеликих БД, які використовуються дуже спорадично, і мені сподобалася думка про те, що вони поміняється системою, коли вони не використовуються ... Однак я припускаю, що MySQL зможе самостійно впоратися з цим ...
Radek Hladík

Mysql робить досить непогану роботу з керування власними кешами, але це засновано на припущеннях про те, що насправді є в пам'яті, а що ні. Якщо ви спробуєте подвійно відгадати це за допомогою swap-пам'яті, ви просто погіршуєте можливість 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що буде зберігатися всі відповідні дані, щоб smem можна було запустити на ньому пізніше.

   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.

1
Smem з F17 repo не працював (показав порожній список), але той, який працював у джерелі, працював і показує майже такі ж цифри, як і інші :-) mysql 358.1M із загальної кількості 392.6M, тоді як топ-шоу 1191224k використано
Radek Hladík

4

Ви повинні перевірити цей скрипт на іншій машині, оскільки моя система показує правильне використання підкачки:

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

Дуже поблизу 111280 ~ = 120368.

Також подивіться на цей сценарій:

for 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-process


Згаданий сценарій повертає ті самі результати ... 364920 / usr / libexec / mysqld 400372 Разом
Radek Hladík

Коли я спробував сценарій на іншому сервері з дуже низьким використанням swap (50MB), він загалом повідомив про близько 72 Мб :-) Пізніше мені потрібно буде імітувати його на якомусь невиробничому сервері ...
Radek Hladík
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.