1 / 46

Progress Performance

Progress Performance. AEP 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.

lauren
Download Presentation

Progress Performance

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. Progress Performance AEP Industries Nederland BV & 4Efficiency

  2. Inhoud • Wie (korteintroductie) • Wat • Onderzoekwelkefactoren de performance bepalenvoor Progress DBMS en 4GL in MFG/Pro omgeving • Waarom • Aankomendevervanging DB server • Veel ‘verhalen’ maar weinigonderbouwing

  3. 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 jaarvoornamelijk Windows • Progress DBA sindsversie 8

  4. Aanleiding • Performance issues die van tijdtottijdopduiken: • Langlopenderapporten (o.a. 25.21.21) • Veelgebruikers die dit ervaren in traagsysteem • Output van een batch laat te lang op zichwachten • Wisselen van menu somsonverklaarbaartraag • Backups durensteeds langer

  5. Aanleiding (2) • Vervanging DB server hardware • Welkeconfiguratieisgoed/zinvol? • Watzijn de parameters in de keuze: • Processor (AMD of Intel) • Memory (Hoeveelheid) • Storage (DAS of SAN) • OS • Windows / Linux (AEP isWintelbased) • 32 of 64 bits > 2GB  64 bits OS

  6. Verbeteren • Deel van de workloadverplaatsen (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 meestgebruikte index) • € zogoedmogelijkbesteden

  7. Aanpak • 3 In- en aanvalshoeken: • Hardware - Dell  Server voorevaluatiebeschikbaar • Configuratie (Progress DBMS) - John Brink voorconsultancy (Progress NL) • Programmeren - AEP & 4Efficiency (Peter Harink)

  8. Metenis (z)weten • Metenis (z)weten • Continue meting van Read,Create,Update en Deletes in de huidigeproductieomgeving AEP • Opvallend: • Record Readsishetenigewat ‘echt’ telt. Restis < .5% (YMMV) • Veelmeerreads dan weverwachthadden. > 1 miljard/dag • GebruikPromon (R&D, 2, 1, R) of lees de VST’s • _UserIO • _CheckPoint • _Startup • _ActSummary • _ActIOTyp

  9. Metenis (z)weten(2) • Windows Performance Monitor (perfmon) • Gemetenaan: • CPU • RAM • DISK I/O en Queue length • MeerInformatie: • Progress Performance & Tuning (Guide & Training) • Performance Tuning Guidelines for Windows Server 2008 R2 • Gebruikboeken en presentaties van Dan Foreman (Bravepoint) (Google ‘Dan Foreman’) http://www.bravepoint.com • Tom Bascomhttp://www.greenfieldtech.com (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 (gebruikttesten 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)

  11. Hardware (2) • Storage (nogtetesten) • SAN Equallogic PE5000-E (16 discs 4,5 TB Bruto, iSCSI) • Voordelen • Betrouwbaar (alles redundant & fail over/replicatie) • Snapshots (i.c.m. proquietbinnen 1 sec. backup) • Zeereenvoudig in gebruik en beheer • Nadelen • Belastingmoeilijkertecontrolerenomdaterveelanderesystemen op zijnaangesloten (VMWare) • Single Point of Storage • Alserwatmisgaat…… • Firmware upgrade  ca. 20 servers down

  12. De TEST • Wattestenvoor benchmark • petest.p (CIM load van) • Iclotr02 3.4.1 (Verplaatsenheen & 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 OrderInvoiceRpt) • Grsync 25.21.21 (Eindemaandfinancieel rapport) • Metendoorlooptijdgeheel en per onderdeel. • 25.21.21 in meerderesessiestegelijk ‘draaien’ • Eigen test.pRandom & Sequential Read/Write

  13. Resultaten (voorlopig) • Opvallend • CPU is meestal de bottle-neck • Waarschijnlijkdoordat SSD zosnel is en/of veel RAM • Vrijweliederetaakdraait op 1 core 100% tot finished • Het gaatdusnietmeerom 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_histuit buffer (-B 1.000.000 = 8GB ) in 74 sec. • Read gltr_hist (20^6 records) from disc in 79 sec! (+7%) • Minder RAM bijgebruik SSD is heel goedmogelijk • Windows vs Linux! (1,08 vs 0,87 mlj Records Read/sec)

  14. Conclusies • Hardware • SSD is eensuccesnummerm.b.t. performance • Veel RAM is ook heel betaalbaar • OS • 64 bits is een must indien je veel RAM wilgebruiken • 32 bits  2GB max • 64 bits -> 16 TB max (18446744073709551616 bytes theoretisch) • Redelijkalternatief is 32 bits en SSD (nietgetest) • Windows of Linux? • Hangtvooral van omgeving en beschikbarekennisaf • Performance stabiliteit en security zijnslechteargumentenvoor OS keuze.

  15. Conclusies (2) • Progress (in MFG/Pro omgeving) • Reads:Writes is ca. 100:1  Optimaliseer Reads(en voorkom locking issues!) • 64 bits begintvolwassenteworden • R-code uitwisselbaar Windows Linux (64 bits) • Client is meestal Windows, Shared Memvaak Linux • Linux/Unix  Beschikbaar op diverse platformen • Geen GUI code voor client server (op Windows compileren) • Windows 64 bits alleen char. GUI nognietbeschikbaar! • Optimaliseer je code, daar zit nogveelwinst!!! • Ditgeldtvooreigen code maarookzekernogvoor QAD

  16. THE PROGRAMMING APPROACHBy Peter Harink, 4Efficiency

  17. Inleiding • De techniek en de configuratiezijnheelbelangrijk MAAR… • De programmatuurmoetzeker niet vergetenworden

  18. WAT HEBBEN WE GEDAAN? • VST (Virtual System Tables) monitoren • Bijwelketabellenzittengrootsteproblemen (PS denkaandatabase-server opstartparameter ‘tablerangesize 1200’) • Programmatuurscannen • Whole-index • Gestarteprogramma’s op specifieketijdstippen • Grootsteknelpuntenoplossen

  19. Elke 10 minutentotalen per tabelopslaan

  20. Totalen per dag

  21. De pieken

  22. De Top 10 Slik! ?

  23. HOE OORZAKEN ZOEKEN? Probleem Top 10: - Wemoetenalleprogramma’s die tabel gebruikenanalyseren… Hulpmiddel: - Pieken: Reducerenaantalprogramma’s - XREF Compile: ZoekennaarWhole-Index (Querieszonder 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. Maar daarvind je niet allesmee

  28. SIMPEL VOORBEELD Primary unique index: ld_loc_p_lot + ld_site + ld_loc + ld_part + ld_lot + ld_ref Ld_detheeft : 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 END. ? ?

  29. MFG/PRO VOORBEELD Primary unique index: ld_loc_p_lot + ld_site + ld_loc + ld_part + ld_lot + ld_ref Ld_detheeft : 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‘) : END. ? ? 10.696

  30. Dat isschrikken… Hmmm…

  31. 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 .

  32. VOORBEELD 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‘) : END. Uitlegwordt nu eenstuklastiger…

  33. Veelgemaaktefouten • Geen index-fields • WHERE ad_name BEGINS ‘Jansen’ • Geenslimmequerieswaardoortochondanksgebruikkey-fields in WHERE TOCH Whole index (Full Table Scan) wordttoegepast • 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-fieldgeen ‘equality match’ • INDEX = ld_site, ld_loc, …. • WHERE ld_site >= ‘A’ AND ld_site <= ‘A’ AND ld_loc >= ‘X’ AND ld_loc <= ‘Y’

  34. Conclusie • Oorzaak: Onwetenheid / Fouten / Slordigheden / Veel range selecties => Daardoorveelongeindexeerdezoekacties • Veelvoorkomend: - Site of Domain mist in opvraag OF zijn range-selecties (>= en <=) - ’Onhandig’ geconstrueerdequeries • Erg belangrijk => regelmatigprogrammatuurscannen => Of nogbeter: elkewijzigingvoor in productienemen -> # readsscannen -> XREF compile uitvoeren Want: • Server drukvoorniets • En nogerger, gevolgismeerdisk-reads, wantmemory-buffers wordenleeggetrokken, inefficiente LRU (Least RecentlyUsed) - Chain

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

  36. DankvoorUwaandacht! peter@4efficiency.nlgwscheppink@aep-industries.com 06 -537 068 49 055- 599 65 84

  37. BIJLAGEN - Mnd_detvoorbeeld - De Theorieachterindexen

  38. Oh ja… De mnd_det!5.880 records Slik! ?

  39. Standaard oplevering QAD

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

  41. 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

  42. 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

  43. 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

  44. 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

More Related