On 02/28/2013 02:54 PM, Jorge Bastos wrote:
> Hi Paul,
>
> Allow me to ask, with this job, you the remaining memory leaks were killed?
Excusez moi le mot, but how the f*ck should I know. I can only test so
much you know.
A lot of the 'leakage' mentioned here and there is not leakage at all,
but memory fragmentation or side effects from GLib's slice allocator.
I've added a memory pool implementation to isolate a lot of the
allocation and have been testing jemalloc. Results are much the same all
over.
You can test those features:
Activate the experimental memory pool:
export DM_POOL=yes
De-activate the slice allocator:
export G_SLICE=all
Use jemalloc:
../configure --with-jemalloc=yes
There probably still is some leakage in the imap code, which will occur
under severe concurrency pressure. Restarting is the only solution atm.
I've been thinking about adding a additional layer to take care of
automatic restarts. A bit like 2.2's preforking:
- one master process and one forked child to handle the workload.
- the master process can then fire up a new child when needed, and
gracefully shut down the stale one.
--
________________________________________________________________
Paul J Stevens pjstevns @ gmail, twitter, skype, linkedin
* Premium Hosting Services and Web Application Consultancy *
www.nfg.nl/[email protected]/+31.85.877.99.97
________________________________________________________________
_______________________________________________
Dbmail-dev mailing list
[email protected]
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
