On 11/6/06, Vinod Panicker <[EMAIL PROTECTED]> wrote:
On 11/6/06, Robert Greig <[EMAIL PROTECTED]> wrote:
> On 06/11/06, Vinod Panicker <[EMAIL PROTECTED]> wrote:
> > On 11/6/06, Robert Greig <[EMAIL PROTECTED]> wrote:
> > > On 06/11/06, Vinod Panicker <[EMAIL PROTECTED]> wrote:
> > >
> > > > I've been running load tests on my app, which is running against mina
> > > > 1.1.0-SNAPSHOT using java.util.concurrent on a JDK 6 VM. The server is
> > > > a 2-way Opteron with 6 gigs of RAM.
> > >
> > > Are you using direct buffers, and are you using pooled buffers?
> >
> > I believe MINA is allocating heap buffers by default. Yes, it's using
> > pooled buffers.
>
> I would try not using pooled buffers. We have found that is more
> effective particularly with JDK 1.6.
OK. Will check with that right away.
> > > Also, what is your app doing (roughly)?
> >
> > Its listening for connections, reading requests, processing them and
> > returning responses. It's an IM server.
>
> You could also try the alternative thread pool that we developed for
> Qpid (see previous message I sent about it).
Yes, that's also something I want to try. Do the filters work without any probs?
> Is your test creating and destroying lot of connections? Or is your
> test setting up connections, then just pumping data through them?
The memory utilization problem is seen when connections have not
started closing. New connections are made at the rate of 4/sec and
existing connections are generating requests.
Hmm... 2 SocketIoProcessors didn't help and neither did the
SimpleByteBufferAllocator.
MINA is showing a lot of ByteBuffers and a large Event queue. The
ExecutorFilter.Event is showing a retained size of 458 MB. The
SimpleByteBufferAllocator.SimpleByteBuffer is having a retained size
of 469 MB.
In contrast, the MINA ByteBuffers that my app is using show a low
shallow and retained size. I hope I'm correct in assuming that my app
is not holding a lot of buffers, but MINA is.
Regards,
Vinod.
