Will Optimizer help me or do I have deeper issues?

[rootsxrocks]

OK that was a loaded question I do Run 4.06 I am talking about MY SQL. I am once again getting slow as molasses and I am hoping it is not VB credits that I recently installed. These values are indicated to be abnormal in my report. Is this normal with vbulletin. or are these issues that optimizer will help fix? The only add ons I am running are Vbcredits deluxe V3Arcade Gameroom and Vbookie. I am clueless about what these mean but I am trying to learn.

• Slow_queries 34 k The number of queries that have taken more than long_query_time seconds. FPRIVATE "TYPE=PICT;ALT=Documentation"
• Handler_read_rnd 3,324.26 M The number of requests to read a row based on a fixed position. This is high if you are doing a lot of queries that require sorting of the result. You probably have a lot of queries that require MySQL to scan whole tables or you have joins that don't use keys properly.
• Handler_read_rnd_next 590 M The number of requests to read the next row in the data file. This is high if you are doing a lot of table scans. Generally this suggests that your tables are not properly indexed or that your queries are not written to take advantage of the indexes you have.
• Qcache_lowmem_prunes 237 M The number of queries that have been removed from the cache to free up memory for caching new queries. This information can help you tune the query cache size. The query cache uses a least recently used (LRU) strategy to decide which queries to remove from the cache.
• Threads_cached 8 The number of threads in the thread cache. The cache hit rate can be calculated as Threads_created/Connections. If this value is red you should raise your thread_cache_size.
• Created_tmp_disk_tables 37 M The number of temporary tables on disk created automatically by the server while executing statements. If Created_tmp_disk_tables is big, you may want to increase the tmp_table_size value to cause temporary tables to be memory-based instead of disk-based.
• Key_reads 496 M The number of physical reads of a key block from disk. If Key_reads is big, then your key_buffer_size value is probably too small. The cache miss rate can be calculated as Key_reads/Key_read_requests.
• Select_full_join 7,895 k The number of joins that do not use indexes. If this value is not 0, you should carefully check the indexes of your tables.
• Select_range_check 242 k The number of joins without keys that check for key usage after each row. (If this is not 0, you should carefully check the indexes of your tables.)
• Sort_merge_passes 78 k The number of merge passes the sort algorithm has had to do. If this value is large, you should consider increasing the value of the sort_buffer_size system variable.
• Opened_tables 99 M The number of tables that have been opened. If opened tables is big, your table cache value is probably too small.
• Table_locks_waited 236 k The number of times that a table lock could not be acquired immediately and a wait was needed. If this is high, and you have performance problems, you should first optimize your queries, and then either split your table or tables or use replication.

 

[rootsxrocks]

my forum is very small.

 

[Mokonzi]

What sort of hosting are you on? Shared, or VPS? Shared can sometimes produce issues if other sites on the same server are taking up more resources (I've myself been the cause of this with my forum one site).

 

[Deceptor]

vB Optimise will relieve some stress on MySQL but if your service is under stress from a specific point and not overall it won't help much, if you have Lite installed you can give that a go - it can't hurt.

As for your report, it indicates slow queries - do you know if they're logged anywhere? Might be best asking your host if they are so you can take a look at the queries potentially slowing the MySQL service down, that'd help pin-point your issue. Ofcourse if you're on a shared server/VPS, it could simply be another user on the website consuming resources.