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!

peter@4efficiency.nl gwscheppink@aep-industries.com06 -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