Ensuring that your end users get the performance they expect from your system requires an organized approach to performance management. This session will cover the planning and measurement necessary to ensure satisfied customers, and will also include tips and tricks learned from MariaDB’s years of supporting many of the most demanding installations in the world.
5. • Service Level Agreements (SLAs)
– Individual Biz/App Transactions
– Throughput
– Latency (at percentile)
– Peaks of peaks or favorable scheduling?
• Translate to Database Transactions
Define Target
10. • Dedicated Server
• Memory
– More usually helps (up to ~dataset size)
– Important with read-heavy + slow disk
• More CPUs
– Highly concurrent use cases
– Usually favored over faster CPUs
• Faster CPUs
– Less concurrent use cases
– Dataset fits in memory
Database Server
11. • Local or SAN over NAS
– Performance
• SSD over HHD
– Performance and MTBF
– SSD wear not usually a factor
• SSDs
– Consumer
– Prosumer
– PCIe
– NVMe
Storage
12. • Can be Bandwidth Hungry
– Regular client traffic
– Replication Traffic
– Rebuilding replicas from snapshots
• Stability matters for Replication
• Sometimes overlooked as potential
bottleneck
• Efficient DNS setup*
Network
13. • vm.swappiness = 10
• ext4 or xfs for data files
• noatime for filesystem mounts
• ulimit changes
OS (Linux)
mariadb.com/kb/en/library/operating-system-optimizations/
19. • Runtime changes via SET GLOBAL
• Make permanent with changes to my.cnf
– Make sure you have right my.cnf
– Verify with SHOW GLOBAL
• One change at a time
• Production changes
– tested, reviewed, version controlled
Changing Config
Settings
my.cnf
23. Finding Slow
Queries
slow_query_log = 1
slow_query_log-file = /var/lib/mysql/myslow.log
long_query_time = 10
Pay attention to similar queries and the
query count
24. Analyzing Slow
Queries
EXPLAIN
SELECT *
FROM employees
WHERE MONTH(birth_date) = 8 G
id: 1
select_type: SIMPLE
table: employees
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 299587
Extra: Using where
25. • Poor Indexing #1 Reason for poor
performance
• Basics of B-Tree Indexing same across
relational systems
• Space/Performance Tradeoff
• Write/Read Tradeoff
Indexing
27. Query Tuning
SHOW STATUS
Global or Session
● Returns List of Internal Counters
● GLOBAL for System-Wide Status — Since
Start-Up
● SESSION for Local to Client Connection
● FLUSH STATUS Resets Local Counters
● Monitor Changes to Counters to Identify Hot
Spots
● Collect Periodically Status Snapshots to Profile
Traffic
28. Query Tuning
PERFORMANCE_SCHEMA
● Similar to INFORMATION_SCHEMA , but
Performance Tuning
● Monitors MariaDB Server Events
● Function Calls, Operating System Waits, Internal
Mutexes, I/O Calls
● Detailed Query Execution Stages (Parsing,
Statistics, Sorting)
● Some Features Storage Engine Specific
● Monitoring Lightweight and Requires No
Dedicated Thread
● Designed to be Used Iteratively with Successive
Refinement