DB2 for LUW Performance: You ve got (frequently asked) questions, we ve got answers!

Size: px

Start display at page:

Download "DB2 for LUW Performance: You ve got (frequently asked) questions, we ve got answers!"

Elizabeth Nicholson
5 years ago
Views:

1 DB2 for LUW Performance: You ve got (frequently asked) questions, we ve got answers! Steve Rees IBM Canada Ltd. Session Code: D11 Wednesday November 10, 13:30 Platform: Linux / Unix / Windows Abstract You might think that DB2 performance question you have is a new, never-before-seen one, but chances are, someone's been there before you - so why not take advantage of that, and find out what they did to solve it? Following on from previous 'performance FAQ' sessions, this year's edition will bring you a new set of common DB2 performance questions (and answers!), to help save you time, should these problems come your way. Topics will include how to optimize utility performance, what are the best uses in a DB2 system for solid-state disks, what kind of a performance boost can be expected from the latest CPU architectures like Power7, how much benefit to expect from LOB inlining, as well as the performance impact of HADR synchronization settings, IDENTITY caching, and more. 1

2 A smorgasbord of performance FAQs! We look at a broad assortment of performance topics Things that are important, but tend to get not that much coverage Good things to know in day-to-day administration & development work, in order to get the best performance out of your system For example -- Impact of the latest in system & storage infrastructure? Cost / benefit of new DB2 features? Impact of tuning and configuration decisions? As they say It Depends! There will often be factors in your environment that influence the answers to these questions All the same, these are backed up by real-world experience & tests in the lab, and are intended to help fill in some common gaps in performance knowledge. 2 Some of topics for this session - What's the best way to configure sort resources for best LOAD and CREATE INDEX performance? What kind of a performance boost can I expect to get from moving up to a new CPU architecture like Power7 or Intel Nehalem? Solid-state disks can provide amazing I/O performance. How do I use them, to get the most 'bang for the buck'? HADR supports three different synchronization levels. What kind of performance impact can I expect from each one? Why do VOLATILE tables still need statistics?

1. How much of a boost can I expect with Power7? Cores / socket Threads / core Max clock speed rperf / 8 cores Power6 2 2 5 GHz 65 Power7 4-8 4 4.

3 1. How much of a boost can I expect with Power7? Cores / socket Threads / core Max clock speed rperf / 8 cores Power GHz 65 Power GHz 92 Power7 reduces individual thread clock speed but significantly increases thread density per socket Similar trend in the overall industry e.g. Intel Nehalem 8-core For well-parallelized DB2 workloads, Power7 can give up to 15-25% improved per-core performance over Power6 Naturally, this amount is affected by the Power6 & Power7 clock speeds in question, and the degree to which the workload is CPU bound 3 Power6 rperf: 03.ibm.com/systems/power/hardware/570/perfdata.html Power7 rperf: 03.ibm.com/systems/power/hardware/750/perfdata.html 3

4 #1 A tip for large (64+ thread) Power7 systems It can be a good idea to set NUM_IOCLEANERS (number of page cleaners, and number of castout engines in purescale) to the number of cores, rather than using AUTOMATIC and having it set based on the number of threads Very large numbers of threads can introduce contention and decrease efficiency in page cleaning Note applies to Nehalem and other highly-scaled (many-cored) architectures as well 4 4

5 2. Where / how / why should I use solid-state disks (SSDs) with DB2? SSDs offer an extremely high performance alternative to regular spinning disks Per-disk measurements Random I/Os / second Random I/O latency Sequential I/O throughput Spinning disks Up to ms Up to 100 MB/s Solid-state disks Up to 30,000 1 ms Up to 250 MB/s SSDs have the greatest benefit when used for highly random I/O Lab tests show up to a 10x improvement in system throughput in OLTP systems with broad use of SSDs What about log devices? Even though they are (small-write) sequential, they benefit greatly from low latency. Well worth considering! What about data warehousing? Again very useful for hot data, and especially temporary tablespaces 5 5

6 3. Do temporary tablespaces need their own bufferpool? Temp tablespaces breathe their data in and out Intermediate results from queries User temp tables Sorts Hash joins A good rule of thumb prior to 9.7 Data Warehouses don t typically benefit all that much from a separate temp bufferpool due to large temps and deep breaths This may also avoids the necessity of configuring & tuning another bufferpool But the smaller the temporary objects are and the more frequently that they come & go, the more benefit a separate bufferpool might provide 6 6

7 Do temporary tablespaces need their own bufferpool? When a temp object is dropped, all pages must be purged from the bufferpool Bufferpool pages to purge are found by either 1. Scanning the bufferpool dirty lists Very efficient for large temps, and small and/or mostly clean bufferpools Much less efficient for frequently dropped small temps in large and/or heavily dirty bufferpools 2. (New in DB2 9.7) Hashing to the BP page Done for small temps (size < 10% of dirty list size) Major improvement for small frequent temp creation/destruction! Applies to both SMS and DMS temps A separate temp BP may still help, but the need is much reduced, compared to previous versions #3 7 7

8 4. How much impact can I expect from enabling CURRENTLY COMMITTED? Prior to 9.7, CURSOR STABILITY (CS) applications could potentially block when trying to read a row that was locked for update by another application Updater has X lock, reader blocks & waits to get S lock Lock wait could be partly alleviated with registry variables like EVALUNCOMMITTED, SKIPINSERTED, SKIPDELETED - but this changes the semantics somewhat In 9.7, CURRENTLY COMMITTED (CC) allows readers to avoid the lock by providing them with the last committed value for the row 8 8

9 How much impact can I expect from enabling CURRENTLY COMMITTED? #4 Row R Zzzzz Row R A 1 A1 updates row R to R A 2 A 1 Row R Row R A2 now blocked until A1 commits, then gets R A1 updates row R to R A 2 A2 gets the committed value of row R Without CURRENTLY COMMITTED With CURRENTLY COMMITTED 9 9

10 How much impact can I expect from enabling CURRENTLY COMMITTED? #4 When is CC most likely to help? Applications showing significant reader/writer lock wait time Applications migrated from other database systems often benefit substantially from CC Workloads with fairly heavy reader/writer contention will generally show a 5-10% boost Lab tests showed up to a 20% decrease in lock wait, and a 28% increase in throughput with CC (your results may vary!) Tip a large log buffer size (LOGBUFSZ) helps CC find the committed version in memory, vs. reading from a log file Tip you can see CC activity via db2pd -locks Cur Commit Disk Log Reads 1771 Cur Commit Total Log Reads The default value for LOGBUFSZ has increased to 256 pages in 9.7, but for use with CC, a larger value is generally advised (e.g or 4096) 10

11 5. How much benefit does LOB inlining provide? Two important (& well-known) facts 1. LOBs don t live in the bufferpool they are read/written directly to disk by the agents, which can be much slower 2. LOB content frequently isn t all that big a few KB or less LOB inlining in DB2 9.7 exploits #2 to help reduce #1 Selectable on CREATE TABLE when LOB columns are present If LOB content of a row is small enough to fit in the inline area *, it is stored there, and no external LOB storage is required for that row Exploits the bufferpool to avoid separate reads & writes Compresses with the rest of the row data Decided on a row-by-row, LOB-by-LOB basis * Basically the page size, minus the size of the non-lob portion of the row 11 11

12 First will LOB inlining impact your table at all? How big are you willing to grow your rows? Adding inline LOBs grows row size NB increases footprint in the bufferpool E.g. maybe 1-3k for a 4k page, or 7k for an 8k page, etc.? Determine how many LOBs are within that range select count(*) from T where len(<lob_col>) <= <max desired inline size> #5 Potential caveats to be aware of Bufferpool consumption will increase due to larger rows All inlined LOBs are logged If LOB data is accessed very infrequently, it might be better left uninlined 12 12

13 #5 A tiny example of LOB inlining impact Transactional application, ~16 GB database size 4k page size, 1.5M page BP One CLOB(5000) column, average length 1300 bytes, updated in 40% of transactions Inline amount Tx / s BP data h/r Direct IO time/tx 0 bytes No LOBs inlined % 36 ms/tx 700 bytes 25% of my LOBs inlined % 3.5 ms/tx 1300 bytes 50% inlined % 2.4 ms/tx 1900 bytes 75% inlined % 1.4 ms/tx 2500 bytes All of my LOBs inlined % 0.32 ms/tx 13 13

14 6. What is non-buffered log I/O? Writes to the transaction log need to be hardened to disk WRITETHRU adds some performance overhead, but it s required for reliability Prior to 9.7, log I/O was buffered in the filesystem cache Provided quicker log reads for large rollbacks, recovery, etc. But also added some overhead to basic log write applications DB2_LOGGER_NON_BUFFERED_IO was added in 9.5 fp1 Defaulted OFF as in, No, I do not want unbuffered I/O (?!?) In 9.7 FP1, the default changes to AUTOMATIC ON: use unbuffered I/O for all log files AUTOMATIC: use unbuffered I/O for just the active log file, and buffered I/O for the inactive logs 14 14

15 #6 What is non-buffered log I/O? The new default can provide a small performance boost in heavy INSERT / UPDATE / DELETE systems Tip: make sure LOGBUFSZ is 1024 or larger to minimize the possibility of a degradation in ROLLBACK performance 15 15

16 7. How much benefit does caching have for IDENTITY columns and SEQUENCEs? IDENTITY / SEQUENCE give clean, robust mechanisms to obtain unique (generally ascending) values Frequently used to generate primary keys, etc. create table t (c1 int, c2 int not null generated always as identity (cache 20) ) A single SEQUENCE can be shared across multiple tables Otherwise they are very similar in behavior & implementation Caching enables a tradeoff between strict behavior and performance but how much? 16 16

17 Caching for IDENTITY columns and SEQUENCEs #7 In-memory cache Get next value 4,5,6,7,8,9 Quick, in-memory access 7 out of 8 times Get next value 4,5,6 With no caching, incur expensive log & catalog operations every time Log write & catalog access are expensive,but only happen 1 out of 8 times Log Catalog CREATE TABLE (CACHE 8) 1,2,3,4, ,6 Log Catalog CREATE TABLE (NO CACHE) 17 17

18 #7 Sample IDENTITY / SEQUENCE caching impacts ODBC transactional application on DB2 9.7 EE About 1800 tps overall when run w/o IDENTITY column 15% of transactions insert into table with IDENTITY column IDENTITY CACHE size (default) 5 2 No caching % overhead relative to no IDENTITY column 0 0 ~1% ~5% ~20% Impact of SEQUENCE caching is the same as for IDENTITY 18 18

19 #7 Other factors that affect ID / SEQ performance 1. The frequency that new values are obtained Greater insert rate means more potential overhead from the use of IDENTITY & SEQUENCE, and more benefit from increased caching 2. The system architecture Caching on DPF and purescale is even more important to good performance than on EE Obtaining the next value (or next cache of values) in DPF/pS requires a network flow to the catalog node Optimal DPF cache sizes are often much larger than the default some tuning is recommended 19 19

20 8. How much overhead will log mirroring add? Log mirroring provides an extra level of reliability against corruption, accidental log deletion, etc. DB2 overlaps primary & mirror log writes for better performance 2. Non-buffered ( writethru ) write to primary path DB2 Log Writer db2loggw 3. Flush the mirror write to disk Primary Log Path 1. Buffered write to mirror path Mirror Log Path 20 20

21 #8 Possible sources of overhead with log mirroring Increased pathlength (fairly small cost) Time to start & flush mirror path write (dominates) This is included in log write time and log wait time monitor metrics Contention between primary & mirror log writes Can be minimized by ensuring the paths don t overlap at any level - filesystem, logical volume, physical disk, etc. ** this is obviously important to maximize fault tolerance, too! Extra overhead can be more prominent in the presence of high INSERT / UPDATE / DELETE rates in the workload 21 21

22 Some lab measurements of log mirroring impact Sample data from the lab Medium-heavy OLTP test workload 7000 tps, 80% read / 20% write 16-way Power6, AIX 6, DB2 v97 fp2 DS4700 SAN controller, 96 disks #8 Conditions With good placement - Separate disk spindles With very poor placement - On the same spindles as the primary log TPS drop ~ 5-7 % ~ % 22 22

23 9. Why do VOLATILE tables still need statistics? The VOLATILE keyword indicates that the volume of data in a table can vary substantially, and biases plan selection toward indexes and away from tablescans 1. Index-only access is favored most strongly 2. Indexes which satisfy the predicates come next 3. List prefetch plans are never chosen Volatile can be very helpful when DB2 thinks (i.e., the latest statistics, if there are any, show) that the table is empty when actually it might have several thousand rows 23 23

24 #9 Why do VOLATILE tables still need statistics? VOLATILE is not magic What if there are multiple indexes that apply? What if it s used in a complicated query that depends on more than just avoiding a tablescan? Good statistics (even on VOLATILE tables) are still the best way to ensure a good plan & good performance Tip collect statistics on VOLATILE tables when there are a reasonable number of rows present And don t forget run-time statistics (a.k.a automatic RUNSTATS) will skip VOLATILE tables 24 24

25 10. How does sort heap affect LOAD performance? When loading data with indexes defined, SORTHEAP and SHEAPTHRES_SHR have a big impact on performance If N indexes are defined, LOAD starts N concurrent sorts Reaction to slow index creation in LOAD is often to just increase SORTHEAP not always a good idea Input File Media Reader db2lmr shmem Formatter Formatter db2lfrm Formatter db2lfrm Formatter db2lfrm Formatter db2lfrm Formatter db2lfrm Formatter db2lfrm Formatter db2lfrm db2lfrm shmem The Ridder handles sorting keys for index building in LOAD Ridder db2lrid shmem Simplified LOAD architecture Buffer Manipulator db2lbm Container Container Container 25

26 SORTHEAP & SHEAPTHRES_SHR The ratio of SHEAPTHRES_SHR & SORTHEAP should reflects the number of large concurrent sorts anticipated in the system SHEAPTHRES_SHR in 4k pages #10 Sort I Sort J Sort K Sort L Sort M Allocates full SORTHEAP Needs < full SORTHEAP Needs < full SORTHEAP Allocates full SORTHEAP Needs < full SORTHEAP SORTHEAP in 4k pages Sub-optimal case: ratio doesn t reflect number of large concurrent sorts in the system SHEAPTHRES_SHR in 4k pages Unused sort storage headroom within max defined by SHEAPTHRES_SHR Sorts at or near SHEAPTHRES_SHR may not get the sort memory they need Sort I Allocates full SORTHEAP Sort J Needs < full SORTHEAP but gets less than that Sort K Getting less than it needs Sort L Sort M SORTHEAP in 4k pages Overflow beyond SHEAPTHRES_SHR 26

27 Sort: Efficient vs. inefficient merges Good ratio good load performance 2, 3, 4, 5, Tournament tree 2, 3, 4, 5, 5 Ratio too low poor performance # : : : : Temp bufferpool Sort runs few, large spills to merge 1 pass required spills are large enough to prefetch simple tournament tree.. many tiny spills to merge up to 256,000 in pathological cases 2 passes required spills are too small to prefetch large, deep tournament tree extra pass, deeper tree & lack of prefetching can cause 1. Longer run time 2. Higher logical & physical reads 27

28 POOR-SORT-itis: Recognizing the problem if it happens Main symptoms Periodic very long LOAD / CREATE INDEX / sort durations Sort overflows counts # of spilled sorts, not # of times a sort spilled so not helpful as a diagnostic High sort time reported in monitors Many small I/Os on temp tablespace In worst case, not prefetched (synchronous vs asynchronous reads) For in-flight sorts, db2pd db <dbname> -sort reports the number and size of sort runs A large number of small sort runs indicates either a very small sortheap, or exhaustion of SHEAPTHRES_SHR #

29 11. What s the runtime performance impact of HADR? HADR provides disaster recovery support by shipping log records from a primary system to a standby system, where they are applied against another copy of the database SYNC mode t S Primary Log disk Standby Log disk Write primary log, then wait until standby log write finishes NEARSYNC mode (default) t N Primary Log disk Standby Log disk Send log record to standby, get ACK, then write primary log ASYNC mode t A Primary Log disk Standby Log disk Send log record to standby, then write primary log 29 29

30 What s the runtime performance impact of HADR? Relative performance of ASYNC vs NEARSYNC vs SYNC Generally: ASYNC is faster than NEARSYNC, faster than SYNC and obviously impacted by the workload The difference between ASYNC & NEARSYNC is largely determined by the link distance & speed between primary & standby The faster the link (e.g. for HA configurations over high-speed LAN), the smaller the difference. The difference between NEARSYNC & SYNC is largely determined by logging performance on the secondary The faster the log infrastructure, the smaller the difference In low-latency HA environments, SYNC can often be as fast as NEARSYNC! #

31 What s the runtime performance impact of HADR? Some other factors affecting HADR runtime performance Anything driving more log traffic (e.g. INS / UPD / DEL) causes more trips to the standby node If a shared network infrastructure is used, watch out for other traffic potentially causing a bottleneck in the link to the standby node Make sure the standby node has an adequate log disk infrastructure Quick write response time under load means faster response time back to the primary in SYNC mode, and a smaller DR exposure of unflushed records in ASYNC and NEARSYNC modes Rough rule-of-thumb: 5-15%, depending on a number of things Workload Distance between primary & standby Infrastructure Can be higher in extreme cases. #

32 Sample Lab measurements of HADR overhead Medium-heavy OLTP test workload 2600 tps, 80% read / 20% write Primary: 16-way Power6, AIX 6, DB2 v97 fp2, DS4700 SAN Secondary: 8-way Power6, AIX 6, DB2 v97 fp2, DS4700 SAN 1 Gb Ethernet interconnect #11 Mode SYNC mode NEARSYNC mode ASYNC mode TPS reduction ~9% ~7% ~6% 32 32

How much boost from LOB inlining? Non-buffered log I/O? Caching for IDENTITY and SEQUENCE?

33 A quick review of our FAQs - Power 7 impact? Where to use SSDs? Dedicated BP for temporary tablespaces? How much boost from CURRENTLY COMMITTED? How much boost from LOB inlining? Non-buffered log I/O? Caching for IDENTITY and SEQUENCE? Overhead due to log mirroring? VOLATILE tables and statistics? SORTHEAP and Load? Overhead of HADR? What are your FAQs? 33 33

34 Steve Rees IBM Canada Ltd. srees at ca.ibm.com Session D11 DB2 for LUW Performance: You ve got (frequently asked) questions, we ve got answers! 34

IBM DB2 LUW Performance Tuning and Monitoring for Single and Multiple Partition DBs

IBM DB2 LUW Performance Tuning and Monitoring for Single and Multiple Partition DBs Day(s): 5 Course Code: CL442G Overview Learn how to tune for optimum the IBM DB2 9 for Linux, UNIX, and Windows relational