<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Beating the Life Out of My Database</title>
	<atom:link href="http://www.gnorb.net/679/beating-the-life-out-of-my-database/feed" rel="self" type="application/rss+xml" />
	<link>http://www.gnorb.net/679/beating-the-life-out-of-my-database</link>
	<description>Fiction has to be plausible. Reality is under no such constraint.</description>
	<lastBuildDate>Thu, 26 Jan 2012 04:13:35 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Nathan Smith</title>
		<link>http://www.gnorb.net/679/beating-the-life-out-of-my-database#comment-11166</link>
		<dc:creator>Nathan Smith</dc:creator>
		<pubDate>Sun, 19 Nov 2006 20:58:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.gnorb.net/gnorbnet-updates/20061115/beating-the-life-out-of-my-database/#comment-11166</guid>
		<description>As your former hosting service provider, I can tell you, that when you were on my server in Edmonton, I wrote a special script - to keep my server from outright collapsing. Remember the &quot;server temporarily unavailable&quot; messages. Basically what the script did, was take down apache and throw up a temporarily unavailable page (complete with the proper error code # so the search engines would understand) until the CPU load went back down to normal. That script kept a log of every time it kicked into effect. Since you left my humble server well, that script hasn&#039;t logged one single event. (Apparently your new provider does something similar to prevent one site from collapsing the server).
.
I think the problem has to do with your flattened URLS. (URL rewrites). Then again I also have a wordpress blog that gets a fair amount of traffic, and it has never blown up the server. 
.
The answer to your problem is a complex one. I can tell you that for sure it&#039;s releated to MySQL. What you would need to do, is log MySQL queries or use phpMyAdmin or Mysql&#039;s admin tools to tell you what queries are causing the problem (queries that take a long time to execute). Then locate what php script is making that query. To fix the problem - either stop using the php script (if it&#039;s a module turn it off), or rewrite the query so it&#039;s more efficent, or fix the database structure to make it more efficient. 
.
The other way to troubleshoot is by using the process of elimination method. Turn off one module at a time or disable one script at a time and see if the problem stops happening. 
.
Good luck.
Nate</description>
		<content:encoded><![CDATA[<p>As your former hosting service provider, I can tell you, that when you were on my server in Edmonton, I wrote a special script &#8211; to keep my server from outright collapsing. Remember the &#8220;server temporarily unavailable&#8221; messages. Basically what the script did, was take down apache and throw up a temporarily unavailable page (complete with the proper error code # so the search engines would understand) until the CPU load went back down to normal. That script kept a log of every time it kicked into effect. Since you left my humble server well, that script hasn&#8217;t logged one single event. (Apparently your new provider does something similar to prevent one site from collapsing the server).<br />
.<br />
I think the problem has to do with your flattened URLS. (URL rewrites). Then again I also have a wordpress blog that gets a fair amount of traffic, and it has never blown up the server.<br />
.<br />
The answer to your problem is a complex one. I can tell you that for sure it&#8217;s releated to MySQL. What you would need to do, is log MySQL queries or use phpMyAdmin or Mysql&#8217;s admin tools to tell you what queries are causing the problem (queries that take a long time to execute). Then locate what php script is making that query. To fix the problem &#8211; either stop using the php script (if it&#8217;s a module turn it off), or rewrite the query so it&#8217;s more efficent, or fix the database structure to make it more efficient.<br />
.<br />
The other way to troubleshoot is by using the process of elimination method. Turn off one module at a time or disable one script at a time and see if the problem stops happening.<br />
.<br />
Good luck.<br />
Nate</p>
]]></content:encoded>
	</item>
</channel>
</rss>

