1 / 108

Standard template for internal and external presentations Journal on i/OS

Standard template for internal and external presentations Journal on i/OS. 2009.10.15 김 교 석 MTS, IBM Korea. Journal 개요. Journal Basic. Journal Objects DB Objects: Physical Files, Access Paths Data Areas, Data Queues IFS Objects Journal 마치 깔때기와 같은 역할

colby-church
Télécharger la présentation

Standard template for internal and external presentations Journal on i/OS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Standard template for internal and external presentationsJournal on i/OS 2009.10.15 김 교 석 MTS, IBM Korea

  2. Journal 개요

  3. Journal Basic • Journal Objects • DB Objects: Physical Files, Access Paths • Data Areas, Data Queues • IFS Objects • Journal • 마치 깔때기와 같은 역할 • 각각의 object들과 journal entry들의 연결고리 • 그 크기가 증가하지는 않는다, • Journal Receiver • Journal entry들을 저장하는 곳 • Audit관련 내용을 제공 • 크기가 증가함에 따라 관리 필요

  4. SMAPP • SMAPP (System Managed Access Path Protection) • System이 자동으로 지정된 Access Path Rebuild Time에 따라 커다란 AP들을 Journaling하는 기능 • System의 Outage시 새로 Rebuild하는 대신 Journal을 이용해 Access Path들을 복구 • Runtime vs. IPL (IASP vary-on) • EDTRCYAP 명령어를 이용해 원하는 AP 복구시간을 지정할 수 있다. • SMAPP 고려사항 • Rebuild Time을 너무 크게 지정하지 말 것 • 만약 PF가 Journal되고 있다면, AP entry는 User Journal에 저장된다. • User Journal에 쌓이는 SMAPP entry에 의해 사용되는 량을 줄이기 위해서 RCVSIZOPT(*RMVINTENT)를 사용한다 • Minimize Aps that are ineligible for SMAPP

  5. EDTRCYAP

  6. Remote Journal • Source에서 Target으로 Journal entry를 빠르고 효과적으로 보낸다. • O/S의 SLIC Layer에서 수행되는 기능 • Remote Journal이 적용되면, Receiver에 있던 모든 Entry들이 가장 효율적인 “Catch-up” Mode로 보내진다. • 일단 Catch-up되어진 후, Synchronous또는 Asynchronous 전달Mode를 이용해 전송된다.

  7. Remote Journal • Asynchronous Mode • Source쪽의 Disk에 entry를 저장한 후 Target에 보낸다. • Sending task는 충분하지 않은 Communication Bandwidth등의 이유로 실패할 수도 있는데, 이럴 경우는 좀더 효율적인 Mode로 자동으로 보내게 된다. • 만약 Source쪽이 Crash되었을 경우, 각 Entry가 제대로 Target에 적용되었는지 확실하지 않다. • Target System에 Entry들을 보내는 작업이 지연된다 하여도 Source System의 성능에는 영향이 없다. • Synchronous Mode • Source System에서 Entry를 Disk에 쓰기 전에, Target에 Entry를 보내고 Response를 받는다. • 따라서, Source가 Crash되더라도 Entry들이 Target에 적용되었음을 Guarantee할 수 있다. • Target never falls behind • Source system performance can be impacted if insufficient communication bandwidth

  8. Remote Journal • Remote Journal사용시 고려사항 • 두 시스템간의 Communication bandwidth가 충분해야 한다. • To test the throughput between systems, activate remote journal with an existing journal receiver which will run in “catch-up” mode and give an upper bound on the rate of transfer between systems • Internal SMAPP Entries의 전송을 막기 위해 RCVSIZOPT(*RMVINTENT)로 Setting • Network문제로 인해 remote journal이 중단되거나 비효율적으로 작동할 수 있으므로 NETSTAT command를 사용하여 Retransmissions이 얼마나 일어나나 확인한다.

  9. Journal Attribute • 모든 journals에 대해 아래 값들을 설정하도록 한다. • RCVSIZOPT(*RMVINTENT) • User journal에서 internal SMAPP entries에 의해 사용되는 공간을 최소화 • Remote Journal을 사용할 경우 Internal SMAPP Entries를 보내는 overhead를 줄일 수 있다. • RCVSIZOPT(*MAXOPT2) • 좀 더 큰 maximum sequence number • 좀 더 큰 maximum receiver size • 좀더 많은 Disk Arm들에 Receiver의 Data들을 분산시킬 수 있다. • Internal entries의 재 사용을 위한 추가 space를 제공한다. • 성능 개선효과 및 다른 function들의 maximums을 증가시킬 수 있다.

  10. Journal 성능 관련 10가지 질문

  11. 과연 Journal을 제대로 알고 사용하고 있는가 ! Block들을 쌓는 것과 같다... Larry

  12. 그리고 함께 사용할 2개의 Tool들... C Programs SQL Queries 사용할 3개의 Block들은... 때론 이것들을 함께 묶어서... Collection Services Pex Traces DSPJRN i5/OS has a richer journal

  13. Journal Optimization에 사용될 Block들 • DSPJRN to an OUTFILE • DSPJRN JRN(LIB/JRN) OUTPUT(*OUTFILE) OUTFILFMT(*TYPE5) • OUTFILE(LIB/OUTFILE) • Run Collection Services • Performance Tools(5722-PT1)이 설치되어 있다면 Collection Services 시작 • GO PERFORM • Select Option 1 to start collection services. • API CALL • CALL QYPSSTRC PARM('*PFRxxxxxx' '*STANDARDP' X'00000000') (xxxxxx는 Space 6자리) • Run Performance Explorer 1) Use the ADDPEXDFN command to add a PEX definition which will collect Journal Events 2) Start PEX using the STRPEX command and specify the PEX definition you created 3) Run workload to be analyzed 4) End PEX with the ENDPEX command and specify to output the data a user library 5) Run the PARSEJOPEX program to parse the Journal Trace Point information

  14. 이 Session에서 소개드릴 Tool및 Program source는 아래 URL에서 download가능합니다.: http://www-03.ibm.com/systems/i/software/db2/journalperfutilities.html

  15. 아래와 같은 10가지 질문에 어떻게 답할 것인가? Topic Classic Question How do I get Journal to use all my disk arms ? Disk Arms Do I have enough to make Journal happy ? IOA Write Cache Are my settings and applications Journal-friendly ? Bundling How can I tame the Commit tiger ? Commit Too may files serviced by a single journal ? Bullies Have I got journal entries I don’t need ? Discarding Chaff How can I send less data to disk and target machine ? Skinny Jrn Entries Am I failing to exercise good Jrn Housekeeping ? Full Closes Are my Jrn background tasks gasping for breath ? Jrn Recovery Ratio Are my Remote Jrn ASYNC sending tasks falling behind? Remote Journal

  16. Q1. Disk Arms – Journal이 Disk Arm들을 적절히 사용하고 있는가? 일반적으로 Jrn Rcvr들은 여러 Disk Arms에 골고루 퍼져서 분포하지만, 과연 몇 개나 사용하고 있는가? Journal Receiver User ASP Journal Receiver arms

  17. Round-robin use of disk arms . . 12 . 2 1 Arm Number

  18. 사용중인 Disk Arm은... • 현재 journal receiver가 몇 개의 disk arm을 사용하고 있는가? • Requirements • Journal Receiver should contain a sufficient number of entries to analyze • Journal Receiver가 사용하는 disk arm 갯수를 알아 내는 방법 • 1) DSPJRNto an OUTFILE using *TYPE5 to obtain arm information • 2) Run the following SQL query to determine number of arms being used: • SELECT MAX(JOARM) from lib/outfile ? Output: Number of Arms used for the Receiver

  19. DSPJRN w/ *TYPE5 Display Data Data width . . . . . . : 862 Position to line . . . . . Shift to column . . . . . . ...40....+...41....+...42....+...43....+...44....+...45....+...46....+...47.... RCVARM THREAD ADDRESS REMOTE REMOTE ASP NUMBER ID FAMILY PORT ADDRESS HEX 1 2 0000000000000000 0 0 1 2 0000000000000000 0 0 1 2 0000000000000000 0 0 120000000000000000 0 0 1 3 0000000000000000 0 0 1 3 0000000000000000 0 0 1 3 0000000000000000 0 0 130000000000000000 0 0 1 3 0000000000000000 0 0 1 4 0000000000000000 0 0 1 4 0000000000000000 0 0 1 4 0000000000000000 0 0 1 4 0000000000000000 0 0 14 0000000000000000 0 0 More... F3=Exit F12=Cancel F19=Left F20=Right F21=Split { {

  20. Query output Display Data Data width . . . . . . : 13 Position to line . . . . . Shift to column . . . . . . ....+....1... MAX ( JOARM ) 11 ******** End of data ******** Bottom F3=Exit F12=Cancel F19=Left F20=Right F21=Split Quantity of arms

  21. 사용중인 Disk Arm은... • 왜 내가 생각한 만큼의 disk arm을 사용하지 않을까? • 아래 값들이 충분하지 않을 경우: • 1. Journal Threshold • 2. RcvSizOpt Setting을 MaxOpt1 로… (or higher) ?

  22. 충분한 Threshold를 가지고 있지 않다면 새 disk drive들은 사용하지 않고 남아있게 된다. 만약 Journal Threshold가 너무 작다면?? PF Journal Threshold IOP1 Write Cache System ASP User ASP Unused AP Jrn Rcvr arms PF

  23. Journal Receiver Thresholds • CRTJRNRCV ... THRESHOLD(1800000) { Means 1.8 Gig } • Note: Threshold 는 Kilobytes단위 • 높은 Threshold로 Setting하게 되면: • 좀 더 많은 disk arms을 사용하게 된다. 즉, Threshold의 매 64 Meg가 추가될 때마다 추가 disk arm을 사용하게 된다. • 그리고 좀 더 큰 bandwidth를 가지고 achieve 가능. Capacity = *MaxOpt1 Threshold

  24. Journal Receiver Threshold와 Disk Arm의 상관관계 Threshold # of Disk arms RcvSizOpt(*MaxOpt1) < 640 MB Up to 10 Min 704 MB 11 778 MB 12 ... . . . . . . 100 Max 6.4 Gig 100 Threshold의 64MB 증가마다 additional arm이 더 사용됨

  25. Example: • CRTJRNRCV JrnRcv(MyLib/Rcv2) Threshold(70000000) { 70 Gig } • CRTJRN Jrn(MyLib/Jrn2) JrnRcv(MyLib/Rcv2) RcvSizOpt(*MaxOpt1) { Rqsts 1 TB max } Journal Receiver thresholds Takes both Capacity = *MaxOpt1 Threshold BACK

  26. System의 IOA Write Cache를 가장 많이 사용하고, 최대 수혜자는 바로 Journal… Q2. IOA Write Cache – Journal에서 사용할 만큼 충분한가? PF Journal Memory IOA Write Cache System ASP UserASP AP Jrn Rcvr arms PF

  27. IOA Write Cache Slower Write Over Threshold Destage Fast Write Memory Demand (and wait) Threshold Write Cache Memory Background Destage DASD DASD Continuous Trickle

  28. Write Cache에 대해 너무 인색하지 말 것… Model Write Cache Journal (older) 2763 10 Meg 2782 40Meg Receiver (older) 2778 26 (104) Meg 2757 235 (757) Meg IOA Write Cache . . . Physical quantity Feels like Need enough Arms

  29. IOA write cache ? • IOA write cache는 충분한가? • Requirements • The performance tools (5722PT1) to start collection services • Fast disk write의 사용률을 알아내는 방법 • 1. Start collection services • 2. Collect data for at least 5 minutes (disk statistics are gathered at this interval). • 3. Dump the statistics to a database table using the following CL command: • CRTPFRDTA FROMMGTCOL(*ACTIVE) TOLIB(LIB) CGY(*DISK) • - This will create a file called QAPMDISK. • 4. Query the resulting file. • The interesting data is in columns DSCCFW (fast writes) and DSWRTS (total writes) • SELECT 100 * SUM(DSCCFW) / SUM(DSWRTS) FastWrtPrcnt • from QMPGDATA/qapmdisk • where dsasp = 2  replace with correct ASP # Output: % of Fast Writes

  30. Percentage of fast disk writes Display Data Data width . . . . . . : 42 Position to line . . . . . Shift to column . . . . . . ....+....1....+....2....+....3....+....4.. FASTWRTPRCNT 99 ******** End of data ******** Bottom F3=Exit F12=Cancel F19=Left F20=Right F21=Split 85 Rule of Thumb: Journal needs 99% fast writes BACK

  31. Q3. Journal Bundling – Application이나 Setting이 Journal-Friendly한가? PF 3 Batch Job #1 Batch Job #2 Batch Job #3 PF 2 PF 1 Main Memory Buffer 128K Buffer Bundle Journal Journal Receiver IOA User ASP Write Cache

  32. Journal Bundling • Bundles을 크게 하면: • Disk에 Write하기 위한 Activity를 좀 더 효율적으로 • 또한 Remote Journal을 좀 더 효율적으로 그렇다면, 현재 내 System의 Journal bundles은 얼마나 될까? 어떻게 해줘야 할 것인가? ?

  33. Bundling이 어떻게 되고 있는가? • Journal은 Round-Robin방식으로 entry들을 저장한다 • 아래의 output을 이용해 Journal의 평균 Bundle Width를 알 수 있다 • DSPJRN Format *TYPE5를 이용 • Journal Entry당 사용한 Disk Arm #을 알 수 있다. J Ent . . . Bundle #10 Bundle #2 Bundle #1 Arm #10 Arm #1 Round Robin

  34. Journal Bundling ? 그렇다면, 현재 내 System의 Journal bundles은 얼마나 될까? Requirements • Journal Receiver가 1개 이상의 disk arm으로 구성된 ASP에 존재해야 한다. • 아래 예와 같이 Journal Receivers의 내용을 DSPJRN TYPE5와 INCHIDENT(*YES) options을 사용하여 output을 생성한다. Example: DSPJRN JRN(mylib/myjrn) OUTPUT(*OUTFILE) INCHIDENT(*YES) OUTFILFMT( *TYPE5 ) OUTFILE(mylib/myoutfile)

  35. DSPJRN Display Data Data width . . . . . . : 862 Position to line . . . . . Shift to column . . . . . . ...40....+...41....+...42....+...43....+...44....+...45....+...46....+...47.... RCVARM THREAD ADDRESS REMOTE REMOTE ASP NUMBER ID FAMILY PORT ADDRESS HEX 1 2 0000000000000000 0 0 1 2 0000000000000000 0 0 1 2 0000000000000000 0 0 120000000000000000 0 0 1 3 0000000000000000 0 0 1 3 0000000000000000 0 0 1 3 0000000000000000 0 0 1 3 0000000000000000 0 0 1 3 0000000000000000 0 0 1 4 0000000000000000 0 0 1 4 0000000000000000 0 0 1 4 0000000000000000 0 0 1 4 0000000000000000 0 0 1 40000000000000000 0 0 More... F3=Exit F12=Cancel F19=Left F20=Right F21=Split Arm change

  36. Journal Bundling • Tool • 1) Display set of Journal Receivers to an OUTFILE using DSPJRN TYPE5 and INCHIDENT(*YES) options • 2) Run BUNDLE programon this outfile • (Source code http://www-03.ibm.com/systems/i/software/db2/journalperfutilities.html ) Get next Entry Update stats for current bundle YES YES NO Is Entry on same Arm as previous Entry? Update overall stats and reset current bundle stats Do More Entries Exist? • Output: • Average Bundle Size • Maximum Bundle Size • Minimum Bundle Size NO Output Results Rule of Thumb: 128k is optimal

  37. BUNDLE program output... number of entries = 530730 Total size of all entries = 354982052 Number of bundles = 2298 Average bundle size = 124474bytes max bundle size = 317170 bytes min bundle size = 609 bytes The optimal bundle size is 128 KB or wider F3=Exit F4=End of File F6=Print F9=Retrieve F17=Top F18=Bottom F19=Left F20=Right F21=User Window

  38. 그럼, 이제 Bundling Width를 어떻게 늘릴 것인가? If you’re willing to make application changes... • Application입장에서는 간단하게 Database Override 통해 가능하다… Working storage of application How can I get bigger bundles ? Jrn Ent Overrides를 사용하면 이 부분이 달라집니다. My ODP

  39. Journal Bundling - Methodology • Tool • 1) Display set of Journal Receivers to an OUTFILE • 2) Run SEQONLY program on this outfile • (Source code http://www-03.ibm.com/systems/i/software/db2/journalperfutilities.html ) Get next pair Good candidate: SEQONLY Output file/job pair identity YES YES Determine # of Updates and Deletes for file/job pair Obtain list of distinct file/job pairs Do more pairs Exist? Does file/job pair have only Inserts? Determine # of Inserts for file/job pair NO NO • Output: • Files which should be considered for SEQONLY(*YES) End

  40. Select * from lib/output Display Data Data width . . . . . . : 62 Position to line . . . . . Shift to column . . . . . . ....+....1....+....2....+....3....+....4....+....5....+....6.. OBJ LIB MBR JOB NUMPTS PROD_TRANS CKRJTEST PROD_TRANS CKRJTEST 136,040 STOR_TRANS CKRJTEST STOR_TRANS CKRJTEST 100,014 ******** End of data ******** Bottom F3=Exit F12=Cancel F19=Left F20=Right F21=Split Good candidates Number of puts

  41. Journal Bundling - Application • ODP Buffer를 효과적으로 사용 • OVRDBF …. SEQONLY(*YES) • 다른 방법은 또 없을까? • Program에 각각의 File당 하나의 View만을 사용해야 한다는 생각은 버리자… • 때론 하나보단 두 개가 나을 때도…

  42. Use a job with two "views" Regular ODP UP PF PT ODP 1 PT PT Pure Inserts ODP 2 ODP 2는 EXTRA "view“를 사용한 경우. 이 instance는 File Open시 SEQONLY(*YES)를 이용하였다. Journal Active IOP 128K Buffer Write Cache System ASP User ASP Jrn Rcvr arms AP PF

  43. Journal Bundling – Journal Cache • Application 수정 이외에 좀 더 편하게 Bundle Width를 늘릴 방법은 없을까?

  44. Journal Caching CHGJRN ... JrnCache(*Yes) PF ODP Buffer Batch Application Cache-enabled Journal Receiver Main memory cache IOA 128K Buffer 128K Buffer Write Cache One per disk arm System ASP User ASP AP PF

  45. Journal Cache의 성능 이점 • Batch Job의 경우 • 5 Million DB operations (10% Adds, 90% Updates) • 9 Million resulting Journal entries (captured both before and after images) Elapsed Time Original Batch run, no Journaling 1118 Sec Ordinary Journaling enabled 9773 Sec 약 6배 향상 Using the new Journal cache option 1433 Sec

  46. Journal Cache의 성능 이점 • Remote Journal을 사용할 경우 • Target System이 Keep-Up Mode일 경우 Keep up rate on Target machine w/o Caching 600,000 transactions/Hr With Caching on target 2,400,000 transactions/Hr Source System Target System Cache . Journal

  47. Journal Caching Option • A priced feature of the Operating System • Option 42 • CHGJRN JRN(MYLIB/MYJRN) JRNCACHE(*YES) • Journal Cache Option이 도움이 될지 안될지 판단하기 위해서는 아래와 같은 방법을 사용하여 알아본다. Tool 1) Display set of Journal Receivers to an OUTFILE 2) Run the following query against the OUTFILE select count(*) as NumEntEligible, sum(JOENTL) as TotalBytes from lib/file where JOCCID = 0 and ((JOENTT = 'PT' OR JOENTT = 'PX' OR JOENTT = 'DL' OR JOENTT = 'UP') and JOCODE = 'R') • Output: • Number of entries eligible to be Cached • Number of bytes eligible to be Cached

  48. Looking for bundle-eligible journal entries Display Data Data width . . . . . . : 58 Position to line . . . . . Shift to column . . . . . . ....+....1....+....2....+....3....+....4....+....5....+... NumEntEligibleTotalBytes 38,197 6,910,903 Bottom F3=Exit F12=Cancel F19=Left F20=Right F21=Split Quantity of Journal entries Number of bytes

  49. 만약 Commit User라면… 일단은 V5R4으로... • Tool • 1) Display set of Journal Receivers to an OUTFILE • 2) Run the following query on the OUTFILE • select count(*) as NumEntEligible, • sum(JOENTL) as TotalBytes • from lib/file • where JOCCID = 0 • and ((JOENTT = 'PT' OR JOENTT = 'PX' OR JOENTT = 'DL' OR JOENTT = 'UP') and JOCODE = 'R') V5R4에서 “soft” commit을 사용할 수 있습니다. Drop this line • Output: • Number of entries eligible to be Cached • Number of bytes eligible to be Cached

  50. Journal Bundling – 결론 (start) Yes Good Performance! Are my Journal Bundles wide?(use Bundle tool) No Yes Can I use SEQONLY(*YES)?(useSEQONLY program) Bigger bundles are better Use SEQONLY(*YES) if possible No Yes Will Journal Caching likely help?(use query) Turn on Journal Caching BACK

More Related