Joan wrote:
>     2007/11/10, Joan < aseques@gmail.com <mailto:aseques@gmail.com>>:
>     > 2007/11/9, Marcin Owsiany <marcin@owsiany.pl
>     <mailto:marcin@owsiany.pl>>:
>     > > On Fri, Nov 09, 2007 at 01:06:31PM +0100, Joan wrote:
>     > > > Well, 3.5Gb should be a fair amount of memory for that amount of
>     > > > domains as I experienced with physical machines.
>     > > > I would like to know what approaches have taken the people
>     experiecing
>     > > > similar issues...
>     > >
>     > > Limit MaxClients, MinSpareServers, MaxSpareServers and most
>     importantly
>     > > MaxRequestsPerChild. This way PHP will not have much time to
>     leak too
>     > > much memory, which should keep the usage down a bit.
>     > >
>     > I tunned the following Timeout, MaxKeepAliveRequests,
>     KeepAliveTimeout.
>     > And also the ones that you've told, specially  MaxClients and
>     > MaxRequestsPerChild wich seem to be the most important ones.
>     >
>     > Will see how it goes for the next days!
>     Too bad, nothing changes, memory keeps increasing everytime until
>     everything crashes silently, thanks to the alarms everytime it happens
>     I can reboot the services, but it's not normal...
>     Tomorrow I'l compare the parameters (ps, lsof, netsat) in the critical
>     moments with the ones in normal time  and see.
> 
> 
> Ok, finally got time to check
> 
> After some time of restarting the whole VeID lsof brings me some
> information:
> lsof | wc -l   -> Has a value of 8560
> In the moment where it has almost no memory:
> wc -l lsof_with_problems  -> The value is 30006
> 
> Analyzing the file a bit further I can see that out of 30006 open files,
> the owner of 28266 is apache2
> 
> I would guess that somehow apache is not closing the files, either for
> memory problems with openvz, or maybe because the non-threading
> configuration that can slowdown the apache process.
> Any clue?
> 
> Shall I go to ask to apache mailing list? Or could it somehow be related
> to openVZ? 

Nope, it looks purely like apache problem.
You can also check the following:
- what are these files? ls -la /proc/pid/fds
  i.e. it can be sockets or files. what are they?
  `netstat -natp` output can be helpful as well
- plz post /proc/user_beancounters output.
  it always helps to analyze the resource shortage problems.
- what does apache say in the log when problem begin?
you can also ask Plesk support if issue is related to Plesk product.

Thanks,
Kirill