I'm running PHP 5.2.12 with PHP-FPM patch, nginx accesses it via
socket. Couple of times a day php-fpm become unresponsive, resulting
in 502 and 504. There is no load spike (CPU usage prior to the
incident is ~50%, and once it starts drops close to 0), there is
plenty of ram available, io isn't the reason either (actually watched
it happen in iotop - small .5mb/s io load dropped close to 0). Oh, and
it's Debian Lenny.

How is it unresponsive? First there is a noticeable slowdown (my
guess: less php-fpm processes available - longer queue), then full
halt with 502/504. Sometimes (rarely) starts working in 30-50 minutes,
but usually I have to restart php-fpm.

There is nothing suspicious in php-fpm log, even if I set logging
level to debug, so no, it's not rlimit etc.

In nginx error:
connect() to unix:/var/run/php-fpm/php.sock failed (11: Resource
temporarily unavailable) while connecting to upstream

in dmesq:
[81503.175657] php-cgi[28972]: segfault at bf7ff4a0 ip 0831c300 sp
bf7ff4a0 error 6 in php-cgi[8048000+5ef000]
[81508.170733] php-cgi[28965]: segfault at bf7ff4a0 ip 0831c300 sp
bf7ff4a0 error 6 in php-cgi[8048000+5ef000]
[180609.535546] php-cgi[26208]: segfault at bf7fee30 ip 0831c300 sp
bf7fee30 error 6 in php-cgi[8048000+5ef000]
[180662.879631] php-cgi[26206]: segfault at bf7fee30 ip 0831c300 sp
bf7fee30 error 6 in php-cgi[8048000+5ef000]

but I have only checked dmesg after I have restarted php-fpm, so I am
not sure if segfault message was there prior to me restarting or it
appeared at restart.


I'd really appreciate any help.


--
Subscription settings: http://groups.google.com/group/highload-php-en/subscribe?hl=en

2010/4/16 c2h5oh <maciej.lisiewski@gmail.com>

> I'm running PHP 5.2.12 with PHP-FPM patch, nginx accesses it via
> socket. Couple of times a day php-fpm become unresponsive, resulting
> in 502 and 504. There is no load spike (CPU usage prior to the
> incident is ~50%, and once it starts drops close to 0), there is
> plenty of ram available, io isn't the reason either (actually watched
> it happen in iotop - small .5mb/s io load dropped close to 0). Oh, and
> it's Debian Lenny.
>
> How is it unresponsive? First there is a noticeable slowdown (my
> guess: less php-fpm processes available - longer queue), then full
> halt with 502/504. Sometimes (rarely) starts working in 30-50 minutes,
> but usually I have to restart php-fpm.
>
> There is nothing suspicious in php-fpm log, even if I set logging
> level to debug, so no, it's not rlimit etc.
>
> In nginx error:
> connect() to unix:/var/run/php-fpm/php.sock failed (11: Resource
> temporarily unavailable) while connecting to upstream
>
> in dmesq:
> [81503.175657] php-cgi[28972]: segfault at bf7ff4a0 ip 0831c300 sp
> bf7ff4a0 error 6 in php-cgi[8048000+5ef000]
> [81508.170733] php-cgi[28965]: segfault at bf7ff4a0 ip 0831c300 sp
> bf7ff4a0 error 6 in php-cgi[8048000+5ef000]
> [180609.535546] php-cgi[26208]: segfault at bf7fee30 ip 0831c300 sp
> bf7fee30 error 6 in php-cgi[8048000+5ef000]
> [180662.879631] php-cgi[26206]: segfault at bf7fee30 ip 0831c300 sp
> bf7fee30 error 6 in php-cgi[8048000+5ef000]
>
> but I have only checked dmesg after I have restarted php-fpm, so I am
> not sure if segfault message was there prior to me restarting or it
> appeared at restart.
>
>
> I'd really appreciate any help.


Hi.

I have seen a similar behaviour on the past. I was able to fix it, tricking
with:

<value name="backlog">4096</value>

It seems that php-fpm not takes backlog value from sysctl when -1 is set.

Hope this helps.
Kind Regards.


--
Subscription settings: http://groups.google.com/group/highload-php-en/subscribe?hl=en

Thans, trying it right now.


--
Subscription settings: http://groups.google.com/group/highload-php-en/subscribe?hl=en

Nope, setting backlog made no difference.


--
Subscription settings: http://groups.google.com/group/highload-php-en/subscribe?hl=en

+1
i tried 5.3.2 with fpm from php svn - and i get random segfaults
within seconds.. 5.2.10 with fpm is running fine but i haven't checked
if it is one of my extensions (apc,memcache,gearman) so i didn't mail
yesterday.

regards,
frieder

2010/4/16 c2h5oh <maciej.lisiewski@gmail.com>:
> Nope, setting backlog made no difference.
>
>
> --
> Subscription settings: http://groups.google.com/group/highload-php-en/subscribe?hl=en
>

2010/4/16 Frieder Kundel <frieder.kundel@gmail.com>:
> +1
> i tried 5.3.2 with fpm from php svn - and i get random segfaults
> within seconds.. 5.2.10 with fpm is running fine but i haven't checked
> if it is one of my extensions (apc,memcache,gearman) so i didn't mail
> yesterday.
>

can you post more about your segfault problems please ?

I never had such problems. Having a log file, a conf and a gdb stack
trace would be helpful.

thx
++ Jerome


--
Subscription settings: http://groups.google.com/group/highload-php-en/subscribe?hl=en

It's most likely 2 separate problems:
1. Mine: stability problems, possible segfault after long use and with
5.2.x
2. Frieder Kundel's one: immediate segfault on start and with 5.3.x

It seems they need separate threads..

Going back to 1st one:

setting
<value name="backlog">4096</value>
vs default
<value name="backlog">-1</value>
made no difference

No matter what logging level I use in php-fpm/nginx I just can't find
any extra info. Segfault listed in dmesg seems to have nothing to do
with the problem - it didn't appear last 2 times it happened.
I have tried stressing the system, but it seems even saturating
100mbit pipe with php-generated html using ab -n50000 -c64 (with all
the modules I normally use in production: xcache, memcached) haven't
triggered the problem.

I would appreciate if someone pointed me in the right direction in
terms of how to debug this problem and pinpoint the reason.


--
Subscription settings: http://groups.google.com/group/highload-php-en/subscribe?hl=en

2010/4/17 c2h5oh <maciej.lisiewski@gmail.com>:
> It's most likely 2 separate problems:
> 1. Mine: stability problems, possible segfault after long use and with
> 5.2.x
> 2. Frieder Kundel's one: immediate segfault on start and with 5.3.x
>
> It seems they need separate threads..
>
> Going back to 1st one:
>
> setting
> <value name="backlog">4096</value>
> vs default
> <value name="backlog">-1</value>
> made no difference
>
> No matter what logging level I use in php-fpm/nginx I just can't find
> any extra info. Segfault listed in dmesg seems to have nothing to do
> with the problem - it didn't appear last 2 times it happened.
> I have tried stressing the system, but it seems even saturating
> 100mbit pipe with php-generated html using ab -n50000 -c64 (with all
> the modules I normally use in production: xcache, memcached) haven't
> triggered the problem.
>
> I would appreciate if someone pointed me in the right direction in
> terms of how to debug this problem and pinpoint the reason.

Can you use the last SVN version with php 5.3.2 ?

for debuggin, you can set log_level to debug, daemonize to no and
rlimit_core to "unlimited". FPM will run in foreground and error logs
will print on stderr. when it crashed you should have a coredump. gdb
it with

gdb /path/to/fpm_binary /path/to/core_file
and show the stack trace with "bt"

++ Jerome


--
Subscription settings: http://groups.google.com/group/highload-php-en/subscribe?hl=en

> Can you use the last SVN version with php 5.3.2 ?

No, the php code I'm running does not work with 5.3.x and I don't even
have ETA on update.


> for debuggin, you can set log_level to debug, daemonize to no and
> rlimit_core to "unlimited". FPM will run in foreground and error logs
> will print on stderr. when it crashed you should have a coredump. gdb
> it with
>
> gdb /path/to/fpm_binary /path/to/core_file
> and show the stack trace with "bt"

logging is already set to debug - nothing out of ordinary in log. I'm
setting rlimit_core and disabling daemonization now - I will get back
to you.


--
Subscription settings: http://groups.google.com/group/highload-php-en/subscribe?hl=en

2010/4/17 c2h5oh <maciej.lisiewski@gmail.com>:
>
>> Can you use the last SVN version with php 5.3.2 ?
>
> No, the php code I'm running does not work with 5.3.x and I don't even
> have ETA on update.

OK I understand. But I'll do my best to help you but I'm not very
familiar with FPM version prior to PHP svn inclusion.

>
>
>> for debuggin, you can set log_level to debug, daemonize to no and
>> rlimit_core to "unlimited". FPM will run in foreground and error logs
>> will print on stderr. when it crashed you should have a coredump. gdb
>> it with
>>
>> gdb /path/to/fpm_binary /path/to/core_file
>> and show the stack trace with "bt"
>
> logging is already set to debug - nothing out of ordinary in log. I'm
> setting rlimit_core and disabling daemonization now - I will get back
> to you.

I'm waiting to hear from you


--
Subscription settings: http://groups.google.com/group/highload-php-en/subscribe?hl=en

> I'm waiting to hear from you

All I got is:

Apr 17 17:21:09.731348 [WARNING] fpm_request_check_timed_out(), line
146: child 25467, script '[edited]' (pool default) executing too slow
(30.078848 sec), logging
Apr 17 17:21:09.731409 [NOTICE] fpm_got_signal(), line 48: received
SIGCHLD
Apr 17 17:21:09.731427 [NOTICE] fpm_children_bury(), line 194: child
25467 stopped for tracing
Apr 17 17:21:09.731441 [NOTICE] fpm_php_trace(), line 139: about to
trace 25467
Apr 17 17:21:09.771622 [NOTICE] fpm_php_trace(), line 167: finished
trace of 25467

Just restarted without execution time limit and waiting for new output.


--
Subscription settings: http://groups.google.com/group/highload-php-en/subscribe?hl=en

2010/4/17 c2h5oh <maciej.lisiewski@gmail.com>:
>
>> I'm waiting to hear from you
>
> All I got is:
>
> Apr 17 17:21:09.731348 [WARNING] fpm_request_check_timed_out(), line
> 146: child 25467, script '[edited]' (pool default) executing too slow
> (30.078848 sec), logging
> Apr 17 17:21:09.731409 [NOTICE] fpm_got_signal(), line 48: received
> SIGCHLD
> Apr 17 17:21:09.731427 [NOTICE] fpm_children_bury(), line 194: child
> 25467 stopped for tracing
> Apr 17 17:21:09.731441 [NOTICE] fpm_php_trace(), line 139: about to
> trace 25467
> Apr 17 17:21:09.771622 [NOTICE] fpm_php_trace(), line 167: finished
> trace of 25467
>
> Just restarted without execution time limit and waiting for new output.
>

yes set request_slowlog_timeout to 0 and request_terminate_timeout to 0.

++ jerome


--
Subscription settings: http://groups.google.com/group/highload-php-en/subscribe?hl=en

Without execution time limit nothing is logged/output to stderr - just
the basic notices, child start, child termination on requests limit
etc.


--
Subscription settings: http://groups.google.com/group/highload-php-en/subscribe?hl=en

2010/4/17 c2h5oh <maciej.lisiewski@gmail.com>:
> Without execution time limit nothing is logged/output to stderr - just
> the basic notices, child start, child termination on requests limit
> etc.

and did the problem appear ?


--
Subscription settings: http://groups.google.com/group/highload-php-en/subscribe?hl=en

Finally somebody that has my very same problem (except for the
segfaults, they stopped a few weeks ago, probably due to some upgrade,
I don't really remember), but I don't think this is strictly php-fpm
related, here's why:

- Tried many different versions of php (5.2 and 5.3 branch)
- Tried using 2 different spawn-cgi script instead of php-fpm
- Tried using another webserver instead of nginx (lighttpd)
- Tried with lighttpd 1.5 + php-fpm and with lighttpd 1.4.x + the
built-in spawning system

All the above resulted in having the same error you described (502
after minutes/hours/days and nothing in the logs that could explain
it).
Ok, here's the interesting part: last wednesday I set a very high
number of max_children in php-fpm.conf (I'm using the apache-like
configuration so the number of child increases or decreases
dinamically) and since then I haven't had any 502! I should wait
another week before saying the error it's gone, but I'm pretty
confident it is.

My PHP version atm: 5.3.99-dev
My OS: Debian 5.0.4
My nginx version: 0.8.35

On 16 Apr, 11:51, c2h5oh <maciej.lisiew...@gmail.com> wrote:
> I'm running PHP 5.2.12 with PHP-FPM patch, nginx accesses it via
> socket. Couple of times a day php-fpm become unresponsive, resulting
> in 502 and 504. There is no load spike (CPU usage prior to the
> incident is ~50%, and once it starts drops close to 0), there is
> plenty of ram available, io isn't the reason either (actually watched
> it happen in iotop - small .5mb/s io load dropped close to 0). Oh, and
> it's Debian Lenny.
>
> How is it unresponsive? First there is a noticeable slowdown (my
> guess: less php-fpm processes available - longer queue), then full
> halt with 502/504. Sometimes (rarely) starts working in 30-50 minutes,
> but usually I have to restart php-fpm.
>
> There is nothing suspicious in php-fpm log, even if I set logging
> level to debug, so no, it's not rlimit etc.
>
> In nginx error:
> connect() to unix:/var/run/php-fpm/php.sock failed (11: Resource
> temporarily unavailable) while connecting to upstream
>
> in dmesq:
> [81503.175657] php-cgi[28972]: segfault at bf7ff4a0 ip 0831c300 sp
> bf7ff4a0 error 6 in php-cgi[8048000+5ef000]
> [81508.170733] php-cgi[28965]: segfault at bf7ff4a0 ip 0831c300 sp
> bf7ff4a0 error 6 in php-cgi[8048000+5ef000]
> [180609.535546] php-cgi[26208]: segfault at bf7fee30 ip 0831c300 sp
> bf7fee30 error 6 in php-cgi[8048000+5ef000]
> [180662.879631] php-cgi[26206]: segfault at bf7fee30 ip 0831c300 sp
> bf7fee30 error 6 in php-cgi[8048000+5ef000]
>
> but I have only checked dmesg after I have restarted php-fpm, so I am
> not sure if segfault message was there prior to me restarting or it
> appeared at restart.
>
> I'd really appreciate any help.
>
> --
> Subscription settings:http://groups.google.com/group/highload-php-en/subscribe?hl=en

Unless Jerome disagrees since he put it in place I would still call
the apache-like or dynamic process manager experimental. Use static
and adjust children appropriately. Note that dynamic is only in svn,
apache-like is from launchpad and neither are in the patch (5.2)

For 5.3 use svn and try that. If that doesn't work, downgrade to 5.2
and use the patch.

On Apr 17, 2010, at 12:20 PM, Usu <andreausu@gmail.com> wrote:

> Finally somebody that has my very same problem (except for the
> segfaults, they stopped a few weeks ago, probably due to some upgrade,
> I don't really remember), but I don't think this is strictly php-fpm
> related, here's why:
>
> - Tried many different versions of php (5.2 and 5.3 branch)
> - Tried using 2 different spawn-cgi script instead of php-fpm
> - Tried using another webserver instead of nginx (lighttpd)
> - Tried with lighttpd 1.5 + php-fpm and with lighttpd 1.4.x + the
> built-in spawning system
>
> All the above resulted in having the same error you described (502
> after minutes/hours/days and nothing in the logs that could explain
> it).
> Ok, here's the interesting part: last wednesday I set a very high
> number of max_children in php-fpm.conf (I'm using the apache-like
> configuration so the number of child increases or decreases
> dinamically) and since then I haven't had any 502! I should wait
> another week before saying the error it's gone, but I'm pretty
> confident it is.
>
> My PHP version atm: 5.3.99-dev
> My OS: Debian 5.0.4
> My nginx version: 0.8.35
>
> On 16 Apr, 11:51, c2h5oh <maciej.lisiew...@gmail.com> wrote:
>> I'm running PHP 5.2.12 with PHP-FPM patch, nginx accesses it via
>> socket. Couple of times a day php-fpm become unresponsive, resulting
>> in 502 and 504. There is no load spike (CPU usage prior to the
>> incident is ~50%, and once it starts drops close to 0), there is
>> plenty of ram available, io isn't the reason either (actually watched
>> it happen in iotop - small .5mb/s io load dropped close to 0). Oh,
>> and
>> it's Debian Lenny.
>>
>> How is it unresponsive? First there is a noticeable slowdown (my
>> guess: less php-fpm processes available - longer queue), then full
>> halt with 502/504. Sometimes (rarely) starts working in 30-50
>> minutes,
>> but usually I have to restart php-fpm.
>>
>> There is nothing suspicious in php-fpm log, even if I set logging
>> level to debug, so no, it's not rlimit etc.
>>
>> In nginx error:
>> connect() to unix:/var/run/php-fpm/php.sock failed (11: Resource
>> temporarily unavailable) while connecting to upstream
>>
>> in dmesq:
>> [81503.175657] php-cgi[28972]: segfault at bf7ff4a0 ip 0831c300 sp
>> bf7ff4a0 error 6 in php-cgi[8048000+5ef000]
>> [81508.170733] php-cgi[28965]: segfault at bf7ff4a0 ip 0831c300 sp
>> bf7ff4a0 error 6 in php-cgi[8048000+5ef000]
>> [180609.535546] php-cgi[26208]: segfault at bf7fee30 ip 0831c300 sp
>> bf7fee30 error 6 in php-cgi[8048000+5ef000]
>> [180662.879631] php-cgi[26206]: segfault at bf7fee30 ip 0831c300 sp
>> bf7fee30 error 6 in php-cgi[8048000+5ef000]
>>
>> but I have only checked dmesg after I have restarted php-fpm, so I am
>> not sure if segfault message was there prior to me restarting or it
>> appeared at restart.
>>
>> I'd really appreciate any help.
>>
>> --
>> Subscription settings:http://groups.google.com/group/highload-php-
>> en/subscribe?hl=en

On 18.04.2010 00:00, Michael Shadle wrote:
> Unless Jerome disagrees since he put it in place I would still call
> the apache-like or dynamic process manager experimental. Use static
> and adjust children appropriately. Note that dynamic is only in svn,
> apache-like is from launchpad and neither are in the patch (5.2)
>
> For 5.3 use svn and try that. If that doesn't work, downgrade to 5.2
> and use the patch.

If that doesn't work, provide a GDB backtrace at last!
If you don't know how to do it, read this: http://bugs.php.net/bugs-generating-backtrace.php

Please, always start with the backtrace whenever you have any segfaults, it saves a lot of time and traffic.

--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime statistics for PHP


--
Subscription settings: http://groups.google.com/group/highload-php-en/subscribe?hl=en

Yeah, I meant dynamic from svn, I've been using it for a few weeks
without problems (except for the 502 thing but it's unreleated since
it happens also using static and old php-fpm versions).

Using static with an appropriate number of children leads to the 502
error, maybe the dynamic thing is just a workaround for this error
because the processes are stopped and started a lot but this is just a
guess... in fact this error seems to be disappeared after setting a
very high number of max_children in php-fpm.conf (using dynamic
process) in order to never reach the limit

On 17 Apr, 22:00, Michael Shadle <mike...@gmail.com> wrote:
> Unless Jerome disagrees since he put it in place I would still call  
> the apache-like or dynamic process manager experimental. Use static  
> and adjust children appropriately. Note that dynamic is only in svn,  
> apache-like is from launchpad and neither are in the patch (5.2)
>
> For 5.3 use svn and try that. If that doesn't work, downgrade to 5.2  
> and use the patch.
>
> On Apr 17, 2010, at 12:20 PM, Usu <andrea...@gmail.com> wrote:
>
>
>
> > Finally somebody that has my very same problem (except for the
> > segfaults, they stopped a few weeks ago, probably due to some upgrade,
> > I don't really remember), but I don't think this is strictly php-fpm
> > related, here's why:
>
> > - Tried many different versions of php (5.2 and 5.3 branch)
> > - Tried using 2 different spawn-cgi script instead of php-fpm
> > - Tried using another webserver instead of nginx (lighttpd)
> > - Tried with lighttpd 1.5 + php-fpm and with lighttpd 1.4.x + the
> > built-in spawning system
>
> > All the above resulted in having the same error you described (502
> > after minutes/hours/days and nothing in the logs that could explain
> > it).
> > Ok, here's the interesting part: last wednesday I set a very high
> > number of max_children in php-fpm.conf (I'm using the apache-like
> > configuration so the number of child increases or decreases
> > dinamically) and since then I haven't had any 502! I should wait
> > another week before saying the error it's gone, but I'm pretty
> > confident it is.
>
> > My PHP version atm: 5.3.99-dev
> > My OS: Debian 5.0.4
> > My nginx version: 0.8.35
>
> > On 16 Apr, 11:51, c2h5oh <maciej.lisiew...@gmail.com> wrote:
> >> I'm running PHP 5.2.12 with PHP-FPM patch, nginx accesses it via
> >> socket. Couple of times a day php-fpm become unresponsive, resulting
> >> in 502 and 504. There is no load spike (CPU usage prior to the
> >> incident is ~50%, and once it starts drops close to 0), there is
> >> plenty of ram available, io isn't the reason either (actually watched
> >> it happen in iotop - small .5mb/s io load dropped close to 0). Oh,  
> >> and
> >> it's Debian Lenny.
>
> >> How is it unresponsive? First there is a noticeable slowdown (my
> >> guess: less php-fpm processes available - longer queue), then full
> >> halt with 502/504. Sometimes (rarely) starts working in 30-50  
> >> minutes,
> >> but usually I have to restart php-fpm.
>
> >> There is nothing suspicious in php-fpm log, even if I set logging
> >> level to debug, so no, it's not rlimit etc.
>
> >> In nginx error:
> >> connect() to unix:/var/run/php-fpm/php.sock failed (11: Resource
> >> temporarily unavailable) while connecting to upstream
>
> >> in dmesq:
> >> [81503.175657] php-cgi[28972]: segfault at bf7ff4a0 ip 0831c300 sp
> >> bf7ff4a0 error 6 in php-cgi[8048000+5ef000]
> >> [81508.170733] php-cgi[28965]: segfault at bf7ff4a0 ip 0831c300 sp
> >> bf7ff4a0 error 6 in php-cgi[8048000+5ef000]
> >> [180609.535546] php-cgi[26208]: segfault at bf7fee30 ip 0831c300 sp
> >> bf7fee30 error 6 in php-cgi[8048000+5ef000]
> >> [180662.879631] php-cgi[26206]: segfault at bf7fee30 ip 0831c300 sp
> >> bf7fee30 error 6 in php-cgi[8048000+5ef000]
>
> >> but I have only checked dmesg after I have restarted php-fpm, so I am
> >> not sure if segfault message was there prior to me restarting or it
> >> appeared at restart.
>
> >> I'd really appreciate any help.
>
> >> --
> >> Subscription settings:http://groups.google.com/group/highload-php-
> >> en/subscribe?hl=en

I'd like to add a section on the site about how to report a bug. That
way it is a one-stop shop on explaining the best things to try.
Jerome/Antony/anyone please send me your ideas on the steps, I'll get
a basic version up and we can tweak (feel free to take it off-list or
on-list, whichever you feel is appropriate)

I suppose it also depends on what the error is too... sometimes
increasing or decreasing the children works, things like that.

Something like this...

"
Common Stuff:
- Be sure to include the following information: OS, distribution, PHP
configure string, relevant snippets from the PHP-FPM log, and any
relevant snippets from nginx or the webserver logs.
- If you are still having issues with segfaults, provide a GDB
backtrace. If you don't know how to do it, read this:
http://bugs.php.net/bugs-generating-backtrace.php


For SVN (5.3+):
- ??
- If you are still having issues with segfaults, provide a GDB
backtrace. If you don't know how to do it, read this:
http://bugs.php.net/bugs-generating-backtrace.php
- Note: at some point soon the bugs.php.net bug tracker should have a
category for this

For the patch:
- ??
- Make sure you are using the 'static' process manager type.
'apache-like' does not actually work.
- Make sure you have enough max_children defined, but not too many.

For the Launchpad version: no longer supported, either change to using
5.3 from SVN, or downgrade to 5.2 and use the patch."


On Sat, Apr 17, 2010 at 1:19 PM, Antony Dovgal <tony@daylessday.org> wrote:

> If that doesn't work, provide a GDB backtrace at last!
> If you don't know how to do it, read this: http://bugs.php.net/bugs-generating-backtrace.php
>
> Please, always start with the backtrace whenever you have any segfaults, it saves a lot of time and traffic.


--
Subscription settings: http://groups.google.com/group/highload-php-en/subscribe?hl=en

On 18.04.2010 00:30, Michael Shadle wrote:
> I'd like to add a section on the site about how to report a bug.

We already have that, no need for a duplicate:
http://bugs.php.net/how-to-report.php

A category for FPM bugs has been added recently, too.

--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime statistics for PHP


--
Subscription settings: http://groups.google.com/group/highload-php-en/subscribe?hl=en