>>> We're not running it on any virtual hosts and are seeing large memory >>> footprints as well. Also seeing really large footprints for the >>> puppetmaster (though I don't care as much about that).
>> puppetmaster still leaks like a sieve for us. :/ We have to restart it >> nightly to keep the system from running out of memory, and even that > I have the same problem on centos 5 boxes, x86_64 as well i386, all > running in xenguests and 0.24.4 (as well the guests). I deploy a cron on > puppetmasters to restart puppetmaster every 4 hours. Just to be on the
Puppetmaster 1 - catalog server. VIRT 99.6, RES 82.
Puppetmaster 2 - file server. VIRT 52M, RES 37M
I've also got a restart cron job, but it only smacks the catalog server, not the file server. CentOS 5, x86, VMware Server guest.
Before I split the file server out (and I sent a patch to dlutter for the RHEL init script, perhaps it belongs elsewhere), I'd routinely see puppetmasterd at 200+ MB of memory on a VM that had 256. Add in the backup software taking VIRT 139/RES 4.5, and a postgres instance for storeconfigs, and I'd also be 200 MB into swap, and compile times would hit hundreds of seconds. Even with the cron to restart it, this happened.
So perhaps splitting the file server out has benefits beyond file serving hogging CPU on the catalog generation?
|
