rc3.org

Strong opinions, weakly held

Never before seen

Today I got an email from TextDrive saying that this humble Web site is causing my server to spend 40-50% of its CPU time on MySQL rather than the standard 3-9% and that they had to put some limits on my MySQL use to solve the problem, at least until I fix my code. What’s interesting is that the only thing I’m running is an out of the box install of Movable Type 3.2. My Web site is probably a little different than most MT installs because there are bunches of entries, but that shouldn’t be a big deal. I run all of the archive pages dynamically, which is definitely the root of the problem (if all my pages were statically served, there would be no MySQL overhead). I’ve asked them to send me the MySQL slow queries log, maybe that will hold some clues.

3 Comments

  1. It wouldn’t be so bad if your blog wasn’t worth so darn much!

    🙂

  2. That sounds really odd. I’ve done many dozens of installs of MT 3.2 on all kinds of different servers and hosting providers and have never seen a single install of MT 3.2 use that many resources.

    While it’s true that rendering the site dynamically increases the number of requests to MySQL, unless it were doing hundreds of requests a second I can’t see how youd exceed their quota so quickly.

    It may be possible that your site was being visited by some overzealous spambots, indexers, and spidering engines which if not programmed correctly will try to index an entire site as quickly as possible — which means if your hosting provider’s server isn’t fast enough to handle the traffic/requests they’ll queue up.

    I would have your hoting provider examine your log files carefully to see if the requests were all coming from a single source. if so, then it’s likely a problem with a poorly-programmed indexing spider.

  3. Do let us knwo what you find. I mean, if it were a general problem with MT, it would have been all over the web by now.

Leave a Reply

Your email address will not be published.

*

© 2024 rc3.org

Theme by Anders NorenUp ↑