progress performance aep industries nederland bv & 4efficiency
TRANSCRIPT
Progress PerformanceAEP Industries Nederland BV
&4Efficiency
Inhoud
• Wie (korte introductie)• Wat
• 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• 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)• 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:
1 Hardware- Dell Server voor evaluatie beschikbaar
2 Configuratie (Progress DBMS)- John Brink voor consultancy (Progress NL)
3 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• 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 APPROACHBy 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 0 0 0
18/09/2009 1646 00:06:32 lpmd_det 5 0 0 0
18/09/2009 1646 00:06:32 usg_det 33 0 28 0
18/09/2009 1646 00:06:32 hwm_det 9 1 1 0
18/09/2009 1646 00:06:32 lua_det 5 0 0 0
18/09/2009 1646 00:06:32 kbtrd_det 2 0 0 0
18/09/2009 1646 00:06:32 slc_ctrl 264 0 0 0
18/09/2009 1646 00:06:32 slcd_ctrl 926 0 0 0
18/09/2009 1646 00:06:32 slpt_det 130 0 0 0
18/09/2009 1646 00:06:32 slld_det 341 10 20 5
18/09/2009 1646 00:06:32 sltr_hist 394 22 1 0
18/09/2009 1646 00:06:32 slsod_det 5 0 0 0
18/09/2009 1646 00:06:32 slidh_hist 5 0 0 0
18/09/2009 1647 00:16:33 vue_mstr 3 0 0 0
18/09/2009 1647 00:16:33 vuf_det 3 0 0 0
18/09/2009 1647 00:16:33 brw_mstr 5 0 0 0
18/09/2009 1647 00:16:33 brwt_det 5 0 0 0
18/09/2009 1647 00:16:33 brwf_det 9 0 0 0
18/09/2009 1647 00:16:33 utd_det 32 0 0 0
18/09/2009 1647 00:16:33 mnds_det 510 0 0 0
18/09/2009 1647 00:16:33 uip_mstr 6 0 0 0
18/09/2009 1647 00:16:33 pgmi_mstr 1 0 0 0
18/09/2009 1647 00:16:33 sesc_det 3 0 0 0
18/09/2009 1647 00:16:33 sess_mstr 3 0 0 0
18/09/2009 1647 00:16:33 usro_mstr 3 0 0 0
18/09/2009 1647 00:16:33 aps_mstr 3 0 0 0
18/09/2009 1647 00:16:33 lbl_mstr 138 0 0 0
18/09/2009 1647 00:16:33 lbld_det 2477 0 0 0
Totalen per dag
De pieken
De Top 10
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
?
Slik!
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
Maar daar vind je niet alles mee
SIMPEL VOORBEELDPrimary 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 recordsOp locatie ‘exp01’ staan 172 records
-----------------------------------------------------------------------------------------------------------------------------------------------------
FOR EACH ld_det NO-LOCK WHERE ld_site = '1110': => 10.696 readsEND.
-----------------------------------------------------------------------------------------------------------------------------------------------------
FOR EACH ld_det NO-LOCK WHERE ld_site = '1110‘ AND ld_loc = ‘exp01’: => 172 readsEND.
?
?
MFG/PRO VOORBEELDPrimary 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 recordsOp 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‘) :END. 10.696
?
?
Dat is schrikken…
Hmmm…
UITLEGFOR 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 .
VOORBEELDFOR 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‘) :END.
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’• INDEX = ld_site, ld_loc, ….• 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!
[email protected] [email protected] -537 068 49 055- 599 65 84
BIJLAGEN
- Mnd_det voorbeeld- De Theorie achter indexen
Oh ja… De mnd_det!5.880 records
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
?
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
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
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 index2. 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 OR4. 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 decide7. Use the primary index
General Rules for Choosing a Single Index