LINUX.ORG.RU
решено Форум — Development  

Где-то течет, а где - хз!

 


0

3

Салют, ЛОР!

На железке течет память. Не могу понять, из-за чего именно.
В /tmp/ нет никаких больших файлов.
top/htop говорят, что все ок.

Вот вывод free: 

              total  used  free  shared buffer
Mem:          125576 81820 43756 436    0
-/+ buffers:         81820 43756
Swap:         0      0     0

Динамика следующая(занято Кб):

  • день 1: 33500
  • день 2: 40800
  • день 5: 62200
  • день 6: 71500
  • день 7: 80000

Как можно задетектить утечку?



Последнее исправление: vgovseychuk (всего исправлений: 1)
← ido vs helm
Исключения в rand() →
Ответ на: комментарий от WRG

В том-то и дело, что htop не показывает, что где-то что-то увеличивается.

vgovseychuk
() автор топика

Браузер, небось, постоянно запущен? У меня вот такое - норма: 

 3445 eddy      20   0 2555m 1.2g  93m S   2.0 19.9 847:46.63 firefox

anonymous
()
Ответ на: комментарий от greenman

Тьфу, не обратил внимания.

Тогда надо по top'у сравнивать, что потихоньку жиреет. Возможно, какой-нибудь самопальный демон подтекает или суммируется эффект от кучи сервисов (те же иксы, если запущены на этой железяке, тоже жиреть имеют свойство).

anonymous
()

Кеши дропать пробовал?

feofan ★★★★★
()
Ответ на: комментарий от anonymous

Судя по размеру памяти и тегам ТС, там что-то типа openwrt.

openwrt memory leak — запрос даёт немало результатов. Часто утечка в модулях ядра, можно ли её выловить...

greenman ★★★★★
()
Ответ на: комментарий от greenman

Как верно догадался анон, на железе OpenWRT. Приложу два набора инфы:
Сначала: 

             total         used         free       shared      buffers
Mem:        125576        78268        47308          336            0
-/+ buffers:              78268        47308
Swap:            0            0            0

Mem: 78300K used, 47276K free, 340K shrd, 0K buff, 9836K cached
CPU:   4% usr   7% sys   0% nic  87% idle   0% io   0% irq   0% sirq
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
11403  3373 root     R     1376   1%   1% top
 2582     1 root     S     1208   1%   1% /sbin/netlogger
   51     2 root     SW       0   0%   0% [kworker/0:1]
 1874     1 root     S     1416   1%   0% /sbin/netifd
 1832     1 root     S      952   1%   0% /sbin/logd -S 16
    3     2 root     SW       0   0%   0% [ksoftirqd/0]
 2605     1 root     S     4268   3%   0% /usr/local/bin/smsd -n MAINPROCESS -p
 2465     1 ntp      S     3048   2%   0% /sbin/ntpd -g -u ntp:ntp -p /var/run/
 1925     1 root     S     2788   2%   0% /usr/sbin/racoon -F -f /etc/racoon.co
 2382     1 root     S     1532   1%   0% /usr/sbin/uhttpd -f -h /www -r
11463  1874 root     S     1500   1%   0% /usr/sbin/pppd nodetach ipparam inter
 1841     1 root     S     1460   1%   0% /sbin/rpcd
 3373     1 root     S     1380   1%   0% /bin/ash --login
 9618  9497 root     S     1376   1%   0% -ash
11464 11463 root     S     1372   1%   0% sh -c USE_APN=internet DIALNUMBER=*99
    1     0 root     S     1332   1%   0% /sbin/procd
 9497  2169 root     S     1116   1%   0% /usr/sbin/dropbear -F -P /var/run/dro
 1907     1 root     S     1084   1%   0% /usr/sbin/odhcpd
 2169     1 root     S     1048   1%   0% /usr/sbin/dropbear -F -P /var/run/dro
 2732     1 nobody   S      888   1%   0% /usr/sbin/dnsmasq -C /var/etc/dnsmasq
Спустя пару дней: 
             total         used         free       shared      buffers
Mem:        125576        36268        89308          440            0
-/+ buffers:              36268        89308
Swap:            0            0            0

Mem: 36192K used, 89384K free, 440K shrd, 0K buff, 9984K cached
CPU:   5% usr   5% sys   0% nic  88% idle   0% io   0% irq   0% sirq
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
 1875     1 root     S     1416   1%   0% /sbin/netifd
 7877   490 root     R     1376   1%   0% top
 1833     1 root     S      952   1%   0% /sbin/logd -S 16
    3     2 root     SW       0   0%   0% [ksoftirqd/0]
 2587     1 root     S     4268   3%   0% /usr/local/bin/smsd -n MAINPROCESS -p
 2465     1 ntp      S     3044   2%   0% /sbin/ntpd -g -u ntp:ntp -p /var/run/
 1924     1 root     S     2788   2%   0% /usr/sbin/racoon -F -f /etc/racoon.co
 2384     1 root     S     1540   1%   0% /usr/sbin/uhttpd -f -h /www -r
 1842     1 root     S     1460   1%   0% /sbin/rpcd
 7897  1875 root     S     1444   1%   0% {3g.sh} /bin/sh ./3g.sh 3g setup inte
  490     1 root     S     1380   1%   0% /bin/ash --login
 6731  6660 root     S     1376   1%   0% -ash
    1     0 root     S     1332   1%   0% /sbin/procd
 6660  2197 root     S     1116   1%   0% /usr/sbin/dropbear -F -P /var/run/dro
 1908     1 root     S     1084   1%   0% /usr/sbin/odhcpd
 2197     1 root     S     1048   1%   0% /usr/sbin/dropbear -F -P /var/run/dro
 2717     1 nobody   S      888   1%   0% /usr/sbin/dnsmasq -C /var/etc/dnsmasq
  452     1 root     S      804   1%   0% /sbin/ubusd
 7899  7897 root     S      756   1%   0% gcom -d /dev/ttyACM0 -s /etc/gcom/get
   51     2 root     SW       0   0%   0% [kworker/0:1]

vgovseychuk
() автор топика
Ответ на: комментарий от greenman

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

vgovseychuk
() автор топика
Ответ на: комментарий от vgovseychuk

Так судя по вашим выводам top'а,
спустя пару дней значение free увеличилось :)

Dead ★★★★
()
Ответ на: комментарий от vgovseychuk

А есть вариант это как-то увидеть?

Гугл находит несколько методик :)
Честно говоря, не пробовал их.

Dead ★★★★
()
Ответ на: комментарий от vgovseychuk

Еще интересно, почему у free и top отсутствует параметр cached.

Dead ★★★★
()
Ответ на: комментарий от vgovseychuk

Ок. Буду вкуривать тогда дальше. Если найду причину, отпишусь.

У меня бывало нечто подобное, но оно было связано с работой с носителями данных, в результате чего страничный кэш забирал много памяти. Я не знаю, работает ли ваше устройство с носителям (USB/SATA/MMC/SD). А также непонятно почему free и top не показывают текущий размер страничного кэша.

Что говорит команда cat /proc/meminfo ?

Dead ★★★★
()
Последнее исправление: Dead (всего исправлений: 1)

Советую установить размер swap не менее размера оперативной памяти...

anonymous
()
Ответ на: комментарий от anonymous

Советую установить размер swap не менее размера оперативной памяти...

Какой может быть swap на железке с OpenWRT?

Dead ★★★★
()
Ответ на: комментарий от Dead

А также непонятно почему free и top не показывают текущий размер страничного кэша.

В OpenWrt много что порезано. Часть утилит в составе busybox, так что это нормально.
9984K cached - это не оно, разве?

Что говорит команда cat /proc/meminfo ?

MemTotal:         125576 kB
MemFree:           53032 kB
MemAvailable:      90840 kB
Buffers:               0 kB
Cached:             9680 kB
SwapCached:            0 kB
Active:            11796 kB
Inactive:           3896 kB
Active(anon):       6500 kB
Inactive(anon):       92 kB
Active(file):       5296 kB
Inactive(file):     3804 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:          6036 kB
Mapped:             2740 kB
Shmem:               580 kB
Slab:              43648 kB
SReclaimable:      34012 kB
SUnreclaim:         9636 kB
KernelStack:         392 kB
PageTables:          296 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:       62788 kB
Committed_AS:      10212 kB
VmallocTotal:     892928 kB
VmallocUsed:        5792 kB
VmallocChunk:     873652 kB
vgovseychuk
() автор топика
Ответ на: комментарий от vgovseychuk

Если в ядре течет, то можно попробовать понаблюдать за /proc/slabinfo

vel ★★★★★
()

Есть ясность какой процесс кушает? У меня была проблема, так я ее решал скриптом, который раз в минуту дергает ps с кучей параметров касательно памяти, и потом смотрел где увеличивается.

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от vgovseychuk

По идее нужны /proc/meminfo и /proc/slabinfo до и после того как случилась утечка. По одному снимку ничего не сказать.

GPFault ★★
()

Вызовите слесаря!

anonymous
()
Ответ на: комментарий от GPFault

По идее нужны /proc/meminfo и /proc/slabinfo до и после того как случилась утечка.

Сделал. Основные различия:(извиняюсь, если табуляция поплывет)

meminfo

До: 

Shmem:               440 kB
Slab:               8664 kB
SReclaimable:       2052 kB
SUnreclaim:         6612 kB

После:

Shmem:               580 kB
Slab:              43772 kB
SReclaimable:      34164 kB
SUnreclaim:         9608 kB


slabinfo

До: 

# name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>

dentry              5370   5370    136   30    1 : tunables  120   60    0 : slabdata    179 	179      0
kmalloc-32         13556  13764     32  124    1 : tunables  120   60    0 : slabdata    111	111      0

После:

# name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>

dentry            244830 244830    136   30    1 : tunables  120   60    0 : slabdata   8161   8161      0
kmalloc-32         99896 103540     32  124    1 : tunables  120   60    0 : slabdata    835    835      0
vgovseychuk
() автор топика
Ответ на: комментарий от vgovseychuk

Я пользовался таким скриптом
http://pastebin.com/vq8x8anY
Запускал командой 

sh memtrack.sh > /mnt/flash_drive/log.txt
Он каждые 10минут сохраняет список процессов и количество страниц для каждого PID. А потом из этого лога грепал значения в csv, открывал в libreoffice calc, и строил красивые красивые графики.
Но, если у тебя течет ядро, то этот скрипт тебе наверное не поможет.

pftBest ★★★★
()
Последнее исправление: pftBest (всего исправлений: 1)
Ответ на: комментарий от vgovseychuk

c dentry все понятно, а вот кто такой kmalloc-32 - найти не просто.

Версия ядра какая? Если есть возможность обновить ядро - обнови.

Против большого dentry должно помогать vm.vfs_cache_pressure=10000 и периодическое «echo 2 > /proc/sys/vm/drop_caches»

vel ★★★★★
()
Ответ на: комментарий от vel

Версия ядра какая?

3.18.29, последняя на данный момент 3.18.42. Попробую. В принципе, вычищение кэшей echo 3 > /proc/sys/vm/drop_caches сильно уменьшает kmalloc-32: до 20000 объектов. Правда, что дальше будет, через пару месяцев, неясно. Поставил на всякий пожарный vm.panic_on_oom=1

В любом случае большое спасибо за помощь!

vgovseychuk
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← ido vs helm
Development
Исключения в rand() →