Linux: з’ясуйте, який процес використовує всю оперативну пам’ять?


127

Перш ніж насправді запитати, просто щоб було зрозуміло: так, я знаю про кеш диска, і ні, це не моя справа :) Вибачте за цю преамбулу :)

Я використовую CentOS 5. Кожен додаток у системі сильно змінюється, а система дуже повільно. Коли я це роблю free -m, ось що я отримав:

             total       used       free     shared    buffers     cached
Mem:          3952       3929         22          0          1         18
-/+ buffers/cache:       3909         42
Swap:        16383         46      16337

Отже, я фактично маю лише 42 Мб! Наскільки я розумію, -/+ buffers/cacheнасправді кеш диска насправді не враховується, тому у мене справді лише 42 Мб, правда? Я подумав, що я можу помилятися, тому спробував вимкнути кешування диска, і це не мало ефекту - картинка залишилася колишньою.

Отже, я вирішив з’ясувати, хто використовує всю мою оперативну пам’ять, і я topдля цього використовував . Але, мабуть, це повідомляє, що жоден процес не використовує мою оперативну пам’ять. Єдиний процес у моїй вершині - MySQL, але він використовує 0,1% оперативної пам’яті та 400Mb свопу. Ця ж картина, коли я намагаюся запускати інші сервіси чи програми - всі йдуть свопом, topпоказує, що MEM не використовується (максимум 0,1% для будь-якого процесу).

top - 15:09:00 up  2:09,  2 users,  load average: 0.02, 0.16, 0.11
Tasks: 112 total,   1 running, 111 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   4046868k total,  4001368k used,    45500k free,      748k buffers
Swap: 16777208k total,    68840k used, 16708368k free,    16632k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  SWAP COMMAND
 3214 ntp       15   0 23412 5044 3916 S  0.0  0.1   0:00.00  17m ntpd
 2319 root       5 -10 12648 4460 3184 S  0.0  0.1   0:00.00 8188 iscsid
 2168 root      RT   0 22120 3692 2848 S  0.0  0.1   0:00.00  17m multipathd
 5113 mysql     18   0  474m 2356  856 S  0.0  0.1   0:00.11 472m mysqld
 4106 root      34  19  251m 1944 1360 S  0.0  0.0   0:00.11 249m yum-updatesd
 4109 root      15   0 90152 1904 1772 S  0.0  0.0   0:00.18  86m sshd
 5175 root      15   0 90156 1896 1772 S  0.0  0.0   0:00.02  86m sshd

Перезапуск не допомагає, і, до речі, це дуже повільно, чого я зазвичай не очікував на цій машині (4 ядра, 4 Гб оперативної пам’яті, RAID1).

Отже, з цим - я майже впевнений, що це не дисковий кеш, який використовує оперативну пам’ять, тому що, як правило, це повинно було бути зменшено, а інші процеси дозволяють використовувати оперативну пам’ять, а не переходити до swap.

Отже, нарешті, питання - якщо хтось має якісь ідеї, як дізнатися, який процес насправді так активно використовує пам'ять?


1
Ви коли-небудь знаходили відповідь на це?
Хекрон

@Hackeron: ОП прийняв цю відповідь . Я знаю, що відповідь не відповідає на ваше запитання . Мені вдалося відтворити вашу проблему на одному з моїх серверів, і зараз я досліджую, чи є спосіб її усунути.
Deltik

@Deltik Ага, добре. Дякую :) - У мене є два сервери, які просочують всю наявну пам'ять протягом приблизно 12 годин, повідомте мене, чи є щось, що я можу зробити, щоб допомогти встановити це. Я доступний як псевдонім "хакерон" на IRC (irc.freenode.org).
Хекрон

@Hackeron: Я не зміг знайти тебе як "хакерона" irc.freenode.org. Я створив тут чат для розширеного обговорення .
Делтік

Варто відзначити, що кеш ARC (та / або L2ARC) пам'яті ZFS не відображається free -m, але розмір його можна запитувати в Linux за допомогою cat /proc/spl/kstat/zfs/arcstats | grep data_size.
kqr

Відповіді:


112

У Linux в цьому topпроцесі ви можете натиснути <клавішу, щоб змістити вихідний вид дисплея вліво. За замовчуванням він сортується %CPUтак, якщо натиснути клавішу 4 рази, ви відсортуєте її за VIRTрозміром віртуальної пам'яті, який дає вам свою відповідь.

Ще один спосіб зробити це:

ps -e -o pid,vsz,comm= | sort -n -k 2

повинен надати вам і вихід, відсортований за віртуальним розміром процесів.

Ось довга версія:

ps --everyone --format=pid,vsz,comm= | sort --numeric-sort --key=2

Це дає мені Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.htmlна сервері Ubuntu 11.10.
Der Hochstapler

1
@OliverSalzburg Питання - це -oваріанти. RHEL4 це працює. RHEL5: ps -e -o pid,vsz,comm= | sort -n -k 2працює. Я спробую 11.10 пізніше сьогодні вночі, але якщо ви знайдете правильні варіанти сортування, перш ніж будь ласка, повідомте мене. ps -e -o pid,vsz,comm | sort -n -k 2може спрацювати, але на даний момент у мене немає місця перевірити.
Карлсон

2
Я не дуже знайомий з -efваріантом. Але це, здається, дає розумний результат:sudo ps axo pid,vsz,comm=|sort -n -k 2
Der Hochstapler

1
Тай, мені подобається головна пропозиція, <я не знав, що це можливо, fedora
SSH

2
Трохи модифікована версія, щоб отримати процеси, які займають оперативну пам’ять, і показує повну команду:ps -e --format=pid,rss,args | sort --numeric-sort --key=2
з'являється

71

Показати пам’ять процесів у мегабайтах та шлях процесу.

ps aux  | awk '{print $6/1024 " MB\t\t" $11}'  | sort -n

8
Ласкаво просимо до Супер Користувача. Чи можете ви розширити свою відповідь, щоб пояснити, що робить цей код і як він вирішує проблему? Неясний код не рекомендує , оскільки він не вчить рішення. Дякую.
fixer1234

9
Я здивований, що ця відповідь є оскарженою, і у неї є коментар із проханням пояснити її. Це досить коротко, щоб було зрозуміло, що вона робить (трубки ps aux в awk, а потім сортування), і в контексті питання це показує які процеси використовують найбільше оперативної пам’яті. Я думаю, що це прекрасна відповідь.
Іван

14

Лише бічна примітка на сервері, що демонструє ті самі симптоми, але все ще показує виснаження пам'яті. Результатом виявився sysctl.conf з коробки з 32 ГБ оперативної пам’яті та налаштування для БД з величезними сторінками, налаштованими на 12000. У цій коробці є лише 2 ГБ оперативної пам’яті, тому вона призначала всю вільну ОЗУ величезним сторінкам (лише 960 з них). Встановлення величезних сторінок на 10, оскільки жодна з них не використовувалося, звільнило всю пам'ять.

Швидка перевірка / proc / meminfo для пошуку налаштувань HugePages_ може стати хорошим початком для усунення несправностей принаймні однієї несподіваної свинки пам’яті.


2
Нещодавно у мене був ще один сервер, де це була проблема. Якщо у вашій організації є колишні співробітники Oracle, цей параметр може стати вашим винуватцем.
поля

5

У моєму випадку проблема полягала в тому, що сервер був віртуальним сервером VMware з vmw_balloonвключеним модулем:

$ lsmod | grep vmw_balloon
vmw_balloon            20480  0
vmw_vmci               65536  2 vmw_vsock_vmci_transport,vmw_balloon

Запуск:

$ vmware-toolbox-cmd stat balloon
5189 MB

Таким чином, близько 5 Гб оперативної пам’яті було фактично повернено господарем. Тож, незважаючи на те, що "офіційно" в моєму ВМ було 8 Гб, на практиці це було значно менше:

$ free
              total        used        free      shared  buff/cache   available
Mem:        8174716     5609592       53200       27480     2511924     2458432
Swap:       8386556        6740     8379816

2

Ви також можете скористатися командою ps, щоб отримати більше інформації про процес.

ps aux | less

З цікавості, який правильний спосіб уникнути цієї команди? Він показує, що ОКЕЙ ОКН я досягаю останнього рядка, він не вбиває процес, коли я Ctrl + C це.
KingsInnerSoul

1
@KingsInnerSoul натисніть 'q'
enobayram

2

Я посилаюся на цю та загальну пам'ять, що використовується процесом Python? - Переповнення стека , це моя відповідь. Зараз я отримую специфічний інструмент підрахунку процесу (python).

# Megabyte.
$ ps aux | grep python | awk '{sum=sum+$6}; END {print sum/1024 " MB"}'
87.9492 MB

# Byte.
$ ps aux | grep python | awk '{sum=sum+$6}; END {print sum " KB"}'
90064 KB

Приєднати мій список процесів.

$ ps aux  | grep python
root       943  0.0  0.1  53252  9524 ?        Ss   Aug19  52:01 /usr/bin/python /usr/local/bin/beaver -c /etc/beaver/beaver.conf -l /var/log/beaver.log -P /var/run/beaver.pid
root       950  0.6  0.4 299680 34220 ?        Sl   Aug19 568:52 /usr/bin/python /usr/local/bin/beaver -c /etc/beaver/beaver.conf -l /var/log/beaver.log -P /var/run/beaver.pid
root      3803  0.2  0.4 315692 36576 ?        S    12:43   0:54 /usr/bin/python /usr/local/bin/beaver -c /etc/beaver/beaver.conf -l /var/log/beaver.log -P /var/run/beaver.pid
jonny    23325  0.0  0.1  47460  9076 pts/0    S+   17:40   0:00 python
jonny    24651  0.0  0.0  13076   924 pts/4    S+   18:06   0:00 grep python

Довідково


1

Створіть сценарій, викликаний show-memory-usage.shіз вмістом:

#!/bin/sh
ps -eo rss,pid,user,command | sort -rn | head -10 | awk '{ hr[1024**2]="GB"; hr[1024]="MB";
 for (x=1024**3; x>=1024; x/=1024) {
 if ($1>=x) { printf ("%-6.2f %s ", $1/x, hr[x]); break }
 } } { printf ("%-6s %-10s ", $2, $3) }
 { for ( x=4 ; x<=NF ; x++ ) { printf ("%s ",$x) } print ("\n") }
 '

6
Чому? Що це робить? Як це працює? Не кажіть людям запускати випадковий код; поясніть її призначення та як це працює.
CVn

2
Рисунок Я поясню код для тих, хто не розуміє, як це здається безпечним для запуску, але downvote може відмовитись від тих, до яких це було б корисно. Він виконує ту ж команду, що і в наведених вище відповідях , але додає форматування за допомогою AWK. Я особисто не запускав сценарій, оскільки не маю для цього користі, але пояснення цього допомагає тим, хто потребує певного форматування.
Dooley_labs

1
Я прочитав код і запускаю його. Він вирівнює поля, як таблиця, і формати споживаної резидентної пам'яті з префіксами (наприклад, 1,12 ГБ, 582,79 МБ).
Стефан Гурішон

0

Це також приймає ідентифікатор процесу, сортує за використовуваним МБ та окреслює команду (яка створила процес):

ps aux | awk '{print $6/1024 " MB\t\t" $2 "\t" $11}' | sort -n


0

Мій сервер ubuntu DISTRIB RELEASE = 18.04 на Hyper-V мав більшу частину використовуваної пам'яті, але всі процеси пройшли нормально. (Зізнається, я видалив оснащені пакети без огляду та без нагляду, але 95% пам'яті все ще було використано.)

Відповідь: Hyper-V має динамічну пам’ять, тому вона потребувала пам'яті для основного використання системи та ubuntu позначила її як використану.

Сподіваюся, це комусь допоможе.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.