2012-03-09 14:13:35 +0000 2012-03-09 14:13:35 +0000
131
131
Advertisement

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

Advertisement

Перед тем, как на самом деле спросить, просто для ясности: да, я знаю о дисковом кэше, и нет, это не мой случай :) Извините за эту преамбулу :)

я использую 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% оперативной памяти и 400 Мб подкачки. Та же картина, когда я пытаюсь запустить другие службы или приложения - все идут в swap, 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

Restart не помогает, и, кстати, они очень медленные, что я обычно не ожидал бы на этой машине (4 ядра, 4 Гб оперативной памяти, RAID1).

Итак, с этим - я почти уверен, что это не дисковый кэш, который использует оперативную память, потому что обычно его нужно было уменьшить и позволить другим процессам использовать оперативную память, а не подкачивать.

Итак, наконец, вопрос в том - есть ли у кого-нибудь идеи, как узнать, какой процесс на самом деле так интенсивно использует память?

Advertisement

答案 (9)

115
115
115
2012-03-09 14:25:01 +0000

На 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
78
78
78
2016-02-09 21:12:26 +0000

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

ps aux | awk '{print $6/1024 " MB\t\t" $11}' | sort -n
14
Advertisement
14
14
2012-10-15 15:05:01 +0000

Просто заметка на сервере, показывающая те же симптомы, но все еще показывающая истощение памяти. В итоге был найден sysctl.conf из коробки с 32 ГБ оперативной памяти и настройкой для БД с огромными страницами, настроенными на 12000. В этом ящике всего 2 ГБ оперативной памяти, поэтому он назначил всю свободную оперативную память на огромные страницы (всего 960 из них). Установка огромных страниц на 10, так как ни одна из них все равно не использовалась, высвободила всю память.

Быстрая проверка /proc/meminfo для поиска настроек HugePages_ может стать хорошим началом для поиска и устранения неисправностей хотя бы одного непредвиденного захода в память.

5
5
5
2018-03-31 03:38:27 +0000

В моем случае проблема заключалась в том, что сервер был виртуальным сервером VMware с включенным модулем vmw_balloon:

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

Running:

$ vmware-toolbox-cmd stat balloon
5189 MB

So около 5 ГБ памяти на самом деле было восстановлено хостом. Так что, несмотря на то, что 8 Гб на мою ВМ “официально”, на практике их было гораздо меньше:

$ free
              total used free shared buff/cache available
Mem: 8174716 5609592 53200 27480 2511924 2458432
Swap: 8386556 6740 8379816
```.
2
Advertisement
2
2
2013-07-08 06:05:54 +0000

Вы также можете использовать команду ps для получения дополнительной информации о процессе.

ps aux | less
2
2
2
2016-10-21 10:51:37 +0000

Я ссылаюсь на this и Total memory used by Python process? - Stack Overflow , вот мой ответ. Теперь я получаю специальную утилиту подсчета процессов (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

Attach my process list.

$ 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
Advertisement
1
1
2016-03-14 20:50:46 +0000

Сделайте скрипт под названием 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") }
 '
0
0
0
2019-07-12 19:46:37 +0000

На моем сервере ubuntu DISTRIB RELEASE=18.04 на Hyper-V использовалась большая часть памяти, но все процессы были в порядке. (Признаюсь, я удалил пакеты snapd и unattended-upgr, но 95% памяти все еще использовалось)

Ответ: Hyper-V имеет динамическую память, поэтому он взял память для использования в основной системе и ubuntu пометил ее как использованную.

Надеюсь, это кому-то поможет.

0
Advertisement
0
0
2019-03-31 17:51:48 +0000

Здесь также берется идентификатор процесса, сортируется по используемому MB и описывается команда (которая создала процесс):

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

相关问题

6
10
5
37
12
Advertisement