160 likes | 170 Views
Top Performance Enhancers Top Performance Killers in Progress. Dan Foreman Progress Expert danf@prodb.com. Introduction. Progress User since 1984 (V2) Presenter at many Progress & QAD Conferences Author of: Progress Performance Tuning Guide Progress Database Administration Guide
E N D
Top Performance EnhancersTop Performance Killersin Progress Dan Foreman Progress Expert danf@prodb.com
Introduction • Progress User since 1984 (V2) • Presenter at many Progress & QAD Conferences • Author of: • Progress Performance Tuning Guide • Progress Database Administration Guide • V10 DBA Jumpstart • Virtual System Table Guide
Introduction – There’s more • Developed these tools for DBAs: • ProMonitor – Monitor Progress DBs • ProCheck – Monitor AppServers, WebSpeed, Admin Server, Name Server, etc. • Pro Dump&Load – Dump&Load a Database of any size with nearly no downtime • Other stuff
Introduction – Who Are You • Progress Version • V10?, V9?, V8, or ?? • Largest Single Database • Database Operating System
Top Destroyer #1 Ad Hoc & Period Ending reports run against a Production DB with some ODBC based BI or Reporting Tool Use a Reporting Database instead Use OpenEdge Replication to create a D/R, Reporting DB Copy on another Server Look @ BravePoint’s Pro2SQL Product Regularly run UPDATE STATISTICS
Top Destroyer #2 • Developers who don’t understand the Progress Indexing Rules • They are reasonably well documented • Progress Documentation • Progress Performance Tuning Guide
Top Destroyer #3 • Poorly Tuned Databases • Crucial Database Parameters & Helpers: • -spin (DB Startup) • -blocksize (prostrct create; Unix/Linux) • APW/BIW/AIW Processes • -B (DB Startup) • -bi (proutil truncate bi)
Top Destroyer #4 • Poorly Configured Databases • Database block size (-blocksize) of 4K (AIX/Linux) or 8K (all other IX) • Not using Type 2 Storage Areas • Tables or Indexes stored in the Schema Area • AI Extents not separated from DB/BI Extents (mainly for integrity, not performance)
Top Destroyer #5 Not using After Imaging Although that’s more of a Database or job future destroyer than a performance destroyer
Top Destroyer #6 Not performing a Regular Dump & Load Using Type 2 Storage Areas does NOT mean you’ll never need to D&L again – don’t trust anyone who told you that Monitor Scatter & Fragmentation in proutildbanalys reports
Top Destroyer #7 • Poorly Tuned AppServers & WebSpeed Agents • Important Parameters: • -mmax # • -TB 31 • -TM 32 • -q • -Bt #
Top Destroyer #8 RAID 5 RAID 5 on most Disk Arrays and SANs penalizes Write Performance up to 50% (i.e. 2X slower)
Top Destroyer #9 • Monitor Java (or the processes that use Java) • WebSpeed Broker • AppServer Broker • Admin Server • Name Server • Tomcat • Watch for excessive memory use or high CPU utilization
Top Enhancer #1 Shared R-Code Libraries (also known as Memory Mapped Libraries) Conserve Memory because code is shared rather than in each Client’s private memory Code execution is much faster
Top Enhancer #2 Stripe (RAID 0) Database Disks Not required for the AI or BI Disks JBOD is sooo 90’s
Questions? • For further info (not free): • danf@prodb.com • +1 541 908 3437 (Available 24/7) • Alternatively 770-449-9696 X3911 • www.BravePoint.com