Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

Hi all of a sudden my server has slowed to a crawl, queries that were 0.10 of a second consistently now taking 20 seconds. somewhat randomly, sometimes it snaps right back. so I have a really sudden and harsh performance problem.

I ran mysqltuner.pl and it reported one thing that might be a problem :

[!!] Table cache hit rate: 0% (400 open / 1M opened)

I am just starting to delve into this performance problem, but does anyone know if this a big immediate red flag?

I can do some DD but am pressed right now. any help much appreciated.

Don

share|improve this question

migrated from stackoverflow.com Jul 3 '12 at 2:50

This question came from our site for professional and enthusiast programmers.

3 Answers 3

up vote 1 down vote accepted

I have seen this problem when a table being frequently table scanned no longer fits in memory. Instead of reading data from cache, the data is read from disk. This will flush data out on a LRU (Least Recently Used) basis. As a result you will be constantly reading the data back in for the next table scan cycle.

If you have it available run sar to determine which disk partition has high IO. This is more useful if you have distributed your database over more than one disk or partition. Also check to see if memory is being paged heavily.

Check your slow queries log and run explain plans on the queries. This should help identify the problem table.

A similar problem can happen if you no longer have enough free memory to keep the database buffers in memory. This will cause part or all of the database's memory to be paged out. It will soon be paged in. This is often called thrashing.

share|improve this answer
    
Hi Bill thx for the response. I only have one disk partition, which is an SDD. –  Don Wool Jul 4 '12 at 7:50
    
the SDD looks like this : –  Don Wool Jul 4 '12 at 7:50
    
/dev/sda1 156030876 16166480 132052556 11% /data –  Don Wool Jul 4 '12 at 7:51
    
Is there an advantage of spreading a database across multiple disk partitions? disks are so big now, that I thought doing that was obviated. If one were to do so, would you try and put different tables on certain partitions? Note : I would think this becomes harder in a RAID environment. then again, maybe the RAID lets you do this. will investigate sar (not currently installed on system). thx again for the reply. –  Don Wool Jul 4 '12 at 7:53
    
Spreading databases over multiple disks is done to provide allow higher throughput. Splitting index and data partitions on different disks allows data to be read or written on one disk whie to complete while other disk is performing a seek. RAID can provide similar benefits in slitting I/O across disks. SSDs minimize seek time, so splitting across disks may not be as beneficial. –  BillThor Jul 6 '12 at 0:43

The query cache was only hit 400 out of 1,000,000 times.

That is a query cache hitrate of 0.04 %

This indicates that 99.96% of your queries are unique and are not reusable. That's not unusual if your are storing session data, doing blogging, audit trails, or just plain logging of events.

While you could setup slow query logging, there is a better approach to checking on SQL performance. I recommend using pt-query-digest with --processlist option or --tcpdump option

This will allow you to catch bad queries in the act of being bad.

share|improve this answer
    
Most of my database access is thru stored procedures. I believe this is the culprit. 'selects' snap back so fast frankly it almost scares me. The problem I have is writing. I wrote a post on it here. dba.stackexchange.com/questions/20372/… –  Don Wool Jul 4 '12 at 7:56
    
by the way I am on Percona. not sure if that impacts your choice on suggested SQL Performance tools? –  Don Wool Jul 4 '12 at 7:58

There are many things to look at, including:

I'd suggest turning on the "slow-query-log" ASAP:

Also look at these parameters:

share|improve this answer
    
well, I know which queries are taking a long time as I said "queries that were 0.10 of a second consistently now taking 20 seconds". indicies are being used on all tables in these queries. It just went off a cliff with no warning! thx. –  Don Wool Jul 2 '12 at 18:25

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.