Understanding enormous numbers in SQL status report

Events happening in the community are now at Drupal community events on www.drupal.org.
TheHoaryHound's picture

Can one of you experts out there help me with this?

In a brand-new, <10 node Drupal 5.1 site running with MySQL 4.1.21 and PHP 5.0.5, on Appache at www.siteground.com

When looking at admin->logs->status->MySQL (4.1.21)

I'm getting some HUGE numbers, where zeros are expected. Can someone provide some guidance or words of wisdom?

Some of the report is listed below. PS--I can't figure out where to get help, no one answers posts at Drupal.org or at siteground.com, and I feel like there's no one out here!!

Qcache_queries_in_cache 36980 The number of queries in the query cache.

Qcache_hits 92144336 The number of times that MySQL found previous results in the cache.

Qcache_inserts 25240480 The number of times that MySQL added a query to the cache (misses).

Qcache_lowmem_prunes 7310257 The number of times that MySQL had to remove queries from the cache because it ran out of memory. Ideally should be zero.

THANK YOU ALL

Comments

shared hosting?

greggles's picture

My guess is that this is related to the way that they have configured databases on their servers and the fact that you are on a shared machine with many other users. Is that correct? Or is this a dedicated machine?

The "Ideally should be zero" advice is probably most relevant when you have your own database environment that you can control. I'm not sure if that report is as relevant on a shared environment.

As to not getting support, I think this is a tricky question which may not have a really good answer. For siteground, they probably have many problems in their queue to attend to before they can get to a specific report in a specific content management system for one customer - especially when they charge so little each month.

Are you experiencing performance problems that you hope to address by tuning mysql? The first thing in my mind would be to enable caching at admin > site configuration > performance. That should help a lot. Beyond that it's hard to say, but tuning mysql on a shared environment is generally difficult or impossible.

--
Knaddisons Denver Life | mmm Free Range Burritos

TheHoaryHound's picture

Greg,

Thanks for the info. Yes, I am on a shared server...so that is probably the problem.

Sorry for this potentially dumb follow on question....but,

are you saying that the statistics revealed on my status page are for all the MySQL server implementations on the server? Or, just that my implementation is less than optimal because of how the other users are taxing the system?

In either case, it sounds like something I shouldn't worry about...although I hate seeing those numbers so big. The drupal setup is working OK (only 4 nodes!!), although their are some quirks with menu items getting "sticky".

Thanks again for your reply.

My host is www.siteground.com and they will not even accept this type of question, let alone respond to it.

yes to both

greggles's picture

Basically yes to both :)

It could be because your server is shared by many people, or that it's just tuned in a way that makes your analysis page look bad but is in a manner that your hosting provider has found to be best for the shared setup.

But yes, it's probably not worth worrying about.

Best luck!

--
Knaddisons Denver Life | mmm Free Range Burritos

check tmp_tables too

eli's picture

Do a "show global status like '%tmp%'" too.

If the "Created_tmp_disk_tables" is large you may have the same problem I ran into: http://drupal.org/node/171685 It was absolutely killing the server.

edit:Though the above caveat about shared hosting enviornments still applies. If you really want stats for just your site on the shared server, you could probably hack Drupal to dump a "show session status" at the end of every request. Take a bit of work though.

High performance

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: