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 perf-discuss@opensolaris.org