LINUX.ORG.RU
Форум — Desktop  

Растет cache при долгой работе

 , , ,


0

3

Трудно сказать, после чего появилась проблема. Итак, дано: После долгой работы (месяцами не выключал комп) забивается кэш. Например если работает хром или virtualbox. При этом начинаются тормоза, т.е. как я понимаю, когда у приложения возникает потребность в памяти, система не отдает ему забитую кэшем. Значит он чем-то используется?

total       used       free     shared    buffers     cached
Mem:         14032      11658       2374       9051          5       9211
-/+ buffers/cache:       2441      11591
Swap:            0          0          0

например вот такая ситуация. сохраняется даже после sync и drop_caches (1,2,3)

ядро 

Linux ansy-desktop 3.16.0-38-generic #52~14.04.1-Ubuntu SMP Fri May 8 09:43:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux


После долгой работы (месяцами не выключал комп) забивается кэш.

вангую кучу дерьма в tmpfs

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

#df -h 

Filesystem              Size  Used Avail Use% Mounted on
udev                    6,9G   12K  6,9G   1% /dev
tmpfs                   1,4G  1,7M  1,4G   1% /run
/dev/sda5                58G  9,1G   46G  17% /
none                    4,0K     0  4,0K   0% /sys/fs/cgroup
none                    5,0M     0  5,0M   0% /run/lock
none                    6,9G   92K  6,9G   1% /run/shm
none                    100M   44K  100M   1% /run/user
/dev/mapper/truecrypt1  301G   71G  215G  25% /home/ansy
/dev/sdd1               2,8T  2,5T  238G  92% /media/ansy/Toshiba3

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

Интересненько… Я правильно понимаю, что по выводу free получается всего памяти ≈14 Гб, при этом shared ≈ 9 Гб и cached ≈ 9 Гб? WTF?!

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

Смотрите /proc/meminfo. Потом гуглите, что там какое поле обозначает и как они складываются. Подозреваю, что у вас растёт slab — какой-нибудь драйвер ядра набирает себе памяти. В этом случае, может быть, поможет вывод программы slabtop.

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

лидер сейчас firefox, пишу с него. 548Мб

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

slabtop 

 Active / Total Objects (% used)    : 3974184 / 4627999 (85,9%)
 Active / Total Slabs (% used)      : 170311 / 170311 (100,0%)
 Active / Total Caches (% used)     : 75 / 132 (56,8%)
 Active / Total Size (% used)       : 1242140,91K / 1382477,04K (89,8%)
 Minimum / Average / Maximum Object : 0,01K / 0,30K / 14,95K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME                   
798816 681860  85%    0,66K  33293       24    532688K shmem_inode_cache
624162 623726  99%    0,57K  22305       28    356880K radix_tree_node
802240 687778  85%    0,25K  50140       16    200560K kmalloc-256
893466 788696  88%    0,19K  42546       21    170184K dentry
985984 716787  72%    0,03K   7703      128     30812K kmalloc-32
252486 240577  95%    0,10K   6474       39     25896K buffer_head
 24192  24108  99%    0,75K   1152       21     18432K fuse_inode
 16784  16784 100%    0,98K   1049       16     16784K ext4_inode_cache
 11144  10143  91%    0,57K    398       28      6368K inode_cache
 30555  25344  82%    0,19K   1455       21      5820K kmalloc-192
  8375   8375 100%    0,63K    335       25      5360K proc_inode_cache
 29818  29818 100%    0,12K    877       34      3508K kernfs_node_cache
  2752   2062  74%    1,00K    172       16      2752K kmalloc-1024
 35264  22447  63%    0,06K    551       64      2204K kmalloc-64
   732    568  77%    2,55K     61       12      1952K task_struct
   352    215  61%    4,00K     44        8      1408K kmalloc-4096
   585    515  88%    2,05K     39       15      1248K idr_layer_cache
  2384   1922  80%    0,50K    149       16      1192K kmalloc-512
   560    543  96%    2,00K     35       16      1120K kmalloc-2048
 11118   9392  84%    0,08K    218       51       872K anon_vma
   972    972 100%    0,88K     54       18       864K mm_struct
  6784   6140  90%    0,12K    212       32       848K kmalloc-128
    96     81  84%    8,00K     24        4       768K kmalloc-8192
   345    327  94%    2,06K     23       15       736K sighand_cache
  1025    924  90%    0,62K     41       25       656K sock_inode_cache
 15912   9043  56%    0,04K    156      102       624K ext4_extent_status
   504    466  92%    1,12K     18       28       576K signal_cache
  2940   2940 100%    0,14K    105       28       420K ext4_groupinfo_4k
  4032   3074  76%    0,09K     96       42       384K kmalloc-96
   216    199  92%    1,75K     12       18       384K TCP
  7140   7140 100%    0,05K     84       85       336K shared_policy_node
  3472   3472 100%    0,07K     62       56       248K Acpi-ParseExt
 30720  26947  87%    0,01K     60      512       240K kmalloc-8
   250    250 100%    0,62K     10       25       160K files_cache
    80     80 100%    1,94K      5       16       160K blkdev_queue
  1610   1610 100%    0,09K     35       46       140K ftrace_event_file
   374    374 100%    0,36K     17       22       136K blkdev_requests
  1188   1188 100%    0,11K     33       36       132K task_delay_info
    56     56 100%    2,14K      4       14       128K pid_namespace
    64     64 100%    1,94K      4       16       128K TCPv6
   120    120 100%    1,06K      4       30       128K UDPv6
  7168   7168 100%    0,02K     28      256       112K kmalloc-16
  2856   2176  76%    0,04K     28      102       112K Acpi-Namespace
   294    294 100%    0,38K     14       21       112K ip6_dst_cache
   900    900 100%    0,11K     25       36       100K jbd2_journal_head
    18     18 100%    4,62K      3        6        96K net_namespace
    90     90 100%    1,06K      3       30        96K dmaengine-unmap-128
   102    102 100%    0,94K      6       17        96K UDP
очень жирный inactive, из которого большая часть AnonPages. slabtop:
MemTotal:       14369504 kB
MemFree:          224848 kB
MemAvailable:    2714900 kB
Buffers:         1051804 kB
Cached:         10393524 kB
SwapCached:            0 kB
Active:          1533048 kB
Inactive:       10980764 kB
Active(anon):    1068600 kB
Inactive(anon):  9285256 kB
Active(file):     464448 kB
Inactive(file):  1695508 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:              1148 kB
Writeback:             0 kB
AnonPages:       1068504 kB
Mapped:           196768 kB
Shmem:           9285372 kB
Slab:            1395408 kB
SReclaimable:     583488 kB
SUnreclaim:       811920 kB
KernelStack:        7968 kB
PageTables:        26312 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     7184752 kB
Committed_AS:   13309632 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      318444 kB
VmallocChunk:   34359388912 kB
HardwareCorrupted:     0 kB
AnonHugePages:    315392 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:      233024 kB
DirectMap2M:     5009408 kB
DirectMap1G:     9437184 kB

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

см внимательнее, делал, и 3, и 2, и 1. как будто что-то еще использует этот кэш

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

Большой Shmem. Там сидит tmpfs и шареная память (ipc и posix).

Раз tmpfs у вас пустые, посмотрите вывод ipcs, может там много ″Shared Memory Segments″. Если там что-то значимое, то сами проссуммируйте столбец bytes.

По posix shared memory что смотреть я не знаю.

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

2 раза по 134217728. как узнать, кто именно использует?

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0x00000000 2654208    ansy       600        393216     2          dest         
0x00000000 2752513    ansy       600        393216     2          dest         
0x00000000 2850818    ansy       600        393216     2          dest         
0x00000000 2883587    ansy       600        393216     2          dest         
0x00000000 3112964    ansy       600        393216     2          dest         
0x00000000 3145733    ansy       600        134217728  2          dest         
0xe8050365 3178502    ansy       600        8          2                       
0x00000000 3375111    ansy       600        393216     2          dest         
0x00000000 3440648    ansy       600        524288     2          dest         
0x00000000 1310729    ansy       600        524288     1          dest         
0x00000000 3670026    ansy       600        393216     2          dest         
0x00000000 9863179    ansy       600        524288     2          dest         
0x00000000 3932172    ansy       600        393216     2          dest         
0x00000000 4096013    ansy       600        393216     2          dest         
0x00000000 4128782    ansy       600        393216     2          dest         
0x00000000 4161551    ansy       600        524288     2          dest         
0x00000000 4194320    ansy       600        524288     2          dest         
0x00000000 4227089    ansy       600        393216     2          dest         
0x00000000 9895954    ansy       600        393216     2          dest         
0x00000000 4358163    ansy       600        524288     2          dest         
0x00000000 4456468    ansy       600        393216     2          dest         
0x00000000 4489237    ansy       600        524288     2          dest         
0x00000000 16875542   ansy       600        524288     2          dest         
0x00000000 11436055   ansy       600        1048576    2          dest         
0x00000000 4653080    ansy       600        2097152    2          dest         
0x00000000 4816921    ansy       600        2097152    2          dest         
0x00000000 5079066    ansy       600        393216     2          dest         
0x00000000 16908315   ansy       600        393216     2          dest         
0x00000000 13074460   ansy       600        134217728  2          dest         
0x00000000 15892509   ansy       600        393216     2          dest         
0x00000000 8650786    ansy       600        524288     2          dest         
0x00000000 10190883   ansy       600        393216     2          dest         

------ Semaphore Arrays --------
key        semid      owner      perms      nsems     

------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages
Ansy
() автор топика
Ответ на: комментарий от Ansy

как узнать, кто именно использует?

 -p, --pid         show PIDs of creator and last operator
 -c, --creator     show creator and owner
anonymous
()
Ответ на: комментарий от Ansy

2 раза по 134217728 — это мелолчи на фоне гигабайтов. Там вся сумма 285 Мбайт. Нужно изучать содержимое /proc/PID/smaps и понимать как правильно складывать, чтобы получить объём shared memory anonymous mapping.

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

Попробуйте посмотреть вывод такой команды: 

( cd /proc ; grep -h -A 3 '/dev/zero (deleted)$' [0-9]*/smaps | awk 'BEGIN{s=0} /^Pss: /{s+=$2} END{print s}' )

Если это нормально отработает и не выругается на слишком длинную командную стркоу, то должно быть число (в кБайтах), сопоставимое с Shmem из /proc/meminfo.

Если это так, то можно посмотреть какие процессы сколько потребляют такой памяти:

for i in /proc/[0-9]*/smaps ; do echo  ${i//[a-z\/]/} `grep -A 3 '/dev/zero (deleted)$' $i | awk 'BEGIN{s=0} /^Rss: /{s+=$2} END{print s}'` ; done  | sort -n -k2,2
mky ★★★★★
()
Ответ на: комментарий от mky

по первой команде вывод 5407. (Shmem:9198416 kB). по второй самое большое в конце 

25968 68
25969 68
25970 68
25971 68
25972 68
26503 68
2242 5412
2242 это апач. его остановил, сделал sync и drop_caches, все равно
             total       used       free     shared    buffers     cached
Память:   14368916   13394088     974828    9355044       1464    9510060
-/+ буферы/кэш:    3882564   10486352

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

Можно было и не делать вторую команду, 5 Мбайт это мелочь на фоне 9 Гбайт.

У вас /etc/mtab регулярный файл или ссылка на /proc/mounts? Может есть какой tmpfs, которого нет в /etc/mtab и нет в выводе ″df -h″.

Пока у меня больше нет идей, что это может быть. Поковырять бы исходники ядра, чтобы понять что ещё входит в Shmem, но не знаю, когда получится.

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

в общем что я нашел интересное: кроме ipcs есть и ipcrm, что может удалять расшаренные сегменты. Правда неизвестно с какими последствиями. А проблема решилась вообще иначе: обновил ядро до 3.19.0-32-generic. Очень изменилась работа с памятью: активнее используется buffers и самоочищается (а так же через drop_caches) кэш. Так что вывод напрашивается лишь один: кривое ядро. Почему оно оказалось как стабильное-остается только догадываться. Но с новым ядром уже третий день комп активно используется (хром и виртуалки), что обычно моментально забивало cache, и никаких проблем.

Ansy
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Desktop