YOUR machine and MY database a performing relationship!? (#141)

Transcription

1 YOUR machine and MY database a performing relationship!? (#141) Martin Klier Senior / Lead DBA Klug GmbH integrierte Systeme Las Vegas, April 10th, 2014

2 Agenda Introduction NUMA + Huge Pages Disk IO Concurrency Engineers to work together

3 Speaker Martin Klier Lead DBA for Oracle at Klug-IS Focus on Performance, Tuning and High Availability Linux since 1997, Oracle since Weblog:

4 Klug GmbH integrierte Systeme ( Teunz, GERMANY Specialist leading in complex intralogistical solutions Planning and design of automated intralogistics systems, focus on software and system control / PLC >300 successful major projects in Europe, America, Asia

5 iwacs

6 DOAG - Deutsche Oracle Anwendergruppe (German Oracle User's Group) Biggest Oracle Technology Conference in Europe (2,000+ attendees) Save the date: Nuremberg, November 18th - 21st 2014

7 Server / CPU

8 NUMA Core(s) +SharedCache, LLC Non Unified Memory Access IMC QPI-C Core(s) +SharedCache, LLC QPI-C PCIe IMC IMC PCIe QPI-C Core(s) +SharedCache, LLC QPI-C IMC Core(s) +SharedCache, LLC

9 NUMA _enable_numa_support = TRUE MOS Doc ID Multiple Buffer Caches Striped pools => cross context :(( => pool access :(

10 NUMA 26 GB

11 NUMA One buffer cache for each node 13GB+13GB=26 GB

12 NUMA Partitioned access Can be up to 40% faster But...

13 NUMA Non-NUMA with NUMA With my workload and only one listener: Saved <1 page alloc miss per second?

14 NUMA So WHY? Fits into RAM of one node. OS NUMA optimization at work. 26 GB

15 NUMA Relevance-and-care chart System Admin DBA Developer

16 NUMA Suggestions NUMA Useful in big environments only (think: DB consolidation) Make friends with the system admin, have a joint opinion Test thoroughly and quantify use vs. effort (think: bugs)

17 Server / RAM

18 RAM New Process PMON Server etc. OS Kernel managed Access (permission check) Small OS Pages Shared Memory Segment Grant permission Integrate in serialization structures Per page

19 RAM Problems Memory Fragmentation Wasting CPU with page alloc OS_THREAD_STARTUP waits

20 Huge Pages New Process PMON Server OS Page FAST access Large / Huge OS Pages FAST startup Shared Memory Segment

21 Huge Pages ( )*2048kB=28GB Alert Log

22 Huge Pages Relevance-and-care chart System Admin DBA Developer

23 Huge Pages Suggestions Large/Huge Pages Useful with SGA >=16GB Use largest available & sane page size Talk your sysadmin into DOing IT Combine with PRE_PAGE_SGA=TRUE

24 Storage / SSD

25 SSD Words Cell Bits Block

26 SSD

27 SSD 16kB 512kB pro Block 1. erase

28 SSD 16kB 512kB pro Block 2. write

29 SSD 120:60 = *2 85:60 = *1.4 Types and Figures from But the terrors are still intact. :)

30 SSD 8k/16k blocks 80% write 20% read 8171 IOPS like 60 HDDs Samsung SSD 840 PRO

31 SSD Relevance-and-care chart System Admin DBA Developer

32 SSD Suggestions Know your IO load profile (AWR, nmon) Use enterprise-level devices w/ Single Level Cell (SLC) SSDs require different lifecycle handling in doubt, consider an array of HDDs of same IO power

33 Concurrency means collisions and serialization

34 Concurrency Occurrence Data Access (Row Lock, Block Header) Shared memory organization (Buffer / Library Cache etc.) CPU queueing Disk / Network IO...

35 Concurrency State A 5 Protected or limited resource State B X? Delayed?

36 Row Lock

37 Block/Buffer ITL entry Header Free Space Row Space =============== =============== =============== =============== =============== =============== =============== =============== Row

38 Row Lock ITL entry Lock and Access Session 1 Spin Session 2 Incompatible Lock Attempt Row =============== =============== =============== =============== =============== =============== =============== =============== enq: TX - row lock contention

39 Concurrency Spinning means Active checking of a value in memory Wasting CPU for non-productive work Oracle Spin Count limits and Wait Events are a generosity to limit, see and measure the impact

40 ITL Stress one does it Resizing Limited Space Concurrent Buffer modif. other one(s) =============== =============== =============== =============== =============== =============== =============== =============== spin! buffer busy wait enq: TX - allocate ITL entry

41 Mutex Mutex Contention Sleep = Wait cursor: mutex S cursor: mutex X... S2 spinning on M. Session 2 Library Cache M Object S1 holding Mutex Session 1 Same for Latches, but a bit uglier.

42 CBC Cache Buffer Chains: Is this block in the BC? Chains Latches CBC 4F BH 1 BH 77 CBC 51 BH 99 BH 32 Buffer Headers (references in Shared Pool)

43 CBC Locks the chain and looks for a buffer Session 1 Spin Session 2 CBC 4F BH 1 BH 77 CBC 51 BH 99 BH 32 Same or diff. Buffer (Chain), same latch :( latch: cache buffer chain

44 Conc. Wait Relevance-and-care chart System Admin DBA Developer

45 Concurrency Suggestions Check workload (think: SQL efficiency) => Reduce logical reads/writes Be ready for decent diagnosis (think in Wait Events)

46 Collaborate It's all about humans working together

47 Layers Application Network Database Operating System Server SAN Storage

48 People Engineers to work together

49 All is slow Relevance-and-care chart System Admin DBA Developer

50 It works Relevance-and-care chart System Admin DBA Developer

51 TEAM Make sure you have enough parallel beer!

52 Thank you very much for your attention! Martin Klier Senior / Lead DBA Klug GmbH integrierte Systeme Las Vegas, April 26th, 2012

53 Read on... More resources on this topic Kevin Closson, on NUMA and Huge Pages Craig Shallahamer, on Cache Buffer Chain visualization Arup Nanda, on ITL / Locks Andrey Nikolaev on Mutexes Exploring mutexes, the Oracle RDBMS retrial spinlocks Ronan Bourlier & Loïc Fura, IBM Oracle DB and AIX Best Practices for Performance & Tuning My Oracle Support Doc ID Enable Oracle NUMA support with Oracle Server Version 11gR2 Doc ID USE_LARGE_PAGES To Enable HugePages Doc ID HugePages on Oracle Linux 64-bit

54 Thank you Many people have helped with suggestions, critics or taking daily work off me during preparation and travel phase. Guys, you are top! Special thanks to: My boss and company, for endorsement My team, for digging out the interesting stuff