Any way to measure how many concurrent processes are being used?

[mike]

Is there any way (or a patch) to easily see how many fastcgi engines
are actually being used right now?

I suppose this will definately be available since you have to
calculate it for the apache-style process management, but it would be
nice to know right now if I am wasting resources by putting 25 engines
up for a client who only maxes out at the highest load at 10
engines...

It will help me make better use of my resources until I can let
PHP-FPM manage my fastcgi engines dynamically :)

Thanks. I'm open for whatever ideas people have. I use nginx as my
webserver. I don't really see any way to get a decent measurement
right now...

[Andrei Nigmatulin]

On Monday 30 June 2008 07:13, mike wrote:
> Is there any way (or a patch) to easily see how many fastcgi engines
> are actually being used right now?

There is a way:
http://groups.google.com/group/highload-php-en/msg/9d47701425afe02c

Every ESTABLISHED fastcgi connection corresponds to one php worker being used.

A more friendly web interface for observing worker states will be ready soon.

> I suppose this will definately be available since you have to
> calculate it for the apache-style process management, but it would be
> nice to know right now if I am wasting resources by putting 25 engines
> up for a client who only maxes out at the highest load at 10
> engines...
>
> It will help me make better use of my resources until I can let
> PHP-FPM manage my fastcgi engines dynamically :)
>
> Thanks. I'm open for whatever ideas people have. I use nginx as my
> webserver. I don't really see any way to get a decent measurement
> right now...

--
Andrei Nigmatulin
GPG PUB KEY 6449830D

Now I lay me down to sleep(3)
Pray the OS my core to keep
If I die before I wake
Pray the Disk my core to take

[mike]

On 6/30/08, Andrei Nigmatulin <andrei.n...@gmail.com> wrote:
>
> On Monday 30 June 2008 07:13, mike wrote:
> > Is there any way (or a patch) to easily see how many fastcgi engines
> > are actually being used right now?
>
> There is a way:
> http://groups.google.com/group/highload-php-en/msg/9d47701425afe02c
>
> Every ESTABLISHED fastcgi connection corresponds to one php worker being used.
>
> A more friendly web interface for observing worker states will be ready soon.

Awesome. I have been singing the praises of php-fpm everywhere I can.
I flat out tell people spawn-fcgi or any other custom things is simply
the wrong way to do it and a waste of time.

I do have a question - doesn't this seem like a whole hell of a lot of
TIME_WAITs over localhost, shouldn't this stuff clean up quicker?

[root@web02 ~]# netstat -np | grep 127.0.0.1:11011 | grep -c ESTABLISHED
1

[root@web02 ~]# netstat -np | grep 127.0.0.1:11011 | grep -c TIME_WAIT
323

I used to have some sysctl.conf settings to recycle TCP sockets
quicker I think, but all my sysctl.conf settings somehow made NFS less
reliable and I never could debug it on a production system.

Do you have any thoughts on that? Does that sound normal? That pool
has 25 children defined for it. Even at peak load I am thinking the
PHP connections execute so fast, I can get away with half that... but
all this excess TIME_WAIT seems a bit crazy.

[Andrei Nigmatulin]

On Monday 30 June 2008 19:11, mike wrote:
> On 6/30/08, Andrei Nigmatulin <andrei.n...@gmail.com> wrote:
> > On Monday 30 June 2008 07:13, mike wrote:
> > > Is there any way (or a patch) to easily see how many fastcgi engines
> > > are actually being used right now?
> >
> > There is a way:
> > http://groups.google.com/group/highload-php-en/msg/9d47701425afe02c
> >
> > Every ESTABLISHED fastcgi connection corresponds to one php worker being
> > used.
> >
> > A more friendly web interface for observing worker states will be ready
> > soon.
>
> Awesome. I have been singing the praises of php-fpm everywhere I can.
> I flat out tell people spawn-fcgi or any other custom things is simply
> the wrong way to do it and a waste of time.
>
> I do have a question - doesn't this seem like a whole hell of a lot of
> TIME_WAITs over localhost, shouldn't this stuff clean up quicker?

This tunable is /proc/sys/net/ipv4/tcp_fin_timeout.

> [root@web02 ~]# netstat -np | grep 127.0.0.1:11011 | grep -c ESTABLISHED
> 1
>
> [root@web02 ~]# netstat -np | grep 127.0.0.1:11011 | grep -c TIME_WAIT
> 323
>
> I used to have some sysctl.conf settings to recycle TCP sockets
> quicker I think, but all my sysctl.conf settings somehow made NFS less
> reliable and I never could debug it on a production system.

AFAIR it's not possible to set different values for different interfaces.

> Do you have any thoughts on that? Does that sound normal?

Yes, quite a normal thing.

> That pool
> has 25 children defined for it. Even at peak load I am thinking the
> PHP connections execute so fast, I can get away with half that... but
> all this excess TIME_WAIT seems a bit crazy.

--

[mike]

On 7/1/08, Andrei Nigmatulin <andrei.n...@gmail.com> wrote:

> > I do have a question - doesn't this seem like a whole hell of a lot of
> > TIME_WAITs over localhost, shouldn't this stuff clean up quicker?
>
> This tunable is /proc/sys/net/ipv4/tcp_fin_timeout.

Thanks

> > I used to have some sysctl.conf settings to recycle TCP sockets
> > quicker I think, but all my sysctl.conf settings somehow made NFS less
> > reliable and I never could debug it on a production system.
>
> AFAIR it's not possible to set different values for different interfaces.

yea i wasn't planning on trying to do it on different interfaces.

> > Do you have any thoughts on that? Does that sound normal?
>
> Yes, quite a normal thing.

so in your opinion, is this anything i should mess with? i want my
machines to be as efficient as possible. currently
/proc/sys/net/ipv4/tcp_fin_timeout is set to 60... would you recommend
knocking that down at all?

[Andrei Nigmatulin]

If you're not experiencing any problems with socket resources I would not
recommend to tune that down.