I am running tuning-primer.sh and mysqltuner.pl
mysqltuner.pl says:
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
Adjust your join queries to always utilize indexes
When making adjustments, make tmp_table_size/max_heap_table_size equal
Reduce your SELECT DISTINCT queries without LIMIT clauses
Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
join_buffer_size (> 128.0K, or always use indexes with joins)
tmp_table_size (> 50M)
max_heap_table_size (> 50M)
table_cache (> 4096)
tuning-primer.sh returns
TEMP TABLES
Current max_heap_table_size = 50 M
Current tmp_table_size = 50 M
Of 7970 temp tables, 30% were created on disk
Perhaps you should increase your tmp_table_size and/or max_heap_table_size
to reduce the number of disk-based temporary tables
Note! BLOB and TEXT columns are not allow in memory tables.
If you are using these columns raising these values might not impact your
ratio of on disk temp tables.
JOINS
Current join_buffer_size = 132.00 K
You have had 310 queries where a join could not use an index properly
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
If you are unable to optimize your queries you may want to increase your
join_buffer_size to accommodate larger joins in one pass.
Note! This script will still suggest raising the join_buffer_size when
ANY joins not using indexes are found.
I would like to know if changing these settings will actually help given what is in myslow table log?
I see that there are a number of joins across spaces and og, there are system calls that seem to take forever, and calls to views_display that take a long time. Are views in the blob format?
How can I pair this down so that each does not take so much time?
Here are a few examples (the rest are in the slow query log)
Time: 110314 17:45:13
User@Host: my-site-db[my-site-db] @ localhost []
Query_time: 19.464210 Lock_time: 0.000000 Rows_sent: 0 Rows_examined: 0
SET timestamp=1300139113;
SELECT DISTINCT t.tid, t.*, parent FROM term_data t INNER JOIN term_hierarchy h
ON t.tid = h.tid
LEFT JOIN term_node spaces_og_tn ON t.tid = spaces_og_tn.tid
LEFT JOIN vocabulary spaces_og_v ON t.vid = spaces_og_v.vid
LEFT JOIN og_ancestry spaces_og_oga ON spaces_og_tn.nid = spaces_og_og
a.nid
LEFT JOIN node spaces_og_n ON spaces_og_oga.group_nid = spaces_og_n.ni
d WHERE ((spaces_og_oga.group_nid IS NULL) OR (spaces_og_v.tags = 0) OR (spaces_
og_oga.group_nid IN (645, 167, 204, 476, 644, 177, 641, 479, 1, 201) AND spaces_
og_n.status = 1)) AND ( t.vid = 155 )ORDER BY weight, name;
Time: 110314 19:45:38
User@Host: root[root] @ localhost []
Query_time: 16.719973 Lock_time: 0.000040 Rows_sent: 646 Rows_examined: 646
SET timestamp=1300146338;
SHOW TABLES FROM my-site-db;
Time: 110314 19:46:21
User@Host: developmentsocia[developmentsocia] @ localhost []
Query_time: 30.343935 Lock_time: 0.000043 Rows_sent: 1 Rows_examined: 1
use developmentsocia;
SET timestamp=1300146381;
SELECT data, created, headers, expire, serialized FROM cache WHERE cid = 'schema
';
Time: 110314 19:46:34
User@Host: my-site-db[my-site-db] @ localhost []
Query_time: 17.853698 Lock_time: 0.000000 Rows_sent: 0 Rows_examined: 0
use my-site-db;
SET timestamp=1300146394;
SELECT m.load_functions, m.to_arg_functions, m.access_callback, m.access_argumen
ts, m.page_callback, m.page_arguments, m.title, m.title_callback, m.title_argume
nts, m.type, m.description, ml.*
FROM menu_links ml LEFT JOIN menu_router m ON m.path = ml.router_path
WHERE ml.menu_name = 'admin' AND ml.plid IN (83906, 83912, 83986, 0)
ORDER BY p1 ASC, p2 ASC, p3 ASC, p4 ASC, p5 ASC, p6 ASC, p7 ASC, p8 AS
C, p9 ASC;
Time: 110314 19:46:35
User@Host: my-site-db[my-site-db] @ localhost []
Query_time: 63.911864 Lock_time: 0.000000 Rows_sent: 0 Rows_examined: 0
SET timestamp=1300146395;
SELECT * FROM views_display WHERE vid IN (1, 2, 3, 4, 5, 24, 7, 8, 9, 12, 11, 13
, 14, 15, 16, 17, 19, 20, 21, 22, 23, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35
, 36, 37, 38, 39, 40, 41, 42, 45, 44, 46, 47, 48, 49, 120, 121, 51, 53, 56, 55,
57, 58, 59, 61, 62, 90, 64, 77, 70, 71, 72, 73, 74, 75, 78, 83, 84, 81, 82, 85,
86, 87, 88, 89, 91, 92, 131, 94, 95, 96, 97, 101, 100, 102, 105, 106, 107, 108,
109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 122, 123, 124, 125, 126,
127, 128, 130, 132, 133, 134, 135, 138, 139, 140, 141, 142, 143, 144, 145, 146,
147) ORDER BY vid, position;
Time: 110314 19:47:25
User@Host: my-site-db[my-site-db] @ localhost []
Query_time: 19.168750 Lock_time: 0.000095 Rows_sent: 1 Rows_examined: 1
SET timestamp=1300146445;
SELECT n.nid, n.type, n.language, n.uid, n.status, n.created, n.changed, n.comme
nt, n.promote, n.moderate, n.sticky, n.tnid, n.translate, r.vid, r.uid AS revisi
on_uid, r.title, r.body, r.teaser, r.log, r.timestamp AS revision_timestamp, r.f
ormat, u.name, u.picture, u.data FROM node n INNER JOIN users u ON u.uid = n.uid
INNER JOIN node_revisions r ON r.vid = n.vid WHERE n.nid = 610;
Time: 110314 19:47:36
User@Host: root[root] @ localhost []
Query_time: 21.617820 Lock_time: 0.000178 Rows_sent: 646 Rows_examined: 646
SET timestamp=1300146456;
SHOW TABLE STATUS FROM my-site-db;
User@Host: root[root] @ localhost []
Query_time: 22.144506 Lock_time: 0.000157 Rows_sent: 646 Rows_examined: 646
SET timestamp=1300146456;
SHOW TABLE STATUS FROM my-site-db;

Comments
I would like to know if
Possibly. Though looking at these queries, you might be able to gain more from optimizing the queries, rather than tuning the server. Run EXPLAIN on the queries, are indexes being used? Are the LEFT joins necessary? Can you get rid of the DISTINCT? GROUP BY usually performs better. ORs in WHERE clauses often perform poorly, you might experiment with UNIONs instead.
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his