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

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

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

Aanleiding Performance issues die van tijd tot tijd opduiken: Langlopende rapporten (o.a. 25.21.21) 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

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

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

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)

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

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’) http://www.bravepoint.com Tom Bascom http://www.greenfieldtech.com (ProTop)

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 11 64 bits) Disc 2 (Database only .dx & .bi)

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

De TEST Wat testen voor benchmark petest.p (CIM load van) Iclotr02 3.4.1 (Verplaatsen heen & terug) Ictriq01 3.21.2 Ictrup 3.21.23 Ppptrp06 3.6.15 Zupparrp 1.5.99.30  AEP versie van pparrp.p Zusoivrp09 7.17.99.7 (Sales Order Invoice Rpt) Grsync 25.21.21 (Einde maand financieel rapport) Meten doorlooptijd geheel en per onderdeel. 25.21.21 in meerdere sessies tegelijk ‘draaien’ Eigen test.p Random & Sequential Read/Write

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 1.000.000 = 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)

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 (18446744073709551616 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.

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

THE PROGRAMMING APPROACH By Peter Harink, 4Efficiency

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

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

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

Totalen per dag

De pieken

? De Top 10 Slik! Tabelnaam Som van read loc_mstr 411.229.364 mnd_det 395.521.498 ro_det 386.752.235 ld_det 274.388.628 ad_mstr 190.663.549 l_m_shc 183.545.406 l_m_qsd_det 127.442.849 op_hist 113.544.060 wo_mstr 59.181.435 tr_hist 50.132.450 ?

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)

XREF compile – scan Whole Index Regelnummer InfoRapid

EEN PIJNLIJK PRAKTIJKVOORBEELD

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

Maar daar vind je niet alles mee

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

MFG/PRO VOORBEELD Primary unique index: ld_loc_p_lot + ld_site + ld_loc + ld_part + ld_lot + ld_ref Ld_det heeft : 10.696 records Op site ‘1110’ staan 10.696 records Op locatie ‘exp01’ staan 172 records ------------------------------------------------------------------------------------------------------------------ EN DAN DE STANDAARD MFG/PRO QUERY OPBOUW: FOR EACH ld_det NO-LOCK => 10.696 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

Dat is schrikken… Hmmm…

UITLEG FOR EACH ld_det NO-LOCK => 172 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 .

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

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’

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

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

Dank voor Uw aandacht! 06 -537 068 49 055- 599 65 84 peter@4efficiency.nl gwscheppink@aep-industries.com 06 -537 068 49 055- 599 65 84

BIJLAGEN - Mnd_det voorbeeld - De Theorie achter indexen

Oh ja… De mnd_det! 5.880 records Slik! Tabelnaam Som van read loc_mstr 411.229.364 mnd_det 395.521.498 ro_det 386.752.235 ld_det 274.388.628 ad_mstr 190.663.549 l_m_shc 183.545.406 l_m_qsd_det 127.442.849 op_hist 113.544.060 wo_mstr 59.181.435 tr_hist 50.132.450 ?

Standaard oplevering QAD Tabelnaam Som van read loc_mstr 411.229.364 mnd_det 395.521.498 ro_det 386.752.235 ld_det 274.388.628 ad_mstr 190.663.549 l_m_shc 183.545.406 l_m_qsd_det 127.442.849 op_hist 113.544.060 wo_mstr 59.181.435 tr_hist 50.132.450

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

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

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

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

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