Hi, I have been having a problem running php on my website. I have
installed gallery2 (from gallery.sourceforge.net) and have been
seeing many problems with it since I have added many images to it.
When anyone accesses a gallery2 page, the server load goes way up
and if I do "top -u" from a console, httpd is taking up anywhere
from 75% to 95% cpu time for about 10 seconds, which is about how
long the pages take to load.
Well gallery does do a lot of computations on the fly, specifically
it uses netpbm or imagemagick to manipulate images, which is
computationally intensive.
Al;sop remember that the goal of OSen is to maximize use of
resources, so seeing 100% CPU used effectively is what you should
expect.
I originally thought this might be a MySQL problem, since there is
performance problems with OS X Server and MySQL (threading). I
installed mysql on a linux server and replicated one of the gallery2
DBs, but I still get awful load times.
Does Gallery use MySQL? AFAIK it doesn't, but this may have changed
in a newer version.
What is the process that is using the CPU? That would be the telling facts.
The next thing I tried was using a different web server. I installed
lighttpd using DarwinPorts, along with the FastCGI module for php.
When I access the same page using lighttpd as the server, a php
process spawns and uses 75% - 95% cpu time for about 10 seconds, and
the web page still takes that long to load.
So perhaps my php is causing the problem? I upgraded to php 4.4.0,
same problem, then I tried the Marc Liyanage php package (4.3.11),
same result.
Sounds to me like you need to stop your schitzoid manouverings and
actually troubleshoot your issue.
I am at a loss as to what could be wrong. Could this be a hardware
fault? The blower fans on the XServe this is hosted on have failed,
but I don't see how that could affect this.
You're really reaching for straws.
Why not examine the actual processes and flow?
At 11:48 AM -0500 9/7/05, Jeremy Bush wrote:
There must be something wrong with the server this is being hosted
on. I copied all the data from my existing install to a brand new G5
server, and it ran flawlessly on the new server.
As the same code performs differently on the 2 machine, it must be
something to do with the server. But what? I am out of ideas...
OK this seems to indicate a gross misconfiguration.
First, have you turned OFF the performance cache???
At 10:27 AM +0100 9/8/05, Simon Slavin wrote:
The other server has been in use for lots of time. The new
server has no 'history' so the cache is nearly empty.
The cache isn't that big.
At 9:10 AM -0500 9/8/05, Jeremy Bush wrote:
The problem has nothing to do with apache, or settings in Server
Admin such as Performance Cache (which I always have off, btw).
This demonstrates a gross misconception of how things interoperate.
I ran the site under lighttpd, and instead of apache spawning procs
that take 10 seconds to finish, lighttpd would spawn php procs that
take 10 seconds to finish.
And this occurs after a clean install as well?
Last night I moved all the sites from the "bad" server to the new G5
server, and will monitor it closely for this behavior. The previous
server has been reformatted because it was exhibiting this behavior
previously, and I figured a fresh start would help it out. It had
previously ran 10.2, then upgraded to 10.3, then upgraded to 10.4,
and there is many things that could go wrong with all those upgrades.
I'd recommend a clean install and more careful configuration afterwords.
--
-dhan
------------------------------------------------------------------------
Dan Shoop AIM: iWiring
Systems & Networks Architect http://www.iwiring.net/
email@hidden http://www.ustsvs.com/
iWiring provides systems and networks support for Mac OS X, unix, and
Open Source application technologies at affordable rates.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macos-x-server mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/macos-x-server/email@hidden
