Задать вопрос

Как найти невидимый процесс, потребляющий много памяти?

Есть сервер. 12 ядер CPU, 128Gb RAM. Аптайм почти год.
Где-то 50 Гб занято неизвестным процессом. В top не видно, кто мог бы занимать такой объем памяти (фактически у всех процессов по 0.0%). На сервере из самых больших потребителей памяти -- postgres и redis.
Перезапускать сервер не пробовал. После перезапуска сервера существенно ничего не поменялось.

Как выглядело при остановленных postgres и redis:
5c8788f51b2f3209775050.png
После перезапуска при остановленных postgres и redis:
5c88adc733165708321317.png
# lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 14.04.1 LTS
Release:	14.04
Codename:	trusty
# uname -a
Linux *** 3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux


Собственно вопрос, можно ли увидеть, кто потребляет столько памяти? Или это баг ядра? Или это проблемы с физическим устройством? Может ли кто-то подсказать, как хотя бы сузить круг вариантов? Спасибо.

UPD:
5c87838132ccb449706580.png
# free -m
             total       used       free     shared    buffers     cached
Mem:        128910     128295        614         15         45      58001
-/+ buffers/cache:      70249      58661
Swap:        65503        486      65017


UPD2:
# ps aux --sort -rss | head -5
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
redis    17527  0.1 11.6 16119340 15359700 ?   Ssl  Mar11   2:22 /usr/local/bin/redis-server 0.0.0.0:****         
postgres  3320  1.4  0.0 21683512 63976 ?      Ss   10:33   0:37 postgres: root *(3439) idle                                                            
postgres  3185  2.0  0.0 21676664 58268 ?      Ss   10:33   0:53 postgres: root *(45405) idle                                                           
postgres 30150  3.1  0.0 21676344 58184 ?      Ss   08:25   5:19 postgres: root *(38249) idle


UPD3:
# vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0 498100 647344  43184 58972332   14    4   597   331    0    0 15  2 81  2  0


UPD4:
# mount -l
/dev/md2 on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/cgroup type tmpfs (rw)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755)
none on /sys/fs/pstore type pstore (rw)
/dev/md1 on /boot type ext3 (rw)
/dev/mapper/megadata-verygood on /data type ext4 (rw,nosuid,nodev,uhelper=udisks)
rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw)
systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)


# cat /proc/meminfo
MemTotal:       132004348 kB
MemFree:          621276 kB
Buffers:           39096 kB
Cached:         59445108 kB
SwapCached:       441140 kB
Active:         45814080 kB
Inactive:       31157208 kB
Active(anon):   16139272 kB
Inactive(anon):  1409684 kB
Active(file):   29674808 kB
Inactive(file): 29747524 kB
Unevictable:       10612 kB
Mlocked:           10620 kB
SwapTotal:      67075964 kB
SwapFree:       66583004 kB
Dirty:             24344 kB
Writeback:            16 kB
AnonPages:      17100080 kB
Mapped:            35732 kB
Shmem:             15752 kB
Slab:             655128 kB
SReclaimable:     572604 kB
SUnreclaim:        82524 kB
KernelStack:        2400 kB
PageTables:        57404 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    106639480 kB
Committed_AS:   18698340 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      494836 kB
VmallocChunk:   34359132264 kB
HardwareCorrupted:     0 kB
AnonHugePages:  11401216 kB
HugePages_Total:   25819
HugePages_Free:    15316
HugePages_Rsvd:        2
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:      106760 kB
DirectMap2M:     9295872 kB
DirectMap1G:    126877696 kB


Вывод /proc/slabinfo

UPD5:
slabtop
5c88749322d5e932013112.pngUPD6:
По просьбам трудящихся:
# df -h
Filesystem                     Size  Used Avail Use% Mounted on
/dev/md2                       1.8T  361G  1.3T  22% /
none                           4.0K     0  4.0K   0% /sys/fs/cgroup
udev                            63G  4.0K   63G   1% /dev
tmpfs                           13G  1.4M   13G   1% /run
none                           5.0M     0  5.0M   0% /run/lock
none                            63G  4.0K   63G   1% /run/shm
none                           100M     0  100M   0% /run/user
/dev/md1                       488M   92M  371M  20% /boot
/dev/mapper/megadata-verygood  880G  740G   96G  89% /data
  • Вопрос задан
  • 5449 просмотров
Подписаться 19 Сложный 10 комментариев
Решения вопроса 1
@FRiMN Автор вопроса
Решение нашлось. Как говорится ССЗБ :) На сервере были выделены HugePages, они это и были. Как выяснилось, система сразу выделяет память под HugePages, и выглядит она именно как используемая, хотя по факту может быть свободной.
Всем спасибо за участие.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 6
@metajiji
Возможно в tmpfs. Проверьте mount. Так же загляните в /dev/shm
Ответ написан
Комментировать
@rPman
Кажется htop не умеет группировать процессы, попробуйте atop
В консольном интерфейсе нажмите последовательно m а затем p (до или после нажмите a чтобы вкл/выкл отображение всех процессов а не только значимых по потреблению ресурсов)
Это включит режим сортировки по потреблению памяти а затем сгруппирует записи по одинаковому процессу (слева будет колонка с количеством) так вы найдете процесс, который запущен в нескольких копиях и по одной потребляет мало но суммарно много.

Что показывает free -g или free -m (g - гигабайты, m - мегабайты)? возможно у вас половина памяти отведена под кеш и буфера операционной системы, это нормально, она будет освобождена автоматически.
Ответ написан
@Votumchik
Если ставились на zfs, то это zfs arc cache
Ответ написан
@zersh
cat /proc/meminfo обратите внимание на SUnreclaim
если память там - то только перезагружать. насколько я знаю других вариантов нет
и так, для сравнения с другими софтинками - получить топ процессов по занимаемой памяти:
ps -eo rss,pid,user,command --sort -size | awk '{ hr=$1/1024 ; printf("%13.2f Mb ",hr) } { for ( x=4 ; x<=NF ; x++ ) { printf("%s ",$x) } print "" }' | egrep -v 0.00 |sort -n | awk '{print $1$2"  "$3 }'|tail
Ответ написан
@bkosun
Используйте этот скрипт, чтобы посмотреть список служб, которые потребляют больше всего оперативной памяти:
ps axo rss,comm,pid \
| awk '{ proc_list[$2]++; proc_list[$2 "," 1] += $1; } \
END { for (proc in proc_list) { printf("%d\t%s\n", \
proc_list[proc "," 1],proc); }}' | sort -n | tail -n 10 | sort -rn \
| awk '{$1/=1024;printf "%.0fMB\t",$1}{print $2}'
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы