kernel memory leak?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

kernel memory leak?

Alex Efros-4
Hi!

Я заметил странную вещь: через некоторое время работы значительный объём
памяти (сейчас около 300MB, но раньше вроде бывало и больше) куда-то девается.
Для проверки я остановил все процессы и сервисы кроме одной консоли, а
потом перегрузился так, чтобы загрузилась только эта консоль и сравнил
разницу по выводу free (к сожалению, я забыл сохранить /proc/meminfo до
перезагрузки, возможно причина была бы видна там).

# free
--- до перезагрузки:
             total       used       free     shared    buffers     cached
Mem:       8133928    4333624    3800304       3320      79536    3857840
-/+ buffers/cache:     396248    7737680
Swap:      8388604          0    8388604
--- после перезагрузки:
             total       used       free     shared    buffers     cached
Mem:       8133928     170700    7963228       3268      34632      46304
-/+ buffers/cache:      89764    8044164
Swap:      8388604          0    8388604

Вот список процессов до перезагрузки:

# uname -a
Linux home 3.15.10-hardened-r1 #1 SMP PREEMPT Sat Oct 25 18:56:23 EEST 2014 x86_64 Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz GenuineIntel GNU/Linux
# uptime
 07:46:43 up 2 days, 17:32,  1 user,  load average: 0.00, 0.02, 0.24
# ps axf
  PID TTY      STAT   TIME COMMAND
    2 ?        S      0:00 [kthreadd]
    3 ?        S      0:42  \_ [ksoftirqd/0]
    5 ?        S<     0:00  \_ [kworker/0:0H]
    7 ?        S      0:17  \_ [rcuc/0]
    8 ?        S      0:00  \_ [rcub/0]
    9 ?        S      1:45  \_ [rcu_preempt]
   10 ?        S      0:00  \_ [rcu_sched]
   11 ?        S      0:00  \_ [rcu_bh]
   12 ?        S      0:00  \_ [migration/0]
   13 ?        S      0:00  \_ [watchdog/0]
   14 ?        S      0:00  \_ [watchdog/1]
   15 ?        S      0:00  \_ [migration/1]
   16 ?        S      0:04  \_ [rcuc/1]
   17 ?        S      0:04  \_ [ksoftirqd/1]
   18 ?        S      0:00  \_ [kworker/1:0]
   19 ?        S<     0:00  \_ [kworker/1:0H]
   20 ?        S      0:00  \_ [watchdog/2]
   21 ?        S      0:00  \_ [migration/2]
   22 ?        S      0:04  \_ [rcuc/2]
   23 ?        S      0:04  \_ [ksoftirqd/2]
   24 ?        S      0:00  \_ [kworker/2:0]
   25 ?        S<     0:00  \_ [kworker/2:0H]
   26 ?        S      0:00  \_ [watchdog/3]
   27 ?        S      0:00  \_ [migration/3]
   28 ?        S      0:03  \_ [rcuc/3]
   29 ?        S      0:04  \_ [ksoftirqd/3]
   31 ?        S<     0:00  \_ [kworker/3:0H]
   32 ?        S      0:00  \_ [watchdog/4]
   33 ?        S      0:00  \_ [migration/4]
   34 ?        S      0:02  \_ [rcuc/4]
   35 ?        S      0:00  \_ [ksoftirqd/4]
   37 ?        S<     0:00  \_ [kworker/4:0H]
   38 ?        S      0:00  \_ [watchdog/5]
   39 ?        S      0:00  \_ [migration/5]
   40 ?        S      0:02  \_ [rcuc/5]
   41 ?        S      0:01  \_ [ksoftirqd/5]
   42 ?        S      0:00  \_ [kworker/5:0]
   43 ?        S<     0:00  \_ [kworker/5:0H]
   44 ?        S      0:00  \_ [watchdog/6]
   45 ?        S      0:00  \_ [migration/6]
   46 ?        S      0:02  \_ [rcuc/6]
   47 ?        S      0:01  \_ [ksoftirqd/6]
   48 ?        S      0:00  \_ [kworker/6:0]
   49 ?        S<     0:00  \_ [kworker/6:0H]
   50 ?        S      0:00  \_ [watchdog/7]
   51 ?        S      0:00  \_ [migration/7]
   52 ?        S      0:02  \_ [rcuc/7]
   53 ?        S      0:01  \_ [ksoftirqd/7]
   54 ?        S      0:00  \_ [kworker/7:0]
   55 ?        S<     0:00  \_ [kworker/7:0H]
   56 ?        S<     0:00  \_ [khelper]
   57 ?        S      0:00  \_ [kdevtmpfs]
   58 ?        S<     0:00  \_ [netns]
  205 ?        S      0:00  \_ [khungtaskd]
  207 ?        S<     0:00  \_ [writeback]
  214 ?        SN     0:06  \_ [khugepaged]
  219 ?        S<     0:00  \_ [bioset]
  220 ?        S<     0:00  \_ [crypto]
  223 ?        S<     0:00  \_ [kblockd]
  541 ?        S<     0:00  \_ [ata_sff]
  548 ?        S      0:00  \_ [khubd]
  558 ?        S<     0:00  \_ [edac-poller]
  662 ?        S<     0:00  \_ [kvm-irqfd-clean]
  807 ?        S      0:08  \_ [kswapd0]
  809 ?        S      0:00  \_ [fsnotify_mark]
  810 ?        S<     0:00  \_ [cifsiod]
  833 ?        S<     0:00  \_ [pencrypt]
  835 ?        S<     0:00  \_ [pdecrypt]
  898 ?        S<     0:00  \_ [acpi_thermal_pm]
 1018 ?        S      0:00  \_ [scsi_eh_0]
 1019 ?        S<     0:00  \_ [scsi_tmf_0]
 1023 ?        S      0:00  \_ [scsi_eh_1]
 1024 ?        S<     0:00  \_ [scsi_tmf_1]
 1027 ?        S      0:00  \_ [scsi_eh_2]
 1028 ?        S<     0:00  \_ [scsi_tmf_2]
 1031 ?        S      0:00  \_ [scsi_eh_3]
 1032 ?        S<     0:00  \_ [scsi_tmf_3]
 1034 ?        S      0:00  \_ [scsi_eh_4]
 1036 ?        S<     0:00  \_ [scsi_tmf_4]
 1037 ?        S      0:00  \_ [scsi_eh_5]
 1039 ?        S<     0:00  \_ [scsi_tmf_5]
 1047 ?        S      0:00  \_ [scsi_eh_6]
 1048 ?        S<     0:00  \_ [scsi_tmf_6]
 1057 ?        S      0:00  \_ [scsi_eh_7]
 1058 ?        S<     0:00  \_ [scsi_tmf_7]
 1063 ?        S      0:00  \_ [scsi_eh_8]
 1065 ?        S<     0:00  \_ [scsi_tmf_8]
 1072 ?        S      0:00  \_ [scsi_eh_9]
 1073 ?        S<     0:00  \_ [scsi_tmf_9]
 1086 ?        S      0:02  \_ [kworker/1:1]
 1114 ?        S      0:01  \_ [kworker/3:2]
 1115 ?        S      0:03  \_ [kworker/4:1]
 1449 ?        S<     0:00  \_ [deferwq]
 1477 ?        S<     0:07  \_ [kworker/0:1H]
 1478 ?        S      0:02  \_ [kworker/2:1]
 1487 ?        S      0:01  \_ [kworker/7:1]
 1505 ?        S      0:01  \_ [kworker/5:1]
 1506 ?        S      0:07  \_ [jbd2/sda5-8]
 1507 ?        S<     0:00  \_ [ext4-rsv-conver]
 1532 ?        S      0:01  \_ [kworker/6:1]
 1549 ?        S      0:00  \_ [kworker/4:2]
 1563 ?        S<     0:00  \_ [kworker/6:1H]
 1577 ?        S<     0:00  \_ [kworker/2:1H]
 1579 ?        S<     0:00  \_ [kworker/1:1H]
 1643 ?        S<     0:00  \_ [kworker/5:1H]
 1655 ?        S<     0:00  \_ [iprt]
 1659 ?        S<     0:00  \_ [kworker/7:1H]
 1681 ?        S      0:00  \_ [jbd2/sda6-8]
 1682 ?        S<     0:00  \_ [ext4-rsv-conver]
 1686 ?        S      0:00  \_ [jbd2/sda8-8]
 1687 ?        S<     0:00  \_ [ext4-rsv-conver]
 1914 ?        S<     0:00  \_ [kworker/4:1H]
 2747 ?        S<     0:00  \_ [kworker/3:1H]
 1113 ?        S      0:00  \_ [kworker/3:1]
11616 ?        S      0:01  \_ [kworker/u16:2]
 6433 ?        S      0:03  \_ [kworker/u16:1]
27043 ?        S      0:00  \_ [kworker/0:1]
29191 ?        S      0:00  \_ [kworker/0:0]
22746 ?        S      0:00  \_ [kworker/0:2]
    1 ?        Ss     0:03 runit
 1791 ?        Ss     0:02 runsvdir -P /var/service log: ...........................................................................................................................................................................................................................................................................................................................................................................................................
 1797 ?        Ss     0:00  \_ runsv agetty-tty1
 1873 tty1     Ss     0:00      \_ /bin/login --    
29069 tty1     S      0:00          \_ -bash
22770 tty1     R+     0:00              \_ /bin/ps axf

Теоретически утечка ещё может быть в модулях ядра, но lsmod до
перезагрузки я тоже забыл сделать, а после вот:

# lsmod
Module                  Size  Used by
vboxnetadp             19086  0
vboxnetflt             16322  0
vboxdrv              1809597  2 vboxnetadp,vboxnetflt
nvidia_uvm             42587  0
nvidia              11013337  31 nvidia_uvm

Других модулей (читай - руткитов) добавиться в процессе работы не могло -
после загрузки системы загрузка новых модулей ядра блокируется через
sysctl (/proc/sys/kernel/modules_disabled).

Есть идеи чем это может быть вызвано и на что ещё обратить внимание в
следующий раз (кроме lsmod и /proc/meminfo)?

--
                        WBR, Alex.

Reply | Threaded
Open this post in threaded view
|

Re: kernel memory leak?

Dmitry Podkovyrkin

05.12.2014 11:19,Обратите внимание на cached.
Память в Used - это память занятая процессами и + всякие буферы, кеши.
Когда вы запускаете какой-либо процесс, например ls, то после отработки
этого процесса он не убирается полностью из памяти, а остается там
готовый к следующему запуску. Поэтому первый запуск программы медленнее
следующих, если конечно памяти хватает.

Когда free подходит к концу, то система начинает удалять данные из
cached и освобождает память.
Установите, например, htop - он показывает сколько в занятой памяти
используется реально, а сколько занято старыми данными.

Alex Efros пишет:

> Hi!
>
> Я заметил странную вещь: через некоторое время работы значительный объём
> памяти (сейчас около 300MB, но раньше вроде бывало и больше) куда-то девается.
> Для проверки я остановил все процессы и сервисы кроме одной консоли, а
> потом перегрузился так, чтобы загрузилась только эта консоль и сравнил
> разницу по выводу free (к сожалению, я забыл сохранить /proc/meminfo до
> перезагрузки, возможно причина была бы видна там).
>
> # free
> --- до перезагрузки:
>               total       used       free     shared    buffers     cached
> Mem:       8133928    4333624    3800304       3320      79536    3857840
> -/+ buffers/cache:     396248    7737680
> Swap:      8388604          0    8388604
> --- после перезагрузки:
>               total       used       free     shared    buffers     cached
> Mem:       8133928     170700    7963228       3268      34632      46304
> -/+ buffers/cache:      89764    8044164
> Swap:      8388604          0    8388604
>
>

Reply | Threaded
Open this post in threaded view
|

Re: kernel memory leak?

Alex Efros-4
Hi!

On Fri, Dec 05, 2014 at 11:40:08AM +0500, Dmitry Podkovyrkin wrote:
> Память в Used - это память занятая процессами и + всякие буферы, кеши.

Это в первой строчке. А во второй - за вычетом буферов с кешей, и я
говорил именно о первом числе второй строки. htop показывает то же самое.

> > # free
> > --- до перезагрузки:
> >               total       used       free     shared    buffers     cached
> > Mem:       8133928    4333624    3800304       3320      79536    3857840
> > -/+ buffers/cache:     396248    7737680
> > Swap:      8388604          0    8388604
> > --- после перезагрузки:
> >               total       used       free     shared    buffers     cached
> > Mem:       8133928     170700    7963228       3268      34632      46304
> > -/+ buffers/cache:      89764    8044164
> > Swap:      8388604          0    8388604

--
                        WBR, Alex.

Reply | Threaded
Open this post in threaded view
|

Re: kernel memory leak?

Andrey Utkin
Посмотрите выдачу ps axfu


--
Andrey Utkin
Reply | Threaded
Open this post in threaded view
|

Re: kernel memory leak?

Kanstantsin Shautsou
Смотреть нужно cat /proc/meminfo , без него гадать нет смысла
> On Dec 5, 2014, at 13:32 , Andrey Utkin <[hidden email]> wrote:
>
> Посмотрите выдачу ps axfu
>
>
> --
> Andrey Utkin


Reply | Threaded
Open this post in threaded view
|

Re: kernel memory leak?

Alex Efros-4
Hi!

Это снова произошло, до/после перезагрузки, при всех убитых процессах
кроме одного agetty и bash:

# free
             total       used       free     shared    buffers     cached
Mem:       8133844    1482196    6651648       7808     151204     768648
-/+ buffers/cache:     562344    7571500
Swap:      8388604          0    8388604

# free
             total       used       free     shared    buffers     cached
Mem:       8133844     157064    7976780       3284      31468      41448
-/+ buffers/cache:      84148    8049696
Swap:      8388604          0    8388604


On Fri, Dec 05, 2014 at 02:03:07PM +0300, Kanstantsin Shautsou wrote:
> > Посмотрите выдачу ps axfu

Там различий не видно. В выводе lsmod тоже.

> Смотреть нужно cat /proc/meminfo , без него гадать нет смысла

            до перезагрузки     после перезагрузки
MemTotal:        8133844 kB     8133844 kB
MemFree:         6651912 kB     7987332 kB
MemAvailable:    7745684 kB     7937240 kB
Buffers:          151220 kB       21664 kB
Cached:           768656 kB       40992 kB
SwapCached:            0 kB           0 kB
Active:           504876 kB       44260 kB
Inactive:         421320 kB       24636 kB
Active(anon):       6192 kB        6332 kB
Inactive(anon):     7948 kB        3208 kB
Active(file):     498684 kB       37928 kB
Inactive(file):   413372 kB       21428 kB
Unevictable:           0 kB           0 kB
Mlocked:               0 kB           0 kB
SwapTotal:       8388604 kB     8388604 kB
SwapFree:        8388604 kB     8388604 kB
Dirty:                 0 kB          64 kB
Writeback:             0 kB           0 kB
AnonPages:          6372 kB        6208 kB
Mapped:             4316 kB        4948 kB
Shmem:              7808 kB        3284 kB
Slab:             499488 kB       29064 kB
SReclaimable:     435132 kB        9400 kB
SUnreclaim:        64356 kB       19664 kB
KernelStack:        2096 kB        2272 kB
PageTables:          368 kB         312 kB
NFS_Unstable:          0 kB           0 kB
Bounce:                0 kB           0 kB
WritebackTmp:          0 kB           0 kB
CommitLimit:    12455524 kB    12455524 kB
Committed_AS:      19008 kB       10160 kB
VmallocTotal:   34359738367 kB 34359738367 kB
VmallocUsed:       92052 kB       90420 kB
VmallocChunk:   34359591888 kB 34359636956 kB
AnonHugePages:         0 kB           0 kB
HugePages_Total:       0              0
HugePages_Free:        0              0
HugePages_Rsvd:        0              0
HugePages_Surp:        0              0
Hugepagesize:       2048 kB        2048 kB
DirectMap4k:     1665224 kB       14536 kB
DirectMap2M:     6680576 kB     8331264 kB

Похоже на то, что большая часть "потерявшейся" памяти находится в
SReclaimable, т.е. теоретически она всё-таки должна быть доступна, хоть
free этого и не показывает, а оставшиеся примерно 10% в SUnreclaim.

Так что, получается, всё в порядке? Память не утекает, просто free даже в
"-/+ buffers/cache" выдаёт бесполезную информацию?

--
                        WBR, Alex.