Project Description:
we run a busy website and IPB forums that has been having ongoing performance issues since a recent IPB software upgrade
our server managers insist the issue is with our forum software code, but our forum software managers believe the issue is with the servers.
we are at a stalemate and need a MYSQL expert to come in and find the bottlenecks in the database code or determine if this is a server issue and advise and assist us to setup a new server and hosting.
++++++++++++++++++++
> more specifically :
> > ----------
> > Slow_queries 110
> > The number of queries that have taken more than long_query_time seconds.
> > ----------
> > Handler_read_rnd 4,258 k
> > 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 1,903 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 23 k
> > 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.
> > ----------
> > Created_tmp_disk_tables 258 k
> > 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.
> > ----------
> > Select_full_join 15
> > The number of joins that do not use indexes. If this value is not 0, you should carefully check the indexes of your tables.
> > ----------
> > Opened_tables 2,687
> > The number of tables that have been opened. If opened tables is big, your table cache value is probably too small.
> > ----------
> > Table_locks_waited 287 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.
> > ----------
