Good morning

I've got a plesk installation on a openvz as the single VeID in the
machine (vzsplit -n 1).
The box has 3.5 Gb of memory, and is a 2000GHz Dual Core.
For around of 200 domains the machine should be fine i guess.
But, all the time we are being left with no memory.
Almost every day privvmpages break the counter in user_beancounters.
And after restarting apache2 everything goes fine.

It's a problem with plesk eating all the memory, apache2-mpm-prefork,
openvz memory management or what?

Thanks in advance

On Fri, Nov 09, 2007 at 09:33:05AM +0100, Joan wrote:
> It's a problem with plesk eating all the memory, apache2-mpm-prefork,
> openvz memory management or what?

Probably PHP.

-- 
Marcin Owsiany <marcin@owsiany.pl>              http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
 
"Every program in development at MIT expands until it can read mail."
                                                              -- Unknown

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...

2007/11/9, Marcin Owsiany <marcin@owsiany.pl>:
> On Fri, Nov 09, 2007 at 09:33:05AM +0100, Joan wrote:
> > It's a problem with plesk eating all the memory, apache2-mpm-prefork,
> > openvz memory management or what?
>
> Probably PHP.
>
> --
> Marcin Owsiany <marcin@owsiany.pl>              http://marcin.owsiany.pl/
> GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
>
> "Every program in development at MIT expands until it can read mail."
>                                                               -- Unknown

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.

-- 
Marcin Owsiany <marcin@owsiany.pl>              http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
 
"Every program in development at MIT expands until it can read mail."
                                                              -- Unknown

2007/11/9, Marcin Owsiany <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!

Cheers

> --
> Marcin Owsiany <marcin@owsiany.pl>              http://marcin.owsiany.pl/
> GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
>
> "Every program in development at MIT expands until it can read mail."
>                                                               -- Unknown

2007/11/10, Joan <aseques@gmail.com>:
> 2007/11/9, Marcin Owsiany <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.

Cheers
>
> Cheers
>
> > --
> > Marcin Owsiany <marcin@owsiany.pl>              http://marcin.owsiany.pl/
> > GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
> >
> > "Every program in development at MIT expands until it can read mail."
> >                                                               -- Unknown

>
> 2007/11/10, Joan <aseques@gmail.com>:
> > 2007/11/9, Marcin Owsiany <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?

Cheers
> >
> > Cheers
> >
> > > --
> > > Marcin Owsiany <marcin@owsiany.pl>
> http://marcin.owsiany.pl/
> > > GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4
> 1216
> > >
> > > "Every program in development at MIT expands until it can read mail."
> > >                                                               --
> Unknown

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