{"id":1140889,"date":"2009-07-13T18:12:30","date_gmt":"2009-07-13T18:12:30","guid":{"rendered":"https:\/\/wordpress.org\/support\/topic\/slow-database-help\/"},"modified":"2016-08-19T13:23:41","modified_gmt":"2016-08-19T13:23:41","slug":"slow-database-help","status":"closed","type":"topic","link":"https:\/\/wordpress.org\/support\/topic\/slow-database-help\/","title":{"rendered":"Slow Database help"},"content":{"rendered":"<p>My blog has become exceedingly slow at most times, yet sometimes it is fine.  I know little about databases, so below is the run-time information that displays in Red:<\/p>\n<p>Connections Failed attempts: .01%<br \/>\nConnections Aborted: .15%<\/p>\n<p>Innodb_buffer_pool_pages_dirty\t23 The number of pages currently dirty.<\/p>\n<p>Innodb_buffer_pool_reads\t42 M\t The number of logical reads that InnoDB could not satisfy from buffer pool and had to do a single-page read.<\/p>\n<p>Innodb_row_lock_time_avg\t78 k\t The average time to acquire a row lock, in milliseconds.<\/p>\n<p>Innodb_row_lock_time_max\t429 k\t The maximum time to acquire a row lock, in milliseconds.<\/p>\n<p>Handler_read_rnd_next\t1,952 M\t 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.<\/p>\n<p>Qcache_lowmem_prunes\t91 k\t 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.<\/p>\n<p>Slow_launch_threads\t24\t The number of threads that have taken more than slow_launch_time seconds to create.<\/p>\n<p>Created_tmp_disk_tables\t27 k\t 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.<\/p>\n<p>Key_reads\t234 k\t 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.<\/p>\n<p>Select_full_join\t3,521\t The number of joins that do not use indexes. If this value is not 0, you should carefully check the indexes of your tables.<\/p>\n<p>Select_range_check\t6\t 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.)<\/p>\n<p>Sort_merge_passes\t99 k\t 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.<\/p>\n<p>Opened_tables\t171 k\t The number of tables that have been opened. If opened tables is big, your table cache value is probably too small.<\/p>\n<p>Table_locks_waited\t1,817\t 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.<\/p>\n<p>Help!<\/p>\n","protected":false},"template":"","class_list":["post-1140889","topic","type-topic","status-closed","hentry"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/wordpress.org\/support\/wp-json\/wp\/v2\/topic\/1140889","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wordpress.org\/support\/wp-json\/wp\/v2\/topic"}],"about":[{"href":"https:\/\/wordpress.org\/support\/wp-json\/wp\/v2\/types\/topic"}],"version-history":[{"count":0,"href":"https:\/\/wordpress.org\/support\/wp-json\/wp\/v2\/topic\/1140889\/revisions"}],"wp:attachment":[{"href":"https:\/\/wordpress.org\/support\/wp-json\/wp\/v2\/media?parent=1140889"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}