A dtrace script shows that there are a lot of shell scripts (perl, sh, awk,
grep etc.) running on the system calling kmem_alloc() , they are mostly the
database monitoring/operation scripts running inside each zone (aoubt 7 zones)
almost every minute.
But I wonder can this be the problem? (claiming 55% of memory in kmem_alloc_xxx
buffers, which totals at about 16GB! ) Didn't those "simple" exec (ps, perl,
grep, prtdiag etc.) free the buffers/memory when they exit?
What is more, as my understanding, the dtrace scripts we run only monitor those
exec calling kmem_alloc at the time while the dtrace script is running, what
about those exec already have kmem_alloc_xx buffers allocated and in use?
Thank you so much for any advise.
# dtrace -n 'fbt::kmem_alloc:entry {...@a[execname, stack()] = sum(args[0]); }
END {trunc(@a,20)}'
*******************************
CPU ID FUNCTION:NAME
18 2 :END
Mountmonitor
genunix`pn_alloc+0xc
genunix`resolvepath+0x38
unix`syscall_trap32+0xcc
10092544
netstat
genunix`kmem_zalloc+0xe8
kstat`read_kstat_data+0x1cc
genunix`fop_ioctl+0x20
genunix`ioctl+0x184
unix`syscall_trap32+0xcc
11715891
grep
genunix`pn_alloc+0xc
genunix`resolvepath+0x38
unix`syscall_trap32+0xcc
11846656
grep
genunix`pn_get+0x8
genunix`resolvepath+0x24
unix`syscall_trap32+0xcc
11846656
svcs
doorfs`door_args+0x60
doorfs`door_call+0x2f4
unix`syscall_trap32+0xcc
12651008
perl
genunix`pn_get+0x8
genunix`resolvepath+0x24
unix`syscall_trap32+0xcc
14082048
perl
genunix`pn_alloc+0xc
genunix`resolvepath+0x38
unix`syscall_trap32+0xcc
14082048
sh
genunix`pn_get+0x8
genunix`resolvepath+0x24
unix`syscall_trap32+0xcc
16314368
sh
genunix`pn_alloc+0xc
genunix`resolvepath+0x38
unix`syscall_trap32+0xcc
16314368
perl
genunix`pn_get+0x8
genunix`lookupnameat+0x78
genunix`vn_openat+0x16c
genunix`copen+0x260
unix`syscall_trap32+0xcc
19551232
perl
genunix`exec_args+0xac
elfexec`elf32exec+0x31c
genunix`gexec+0x374
genunix`exec_common+0x278
genunix`exece+0xc
unix`syscall_trap32+0xcc
20652032
ps
genunix`pn_alloc+0xc
genunix`lookuppnvp+0x404
genunix`lookuppnat+0x120
genunix`resolvepath+0x50
unix`syscall_trap+0xac
20723712
ps
genunix`pn_alloc+0xc
genunix`resolvepath+0x38
unix`syscall_trap+0xac
22519808
ps
genunix`pn_get+0x8
genunix`resolvepath+0x24
unix`syscall_trap+0xac
22519808
perl
genunix`pn_get+0x8
genunix`lookupnameat+0x78
genunix`cstatat_getvp+0x198
genunix`cstatat64_32+0x40
unix`syscall_trap32+0xcc
23332864
ps
genunix`pn_alloc+0xc
genunix`lookuppnvp+0x404
genunix`lookuppnat+0x120
genunix`lookupnameat+0x5c
genunix`cstatat_getvp+0x198
genunix`cstatat+0x40
unix`syscall_trap+0xac
23918592
ps
genunix`pn_alloc+0xc
genunix`lookuppnvp+0x404
genunix`lookuppnat+0x120
genunix`lookupnameat+0x5c
genunix`vn_openat+0x16c
genunix`copen+0x260
unix`syscall_trap+0xac
24594432
sh
genunix`exec_args+0xac
elfexec`elf32exec+0x31c
genunix`gexec+0x374
genunix`exec_common+0x278
genunix`exece+0xc
unix`syscall_trap32+0xcc
33316864
prtdiag
genunix`kmem_zalloc+0xe8
openeepr`opromioctl_cb+0x688
unix`prom_tree_access+0x54
openeepr`opromioctl+0x50
genunix`fop_ioctl+0x20
genunix`ioctl+0x184
unix`syscall_trap32+0xcc
36992810
ldap_cachemgr
doorfs`door_results+0x1a0
doorfs`door_return+0xb0
unix`syscall_trap32+0xcc
51768784
--
This message posted from opensolaris.org
_______________________________________________
perf-discuss mailing list
[email protected]