7 deadly sins - percona · overallocation of memory • people go hog wild on per session buffers...
TRANSCRIPT
7 (or so) Deadly Performance Sins
Martin Arrieta - Senior DBA @Percona
Same old Story
• We tend to get the same issues over and over again
• Customers face similar challenges • Some fixes are very easy and we need to
promote common knowledge
2
Let’s learn from others mistakes3
Deadly Sin #1
More is not always better
4
• If 1 is good, 2 is better right? • Lots of people resolve issues by throwing
more resources at it, this does not always work
5
Overallocation of Memory
• People go hog wild on per session buffers like read_buffer, read_rnd_buffer, join_buffer, and sort_buffer.
• What is the maximum amount of memory that MySQL can use?: • Per-session buffers * max connections • + buffer pool size • + key buffer size • + some other buffers
6
Swapping is well known
• Most people know that swapping is bad, but they still over-allocate memory
• Did you know disabling swap can be bad as well?
• TIP: Swappiness • sudo sysctl -w vm.swappiness=1 • echo 1 > /proc/sys/vm/swappiness
7
More and More Indexes
• A lot of people is still indexing every column • Waste Space • Waste Memory • Slow down inserts/updates/deletes
• Multi-key indexes are better than index merges
8
Deadly Sin #2
Default Configurations
9
• Don't leave the my.cnf as default configs! • MyISAM is the default storage engine on
<= 5.5.4 • I have seen companies spend tens of
thousands of dollars on big hardware but not allocate memory to the database.
10
my.cnf
• Minimally set: • InnoDB • Buffer pool size • Log size • Transaction commit
• Key Buffer (still using MyISAM?) • Query cache
11
my.cnf Parameters
• innodb_buffer_pool_size - Size of buffer pool • innodb_log_file_size - Size of redo log
• innodb_flush_log_at_trx_commit - Flush method
• key_buffer_size - Buffer for MyISAM index buffers • query_cache_type and query_cache_size -
Query cache options
12
Deadly Sin #3
Using Too Much Space
13
How much data?
• What's this obsession with keeping data forever? • Purge your data! Is data from 1990
really needed? • Summarize old data • Do you need minute-by-minute or
hourly averages it is fine?
14
• There is a data Explosion going on • Afraid to get rid of things • Wasting space, just because we can • Using tools that design the tables for
us.
15
Choosing the right data type
• Thin is always better! • Smaller datatypes mean less storage per row on disk • Less storage per row means faster retrieval of rows • Less storage per row means more rows fit into
memory • Size especially matters with InnoDB PK's! (more later) • PK's are clustered indexes • Every subsequent index contains the PK!
16
Large on Disk = Large on Memory
• For instance: • 1M 8byte objects = 7.62MB of memory • 1M 4byte objects = 3.81MB • You could have saved 50% of your space
17
Integer data type18
Deadly Sin #4
Not Understanding Indexing
19
Avoid the *solo* index on every column
• Too many indexes slow down inserts/updates • Bloat disk and memory • Index merges can happen in some cases, but
they are slower then multiple key indexes • If the cardinality is bad, MySQL will ignore
them.
20
More on Indexes
• Remove redundant indexes • KEY ( id ) and KEY ( id, type ) are
redundant! • Order *does* matter • (name, lastname) != (lastname, name)
• Run explain plan to see which indexes are being used
21
GUID’s are *not* your friend
• GUID’s are 32 characters • If your using utf8, thats 3bytes per character, or 96
bytes per guid • In MySQL(InnoDB) the PK is duplicated in all
subsequent indexes • 10 Million row table with 5 indexes would mean you
could potentially need 96bytes * 5 * 10 million rows or about 4.5GB... using even a bigint (8 bytes ) instead would require about 400MB.
22
Deadly Sin #5
Bad backup strategy.
23
• Slave servers are NOT backups. • Taking backups from slave? Are you
checking the data consistency? • Do you test your backups regularly? • Using only logical backups? Is your boss
happy with the time of the restore process?
24
