WANproxy stability and its memory management

[Alain-Pierre Perrin]

Hello Juli and other WANproxy contributors.


"Too long, won't read:" Does WANproxy "knows" when to stop allocating
memory and to start purging the oldest/less frequently used pages ?

This question may sound dumb but here's why I ask it.

I tried to use WANproxy (versions 0.8, SVN and diegows variant) on
dedicated Linux (up to date and minimalistic Arch Linux) virtual
machines to compress/deduplicate replication streams on a WAN link
between two Dell Equallogic SANs. With the correct configuration files
(the web site should include a lot more of examples and variants because
I've built my config files by trial-and-error), it works beautifully...
but after some time, WANproxy gets purged by the Linux OOM (out of
memory) killer when the limits of available RAM (8G) are reached on the
two dedicated VMs created to host it. My replication processes get
interrupted until I restart the WANproxy processes on the two proxy
machines.

How can we help to make WANproxy rock-solid ? I'd rather have passable
performance (at least to begin) with killer stability over good
performance with the need to restart WANproxy processes every 4 hours...

To conclude I sincerely congratulate Juli and the other WANproxy
developers/contributors for their work. Among the few (only three, with
TrafficSqueezer and OpenNOP) opensourced WAN optimization software
projects that I found on the net, WANproxy seemed the "least badly
documented" and the most elegant in terms of simplicity (one process,
one config file, no low-level OS customization needed) and modularity.
With some polish in the code (to make wanproxy process more stable and
resilient) and in the doc (to make wanproxy easier to understand and
configure) this little tool, adhering closely to Unix philosophy, could
become as indispensable as rsync, nmap or ssh in every sysadmin
toolbox...

Thanks in advance.


Alain-Pierre Perrin