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.
> 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.
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.
> 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!
> 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?
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.
> 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.
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.
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)
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.