On Wed, Feb 15, 2006 at 01:30:00PM -0800, Konstantin K wrote:
> Hello,
>
> we have a massively multithreaded daemon(more than 100lpws) running on
> solaris 9, E25000, 64 bit. we use umem via LD_PRELOAD_64, ie there are no
> explicit calls to umem. it performs fine during the day, however at the start
> of real work, when data start to come in, a lot of threads (10-15) have
> following top of the stack:
>
> ffffffff7d618370 lwp_park (0, 0, 0)
> ffffffff7d613ed0 mutex_lock_queue (ffffffff7d71b8b8, 0, ffffffff7d5c01e8,
> 0, 0, 0) + 104
> ffffffff7d61490c slow_lock (ffffffff7d5c01e8, ffffffff6c806400,
> ffffffff7f3302b8, 0, 0, 0) + 58
> ffffffff7d4a0bf4 _sbrk_grow_aligned (10000, 2000, 2000, ffffffff6ad394b8,
> 0, 0) + 5c
> ffffffff7f212b00 vmem_sbrk_alloc (ffffffff7f32ff40, 2000, 1, 0, 0, 40) + b4
> ffffffff7f21937c vmem_xalloc (ffffffff7f322000, 0, ffffffff7f330ec0, 0,
> ffffffff7f330b78, 2) + 5d4
> ffffffff7f2199c8 vmem_alloc (ffffffff7f330b48, 2000, 1, 0, 0, 0) + 258
> ffffffff7f21937c vmem_xalloc (ffffffff7f322000, 0, 10084e378, 0,
> 10084e030, 2) + 5d4
> ffffffff7f2199c8 vmem_alloc (10084e000, 2000, 1, 0, 0, 0) + 258
> ffffffff7f213de4 umem_slab_create (100858a68, 0, 0, 0, 0, 0) + 64
> ffffffff7f2141d8 umem_slab_alloc (100858a68, 0, 0, 0, 0, 0) + 88
> ffffffff7f2151bc umem_cache_alloc (1008590c0, 0, 0, 0, 0, 0) + fc
> ffffffff7f215624 umem_alloc (139, 0, 2000, 40, ffffffffffffffff, 40) + 3c
> ffffffff7f211690 malloc (129, ffffffff6ad3de60, 2000, 0,
> ffffffff7d5bc668, 0) + 28
>
> and our daemon hangs for about 1m.
>
>
> is it a known issue?
> is there any way to make it better on initial allocation?
One option is to set the sbrk pagesize larger:
UMEM_OPTIONS=sbrk_pagesize=524288
(any value from "pagesize -a" will do)
This will cause larger chunks of allocations to happen, which should lower
the number of allocations necessary.
I'm currently working on a fix to:
6304072 libumem seems to use more heap than it needs
part of which is doing the above line-up in a more sensible fashion, so
that you don't have everyone piled up on the lock.
Cheers,
- jonathan
--
Jonathan Adams, Solaris Kernel Development
_______________________________________________
perf-discuss mailing list
[email protected]
