View previous topic :: View next topic |
Author |
Message |
wuesti Apprentice
Joined: 07 Mar 2009 Posts: 191
|
Posted: Thu Sep 26, 2013 5:19 pm Post subject: [solved] /usr/bin/du müllt den Arbeitsspeicher voll. |
|
|
Moin Moin,
wenn ich mein System gestartet habe, benutzt es folgenden Speicher: Code: | free -m
total used free shared buffers cached
Mem: 3952 287 3665 0 33 139
-/+ buffers/cache: 114 3838
Swap: 4612 0 4612 |
Lange Zeit habe ich gesucht, um herauszufinden, welches Programm den Speicher voll müllt. Manchmal habe ich, obwohl der user abgemeldet ist, schon 1 gB Speicherverbrauch. Nun habe ich den Überltäter:
Mach ich ein habe ich plötzlich 800mB mehr Arbeitsspeicher belegt. Code: | free -m
total used free shared buffers cached
Mem: 3952 2868 1083 0 312 1628
-/+ buffers/cache: 928 3024
Swap: 4612 1 4610 |
Dass mehr Cache und insbesondere Buffers belegt wird, ist klar. Aber von wem und wofür ist der Arbeitsspeicher belegt?
Vielen Dank
wuesti
Last edited by wuesti on Sun Sep 29, 2013 7:27 am; edited 1 time in total |
|
Back to top |
|
|
kernelOfTruth Watchman
Joined: 20 Dec 2005 Posts: 6111 Location: Vienna, Austria; Germany; hello world :)
|
|
Back to top |
|
|
wuesti Apprentice
Joined: 07 Mar 2009 Posts: 191
|
Posted: Fri Sep 27, 2013 1:41 pm Post subject: |
|
|
kernelOfTruth wrote: | was sagt
cat /proc/meminfo |
Code: | Vorher Nachher
MemTotal: 4047828kB 4047828kB
MemFree: 3752100kB 2446240kB
Buffers: 34060kB 493140kB
Cached: 144500kB 146244kB
SwapCached: 0kB 0kB
Active: 121176kB 430344kB
Inactive: 125672kB 277972kB
Active(anon): 68484kB 69128kB
Inactive(anon): 956kB 964kB
Active(file): 52692kB 361216kB
Inactive(file): 124716kB 277008kB
Unevictable: 0kB 0kB
Mlocked: 0kB 0kB
SwapTotal: 4723036kB 4723036kB
SwapFree: 4723036kB 4723036kB
Dirty: 40kB 8kB
Writeback: 0kB 0kB
AnonPages: 68456kB 68984kB
Mapped: 37652kB 37668kB
Shmem: 1136kB 1136kB
Slab: 19540kB 863128kB
SReclaimable: 8924kB 840592kB
SUnreclaim: 10616kB 22536kB
KernelStack: 1288kB 1240kB
PageTables: 3064kB 3064kB
NFS_Unstable: 0kB 0kB
Bounce: 0kB 0kB
WritebackTmp: 0kB 0kB
CommitLimit: 6746948kB 6746948kB
Committed_AS: 236208kB 236840kB
VmallocTotal: 34359738367kB 34359738367kB
VmallocUsed: 100988kB 100988kB
VmallocChunk: 34359622139kB 34359622139kB
DirectMap4k: 31616kB 31616kB
DirectMap2M: 4161536kB 4161536kB
|
Quote: | ist slab dermaßen stark angestiegen ?
slabtop |
Vorher:
Code: | Active / Total Objects (% used) : 80294 / 81464 (98,6%)
Active / Total Slabs (% used) : 2504 / 2504 (100,0%)
Active / Total Caches (% used) : 60 / 92 (65,2%)
Active / Total Size (% used) : 18858,43K / 19164,60K (98,4%)
Minimum / Average / Maximum Object : 0,01K / 0,23K / 12,00K
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
14400 14400 100% 0,11K 400 36 1600K sysfs_dir_cache
9906 9906 100% 0,10K 254 39 1016K buffer_head
9261 9261 100% 0,19K 441 21 1764K dentry
5952 5451 91% 0,06K 93 64 372K kmalloc-64
4096 4096 100% 0,01K 8 512 32K kmalloc-8
3266 3073 94% 0,17K 142 23 568K vm_area_struct
2839 2839 100% 0,91K 167 17 2672K ext4_inode_cache
2640 2640 100% 0,13K 88 30 352K ext4_allocation_context
2624 2624 100% 0,06K 41 64 164K anon_vma
2560 2560 100% 0,02K 10 256 40K kmalloc-16
2520 2520 100% 0,53K 84 30 1344K inode_cache
2324 2324 100% 0,55K 83 28 1328K radix_tree_node
1932 1715 88% 0,19K 92 21 368K kmalloc-192
1836 1836 100% 0,04K 18 102 72K ext4_extent_status
1456 1456 100% 0,07K 26 56 104K Acpi-ParseExt
1408 1164 82% 0,25K 88 16 352K kmalloc-256 |
Nachher:
Code: | Active / Total Objects (% used) : 1900344 / 1901878 (99,9%)
Active / Total Slabs (% used) : 85874 / 85874 (100,0%)
Active / Total Caches (% used) : 60 / 92 (65,2%)
Active / Total Size (% used) : 834457,29K / 835287,46K (99,9%)
Minimum / Average / Maximum Object : 0,01K / 0,44K / 12,00K
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
732144 732144 100% 0,19K 34864 21 139456K dentry
701403 701403 100% 0,91K 41259 17 660144K ext4_inode_cache
196352 196352 100% 0,06K 3068 64 12272K kmalloc-64
124098 124098 100% 0,10K 3182 39 12728K buffer_head
56406 56406 100% 0,04K 553 102 2212K ext4_extent_status
16884 16884 100% 0,55K 603 28 9648K radix_tree_node
14400 14400 100% 0,11K 400 36 1600K sysfs_dir_cache
14280 14280 100% 0,53K 476 30 7616K inode_cache
13286 12308 92% 0,59K 511 26 8176K proc_inode_cache
4096 4096 100% 0,01K 8 512 32K kmalloc-8
3266 3073 94% 0,17K 142 23 568K vm_area_struct
2640 2640 100% 0,13K 88 30 352K ext4_allocation_context
2624 2624 100% 0,06K 41 64 164K anon_vma
2560 2560 100% 0,02K 10 256 40K kmalloc-16
1974 1974 100% 0,09K 47 42 188K kmalloc-96
1869 1698 90% 0,19K 89 21 356K kmalloc-192 |
Ok, der starke Anstieg von ext4_inode_cache von 2672K auf 660144K sagt mir, dass jede inode, die angefasst wird, im Speicher "normalen Speicher" und nicht im "Cache-Bereich" gespeichert wird. Dann stellt sich die Frage, ob der Speicher auch wieder freigegeben wird, wenn die zur inode gehörende Datei aus dem "Cache-Bereich" fällt. |
|
Back to top |
|
|
kernelOfTruth Watchman
Joined: 20 Dec 2005 Posts: 6111 Location: Vienna, Austria; Germany; hello world :)
|
Posted: Sat Sep 28, 2013 7:57 pm Post subject: |
|
|
wird es,
das ganze wird über
/proc/sys/vm/vfs_cache_pressure
/proc/sys/vm/dirty_background*
/proc/sys/vm/dirty_ratio
gesteuert:
http://bjdean.id.au/wiki/LinuxMemoryManagement
Quote: | Reducing inode/dentry time in the cache: /proc/sys/vm/vfs_cache_pressure
Controls the tendency of the kernel to reclaim the memory which is used for
caching of directory and inode objects.
At the default value of vfs_cache_pressure=100 the kernel will attempt to
reclaim dentries and inodes at a "fair" rate with respect to pagecache and
swapcache reclaim. Decreasing vfs_cache_pressure causes the kernel to prefer
to retain dentry and inode caches. When vfs_cache_pressure=0, the kernel will
never reclaim dentries and inodes due to memory pressure and this can easily
lead to out-of-memory conditions. Increasing vfs_cache_pressure beyond 100
causes the kernel to prefer to reclaim dentries and inodes. |
je kleiner vfs_cache_pressure also ist, desto eher wächst der slab für z.B. die inodes, dentry und den ext4_inode_cache
bei höheren Werten (Andrew Morton (?) benutzt Werte um 1000, 10000, etc. - wenn ich mich richtig erinnere das einmal im Netz gelesen zu haben) wird der Speicher
wieder schneller freigeräumt, andererseits erhöht dies allerdings auch die Belastung in diesem Teil/Unter-System ("Subsystem") des Kernels
ich persönlich für meinen Desktop nutze z.B. 50 bei vfs_cache_pressure und etwas großzügigere Werte beim Caching, da dies im Betrieb über einige Stunden die Arbeit mit dem Browsen in Ordnern etwas beschleunigt, wenn alles (schon) im Speicher gehalten wird
ehe ich was Falsches schreibe, können die Kernel-Profis ihren Senf dazu abgeben _________________ https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa
Hardcore Gentoo Linux user since 2004 |
|
Back to top |
|
|
wuesti Apprentice
Joined: 07 Mar 2009 Posts: 191
|
Posted: Sun Sep 29, 2013 7:27 am Post subject: |
|
|
kernelOfTruth wrote: | wird es,
das ganze wird über
/proc/sys/vm/vfs_cache_pressure
...
gesteuert: |
Das Ganze kommt der Sache schon näher. Mit einem Wert von 1000 werden die Caches geleert, bevor geswapt wird. Beim Standardwert 100 ist es umgekehrt.
Ich werde mich mal an den für mich passenden Wert herantasten.
Vielen Dank
wuesti _________________ Linux-User seit 1999 |
|
Back to top |
|
|
bell Guru
Joined: 27 Nov 2007 Posts: 508
|
Posted: Sun Sep 29, 2013 6:24 pm Post subject: |
|
|
Zum Testen ob der Speicher wieder frei wird, kannst Du folgendes testen, ob daduch der Speicher wieder frei wird:
|
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|