server performance issue

Ilan Berkner iberkner at gmail.com
Tue Oct 26 15:36:57 MSD 2010


How busy is your site?  Have you had a recent spike in traffic?

I would suggest looking at the response times from mysql.  In particular,
turn on the slow query log and set the long query time to 1 second or even
less to see what comes up (you need at least mysql 5.1 to set it to
non-integer values).  You can use a tool like "mk-query-digest" from maatkit
to summarize the slow log and get a sense of what may be holding up your php
processes.

You could also profile your php application using xdebug and view the
resulting files using a grind tool to determine where php is spending most
of its time.  Profiling will most definitely crash your application,
especially since you're already seeing 100% CPU utilization but you can run
it for a short period of time and review the resulting grind files.

Its unlikely that this is an Nginx problem.



On Tue, Oct 26, 2010 at 7:07 AM, Phil Bayfield <phil at techlightenment.com>wrote:

> Your formulas look interesting, will give them a try next time I'm doing
> some optimising.
> Normally I would just make a rough guess based off req/sec, execution times
> etc and fine tune with ab.
>
>
> On 26 October 2010 11:58, SplitIce <mat999 at gmail.com> wrote:
>
>> ive found that if you have no blocking functions in php, aka its CPU bound
>> then number of  CPU cores+1 is the most efficient. If it has mysql (most
>> likely does) and other IO bound operations then *2 or *3 is fine. values
>> between 20-30 are common in decent scale web servers, in fact on my i7 8gb
>> ram I run 20, on my amd x2 4gb ram I run 15.
>>
>> On Tue, Oct 26, 2010 at 9:52 PM, Phil Bayfield <phil at techlightenment.com>wrote:
>>
>>> Sorry didn't read you config before posting, you already have this. :)
>>>
>>> You probably need to reduce the number of child processes, more is not
>>> better.
>>>
>>> On intensive PHP applications I've found lower is better.
>>>
>>> For example, if you have 100 concurrent connections, this doesn't mean
>>> you necessarily need 100 PHP-FPM children.
>>>
>>>>
>>>
>>> _______________________________________________
>>> nginx mailing list
>>> nginx at nginx.org
>>> http://nginx.org/mailman/listinfo/nginx
>>>
>>>
>>
>>
>> --
>> Warez Scene <http://thewarezscene.org> Free Rapidshare Downloads<http://www.nexusddl.com>
>>
>>
>> _______________________________________________
>> nginx mailing list
>> nginx at nginx.org
>> http://nginx.org/mailman/listinfo/nginx
>>
>>
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://nginx.org/mailman/listinfo/nginx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20101026/7556d07b/attachment.html>


More information about the nginx mailing list