Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

100% CPU load : how to investigate?

0 views
Skip to first unread message

Vincent Delporte

unread,
Mar 13, 2007, 10:28:40 AM3/13/07
to
Hello

Someone I know is running some Web 2.0-type web site that lives on a
shared host, and is experiencing 100% CPU load after a few hours. At
this point, his provider couldn't tell if it's due to a DoS attack, or
a bug in his application.

1. For the DoS thing, I assume looking at the log files should be
enough to tell if it's the problem is due to a suspicious rise in the
number of connections at some point.

2. As for bugs, are there tools available for PHP that can monitor an
application and reveal bugs that could explain this CPU load?

Thank you.

Erwin Moller

unread,
Mar 13, 2007, 10:52:25 AM3/13/07
to
Vincent Delporte wrote:

> Hello
>
> Someone I know is running some Web 2.0-type web site that lives on a
> shared host, and is experiencing 100% CPU load after a few hours. At
> this point, his provider couldn't tell if it's due to a DoS attack, or
> a bug in his application.

Web2. A very vague description. :P

>
> 1. For the DoS thing, I assume looking at the log files should be
> enough to tell if it's the problem is due to a suspicious rise in the
> number of connections at some point.

Yes.
Simply check the number of requests. A DDos should be found easily (before
crashing).

>
> 2. As for bugs, are there tools available for PHP that can monitor an
> application and reveal bugs that could explain this CPU load?

Yes. A few debuggers/profilers are out there.
just type 'debugger php' in google to get them.
A very well known one is the DBG debugger.

I understood Zend has a good one, but you have to buy it.
I didn't buy Zend Studio (yet), but am considering it. I hear only good
things from people in here. :)

or check here: http://drupal.org/node/1466

Regards,
Erwin Moller

>
> Thank you.

Vincent Delporte

unread,
Mar 13, 2007, 11:00:28 AM3/13/07
to
On Tue, 13 Mar 2007 15:52:25 +0100, Erwin Moller
<since_humans_read_this...@spamyourself.com> wrote:
>Web2. A very vague description. :P

Some kind of social site :-)

>Simply check the number of requests. A DDos should be found easily (before
>crashing).

Will do.

>Yes. A few debuggers/profilers are out there.
>just type 'debugger php' in google to get them.
>A very well known one is the DBG debugger.

Thanks for the info. I assume it's more a profiler than a debugger.
Hopefully, they're easy to add to a production site without breaking
anything, and that it will easily show what is causing this surge in
CPU load after hours of normal operation.

Toby A Inkster

unread,
Mar 13, 2007, 10:59:21 AM3/13/07
to
Vincent Delporte wrote:

> Someone I know is running some Web 2.0-type web site that lives on a
> shared host, and is experiencing 100% CPU load after a few hours.

I would suggest that the number one thing to check is:

/usr/bin/top

to establish exactly what process is causing the big CPU usage. Your next
stage of investigation will depend on what "top" tells you.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact
Geek of ~ HTML/SQL/Perl/PHP/Python*/Apache/Linux

* = I'm getting there!

Toby A Inkster

unread,
Mar 13, 2007, 11:16:49 AM3/13/07
to
Vincent Delporte wrote:

> Some kind of social site

These sorts of things usually develop into having some pretty big database
tables.

Do you have any "big" tables (say, 2000 rows or more)? Which columns do
you routinely query those big tables by, or join them on? Are those columns
indexed?

Are you using inappropriate data types? (e.g. Storing dates in a varchar
field, which although possible, is very inefficient for queries.)

Do you unnecessarily use "SELECT * FROM ..." when "SELECT x, y FROM ..."
would suffice?

Vincent Delporte

unread,
Mar 13, 2007, 11:21:31 AM3/13/07
to
On Tue, 13 Mar 2007 15:16:49 +0000, Toby A Inkster
<usenet...@tobyinkster.co.uk> wrote:
>These sorts of things usually develop into having some pretty big database
>tables.

Will forward your suggestions, including "top" (although it's a shared
host, so probably no shell).

FWIW, it works fine for hours at a time, and poof. At this point, it
is unknown if it's a DoS or some bug in the code that would only show
after... a while.

Toby A Inkster

unread,
Mar 13, 2007, 1:51:09 PM3/13/07
to
Vincent Delporte wrote:

> although it's a shared host, so probably no shell

If it's a shared host, then what makes you think that it's your friend's
site that is using all the CPU? It could be another customer's site on the
same server.

Vincent Delporte

unread,
Mar 13, 2007, 4:21:34 PM3/13/07
to
On Tue, 13 Mar 2007 17:51:09 +0000, Toby A Inkster
<usenet...@tobyinkster.co.uk> wrote:
>If it's a shared host, then what makes you think that it's your friend's
>site that is using all the CPU? It could be another customer's site on the
>same server.

According to the hoster, it's his site that's causing the problem. I
assume they have monitoring tools that tells them whose processes are
using the host's resources.

Kimmo Laine

unread,
Mar 13, 2007, 3:00:58 PM3/13/07
to
Erwin Moller kirjoitti:

> Vincent Delporte wrote:
>
>> Hello
>>
>> Someone I know is running some Web 2.0-type web site that lives on a
>> shared host, and is experiencing 100% CPU load after a few hours. At
>> this point, his provider couldn't tell if it's due to a DoS attack, or
>> a bug in his application.
>
> Web2. A very vague description. :P

I suppose the performance hit comes from the extrem popularity of the
website, after all, it's web 2.0 for crying out loud! ;)


--
"En ole paha ihminen, mutta omenat ovat elinkeinoni." -Perttu Sirviö
sp...@outolempi.net | Gedoon-S @ IRCnet | rot13(xv...@bhgbyrzcv.arg)

Vincent Delporte

unread,
Mar 18, 2007, 12:25:09 PM3/18/07
to
On Tue, 13 Mar 2007 21:00:58 +0200, Kimmo Laine <sp...@outolempi.net>
wrote:

>I suppose the performance hit comes from the extrem popularity of the
>website, after all, it's web 2.0 for crying out loud! ;)

Nope. The same site would crawl to a snail's space with about 40
concurrent users, while it can easily handle 200 users after being
moved to an hoster, even though both servers where shared. Guess it
was due to configuration.

We still have to investigate why the new host sometimes ends up using
100% CPU time, though.

0 new messages