AEP Industries Nederland BV & 4Efficiency

Presentatie over: "AEP Industries Nederland BV & 4Efficiency"— Transcript van de presentatie:

1 AEP Industries Nederland BV & 4Efficiency
Progress Performance AEP Industries Nederland BV & 4Efficiency

2 Inhoud Wie (korte introductie) Wat Waarom
Onderzoek welke factoren de performance bepalen voor Progress DBMS en 4GL in MFG/Pro omgeving Waarom Aankomende vervanging DB server Veel ‘verhalen’ maar weinig onderbouwing

3 Introductie Peter Harink Gert-Wim Scheppink
Zelfstandig consultant/analyst en Oud-collega’s Ca. 15 jaar Unix en Windows ervaring Gert-Wim Scheppink ICT Manager AEP AEP gebruikt eB2 SP12 en Progress 10.1B Ca. 18 jaar voornamelijk Windows Progress DBA sinds versie 8

4 Aanleiding Performance issues die van tijd tot tijd opduiken:
Langlopende rapporten (o.a ) Veel gebruikers die dit ervaren in traag systeem Output van een batch laat te lang op zich wachten Wisselen van menu soms onverklaarbaar traag Backups duren steeds langer

5 Aanleiding (2) Vervanging DB server hardware
Welke configuratie is goed/zinvol? Wat zijn de parameters in de keuze: Processor (AMD of Intel) Memory (Hoeveelheid) Storage (DAS of SAN) OS Windows / Linux (AEP is Wintel based) 32 of 64 bits > 2GB  64 bits OS

6 Verbeteren Deel van de workload verplaatsen (Report DB) Optimaliseren
Replication (Phatom) 2e DB server en licenties (en kosten) Extra proces & complexiteit MFG/Pro kan standaard niet in –RO DB werken Optimaliseren Consolideren & archiveren Dump & Load (via meest gebruikte index) € zo goed mogelijk besteden

7 Aanpak 3 In- en aanvalshoeken: Hardware Configuratie (Progress DBMS)
- Dell  Server voor evaluatie beschikbaar Configuratie (Progress DBMS) - John Brink voor consultancy (Progress NL) Programmeren - AEP & 4Efficiency (Peter Harink)

8 Meten is (z)weten Meten is (z)weten
Continue meting van Read,Create,Update en Deletes in de huidige productie omgeving AEP Opvallend: Record Reads is het enige wat ‘echt’ telt. Rest is < .5% (YMMV) Veel meer reads dan we verwacht hadden. > 1 miljard/dag Gebruik Promon (R&D, 2, 1, R) of lees de VST’s _UserIO _CheckPoint _Startup _ActSummary _ActIOTyp

9 Meten is (z)weten (2) Windows Performance Monitor (perfmon)
Gemeten aan: CPU RAM DISK I/O en Queue length Meer Informatie: Progress Performance & Tuning (Guide & Training) Performance Tuning Guidelines for Windows Server 2008 R2 Gebruik boeken en presentaties van Dan Foreman (Bravepoint) (Google ‘Dan Foreman’) Tom Bascom (ProTop)

10 Hardware Dell PowerEdge R710 (Try, Buy & Loan)
2 x quad core Intel Xeon X5550 Processor (2.66GHz, 8M Cache, 6.40 GT/s QPI, Turbo, HT) 32 GB RAM (1033 MHz) Storage (gebruikt testen tot nog toe) PERC 6/i RAID Controller Card 256MB 2 x Intel SSD 46 GB Disc 1 23 GB (Windows 2008 R2 64 bits) 24 GB (Linux Fedora bits) Disc 2 (Database only .dx & .bi)

11 Hardware (2) Storage (nog te testen)
SAN Equallogic PE5000-E (16 discs 4,5 TB Bruto, iSCSI) Voordelen Betrouwbaar (alles redundant & fail over/replicatie) Snapshots (i.c.m. proquiet binnen 1 sec. backup) Zeer eenvoudig in gebruik en beheer Nadelen Belasting moeilijker te controleren omdat er veel andere systemen op zijn aangesloten (VMWare) Single Point of Storage Als er wat mis gaat…… Firmware upgrade  ca. 20 servers down

12 De TEST Wat testen voor benchmark petest.p (CIM load van)
Iclotr (Verplaatsen heen & terug) Ictriq Ictrup Ppptrp Zupparrp  AEP versie van pparrp.p Zusoivrp (Sales Order Invoice Rpt) Grsync (Einde maand financieel rapport) Meten doorlooptijd geheel en per onderdeel. in meerdere sessies tegelijk ‘draaien’ Eigen test.p Random & Sequential Read/Write

13 Resultaten (voorlopig)
Opvallend CPU is meestal de bottle-neck Waarschijnlijk doordat SSD zo snel is en/of veel RAM Vrijwel iedere taak draait op 1 core 100% tot finished Het gaat dus niet meer om de spindles en storage (toch?) Windows/Linux en Progress benutten multi-core verre van optimaal. (VMWare ook)  SSD is snel (bloedsnel  5700 DB Reads in Promon) Read gltr_hist uit buffer (-B = 8GB ) in 74 sec. Read gltr_hist (20^6 records) from disc in 79 sec! (+7%) Minder RAM bij gebruik SSD is heel goed mogelijk Windows vs Linux! (1,08 vs 0,87 mlj Records Read/sec)

14 Conclusies Hardware OS SSD is een succesnummer m.b.t. performance
Veel RAM is ook heel betaalbaar OS 64 bits is een must indien je veel RAM wil gebruiken 32 bits  2GB max 64 bits -> 16 TB max ( bytes theoretisch) Redelijk alternatief is 32 bits en SSD (niet getest) Windows of Linux? Hangt vooral van omgeving en beschikbare kennis af Performance stabiliteit en security zijn slechte argumenten voor OS keuze.

15 Conclusies (2) Progress (in MFG/Pro omgeving)
Reads:Writes is ca. 100:1  Optimaliseer Reads (en voorkom locking issues!) 64 bits begint volwassen te worden R-code uitwisselbaar Windows Linux (64 bits) Client is meestal Windows, Shared Mem vaak Linux Linux/Unix  Beschikbaar op diverse platformen Geen GUI code voor client server (op Windows compileren) Windows 64 bits alleen char. GUI nog niet beschikbaar! Optimaliseer je code, daar zit nog veel winst!!! Dit geldt voor eigen code maar ook zeker nog voor QAD

16 THE PROGRAMMING APPROACH By Peter Harink, 4Efficiency

17 Inleiding De techniek en de configuratie zijn heel belangrijk MAAR…
De programmatuur moet zeker niet vergeten worden

18 WAT HEBBEN WE GEDAAN? VST (Virtual System Tables) monitoren
Bij welke tabellen zitten grootste problemen (PS denk aan database-server opstart parameter ‘tablerangesize 1200’) Programmatuur scannen Whole-index Gestarte programma’s op specifieke tijdstippen Grootste knelpunten oplossen

19 Elke 10 minuten totalen per tabel opslaan
Date Nr Time Table Read Create Update Delete 18/09/2009 1646 00:06:32 lpm_mstr 3918 lpmd_det 5 usg_det 33 28 hwm_det 9 1 lua_det kbtrd_det 2 slc_ctrl 264 slcd_ctrl 926 slpt_det 130 slld_det 341 10 20 sltr_hist 394 22 slsod_det slidh_hist 1647 00:16:33 vue_mstr 3 vuf_det brw_mstr brwt_det brwf_det utd_det 32 mnds_det 510 uip_mstr 6 pgmi_mstr sesc_det sess_mstr usro_mstr aps_mstr lbl_mstr 138 lbld_det 2477

20 Totalen per dag

21 De pieken

22 ? De Top 10 Slik! Tabelnaam Som van read loc_mstr 411.229.364 mnd_det
ro_det ld_det ad_mstr l_m_shc l_m_qsd_det op_hist wo_mstr tr_hist ?

23 HOE OORZAKEN ZOEKEN? Probleem Top 10: - We moeten alle programma’s die tabel gebruiken analyseren… Hulpmiddel: - Pieken: Reduceren aantal programma’s - XREF Compile: Zoeken naar Whole-Index (Queries zonder index)

24 XREF compile – scan Whole Index
Regelnummer InfoRapid

25 EEN PIJNLIJK PRAKTIJKVOORBEELD

26 FOR EACH CPH_HIST FIRST AD_MSTR ZONDER INDEX GEVOLG: VOOR ELK GEVONDEN RECORD IN CPH_HIST –> LEZEN WE DE HELE(!) AD_MSTR

27

28 Maar daar vind je niet alles mee

29 SIMPEL VOORBEELD Primary unique index: ld_loc_p_lot + ld_site + ld_loc + ld_part + ld_lot + ld_ref Ld_det heeft : records Op site ‘1110’ staan records Op locatie ‘exp01’ staan 172 records FOR EACH ld_det NO-LOCK WHERE ld_site = '1110': => reads END. FOR EACH ld_det NO-LOCK WHERE ld_site = '1110‘ AND ld_loc = ‘exp01’: => 172 reads ? ?

30 MFG/PRO VOORBEELD Primary unique index: ld_loc_p_lot + ld_site + ld_loc + ld_part + ld_lot + ld_ref Ld_det heeft : records Op site ‘1110’ staan records Op locatie ‘exp01’ staan 172 records EN DAN DE STANDAARD MFG/PRO QUERY OPBOUW: FOR EACH ld_det NO-LOCK => reads WHERE (ld_loc >= 'exp01' AND ld_loc <= 'exp01‘) : END. FOR EACH ld_det NO-LOCK => 172 reads WHERE (ld_site >= '1110' AND ld_site <= '1110') AND (ld_loc >= 'exp01' AND ld_loc <= 'exp01‘) : ? ? 10.696

31 Dat is schrikken… Hmmm…

32 UITLEG FOR EACH ld_det NO-LOCK => reads WHERE (ld_site >= '1110' AND ld_site <= '1110') AND (ld_loc >= 'exp01' AND ld_loc <= 'exp01‘) : END. For a range match to be active it must stand alone or be connected to other selection criteria by ANDs. In addition, it must apply to an index component having : - The component is the first or only one in the index - All preceding components in the index key have active equality matches 10.696 .

33 VOORBEELD Uitleg wordt nu een stuk lastiger…
FOR EACH ld_det NO-LOCK => 222 reads WHERE (ld_part >= 'F ' AND ld_part <= 'F ') : END. FOR EACH ld_det NO-LOCK WHERE ld_site = '1110' AND => reads (ld_part >= 'F ' AND ld_part <= 'F ‘) : Uitleg wordt nu een stuk lastiger…

34 Veel gemaakte fouten Geen index-fields
WHERE ad_name BEGINS ‘Jansen’ Geen slimme queries waardoor toch ondanks gebruik key-fields in WHERE TOCH Whole index (Full Table Scan) wordt toegepast WHERE Can-do(``A,B,C``, pt_part) WHERE pt_part Matches ``A*`` WHERE(IF lLogical# THEN pt_part = ‘A’ ELSE pt_part = ‘B’) WHERE Substring(pt_part,1, 3) = ``ABC`` ….etc…etc… Eerste component in een multi-field index MIST INDEX = ld_site, ld_loc, …. WHERE ld_loc = ``X`` Primaire index-field geen ‘equality match’ WHERE ld_site >= ‘A’ AND ld_site <= ‘A’ AND ld_loc >= ‘X’ AND ld_loc <= ‘Y’

35 Conclusie Oorzaak: Onwetenheid / Fouten / Slordigheden / Veel range selecties => Daardoor veel ongeindexeerde zoekacties Veel voorkomend: - Site of Domain mist in opvraag OF zijn range-selecties (>= en <=) - ’Onhandig’ geconstrueerde queries Erg belangrijk => regelmatig programmatuur scannen => Of nog beter: elke wijziging voor in productie nemen -> # reads scannen -> XREF compile uitvoeren Want: Server druk voor niets En nog erger, gevolg is meer disk-reads, want memory-buffers worden leeg getrokken, inefficiente LRU (Least Recently Used) - Chain

36 Documentatie 9.1E Database Design Guide 10.0B Database Design Manual
Achterin deze presentatie

37 Dank voor Uw aandacht! 06 -537 068 49 055- 599 65 84

38 BIJLAGEN - Mnd_det voorbeeld - De Theorie achter indexen

39 Oh ja… De mnd_det! 5.880 records
Slik! Tabelnaam Som van read loc_mstr mnd_det ro_det ld_det ad_mstr l_m_shc l_m_qsd_det op_hist wo_mstr tr_hist ?

40 Standaard oplevering QAD
Tabelnaam Som van read loc_mstr mnd_det ro_det ld_det ad_mstr l_m_shc l_m_qsd_det op_hist wo_mstr tr_hist

41

42 De Theorie 1) WHERE searchExpr [ BY field ]
2) WHERE searchExpr AND searchExpr [ BY field ] 3) WHERE searchExpr OR searchExpr [ BY field ]

43 1) WHERE searchExpr [ BY field ]
If there is an index on the field in searchExpr, or If field is the first component in a multi-field index =>Progress uses the index. Otherwise, Progress uses the primary index Dus bijv: Table: ld_det – INDEX ld_site, ld_loc, … Query: WHERE ld_lot = “…” => gebruikt NIET deze index

44 2) WHERE searchExpr AND searchExpr[ BY field ]
Progress builds a logic tree and evaluates index usage on either side of the AND. When used with the FOR EACH statement, if both sides of the AND include equality matches on all components of non-unique indexes, both indexes are used When used with the FIND statement, if both sides of the AND are equality matches on indexed fields, only a single index is used. Note that a word index expression with a simple string is an equality match; a wildcard string constitutes a range match

45 3) WHERE searchExpr OR searchExpr[ BY field ]
Progress builds a logic tree and evaluates index usage on either side of the AND. When used with the FOR EACH statement, if both sides of the AND include equality matches on all components of non-unique indexes, both indexes are used When used with the FIND statement, if both sides of the AND are equality matches on indexed fields, only a single index is used. Note that a word index expression with a simple string is an equality match; a wildcard string constitutes a range match

46 General Rules for Choosing a Single Index
When the selection criteria do not support multiple index usage Progress uses these general rules (in this order) to select the most efficient index: 1. If there is a CONTAINS clause (which is legal only for word indexed fields), use the word index 2. If an index is unique, and all of its components are used in active equality matches, use the unique index. 3. Use the index with the most active equality matches. Equality matches are active if: • They apply to successive, leading index components - AND - They are joined by ANDs (not ORs or NOTs!) This disqualifies equality matches on, for example, components 2 and 3 of an index with three components, and it disqualifies matches on components 1 and 2, if they surround an OR 4. Use the index with the most active range matches. For a range match to be active it must stand alone or be connected to other selection criteria by ANDs. In addition, it must apply to an index component having any one of four properties: • The component is the first or only one in the index • All preceding components in the index key have active equality matches 5. Use the index with the most sort matches. (All sort matches are active.) 6. Use the index that comes first alphabetically. That is, if there is a tie—if multiple indexes have the same number of active equality, range, and/or sort matches—use the alphabet to decide 7. Use the primary index