Feedback
Did this article resolve your question/issue?

   

Article

PROMON execution time much higher since OpenEdge version 11.7, 12.0

« Go Back

Information

 
TitlePROMON execution time much higher since OpenEdge version 11.7, 12.0
URL Namepromon-execution-time-much-higher-since-openedge-version-11-7
Article Number000115484
EnvironmentProduct: OpenEdge
Version: 11.7.0, 11.7.1, 11.7.2, 11.7.3, 11.7.4, 11.7.5, 12.0, 12.1
OS: All supported platforms
Question/Problem Description
PROMON execution time much higher since OpenEdge versions 11.7, 12.0
The gather.sh script used by progress support runs a lot slower since OpenEdge 11.7
Loading PROMON R&D menu is very slow after upgrading to OpenEdge 11.7
After typing "R&D" and pressing enter, it takes between 15 and 25 seconds before the first R&D Menu shows.

PROMON access is affected by any activity screens and all options that update the activity counters.
The slow execution time of U, L, Z options in PROMON is in direct proportion to the size of database shared memory
The more memory used for buffer pool (-B/-B2), the more delays are apparent in returning PROMON results
 
Steps to Reproduce1. start the database with a large -B value, for example -B 16500000
2. call 'promon databaseName' through a script using the promon options:
R&D # Advanced options
2 # Activity Displays ...
9 # I/O Operations by File
and update the activity counters 1000 times in a loop with the option: "U" - Update activity counters.
Clarifying Information
The same script calling PROMON executed in OpenEdge version 11.6 or earlier execute much faster than in OpenEdge version 11.7 and 12.0  
Error Message
Defect NumberOCTA-13662
Enhancement NumberOCTA-39648
Cause
PROMON in OpenEdge 11.7.0, 12.0 added statistics per block types in buffer pool.

The counts of the blocks in buffer pools by their types are displayed in:
Buffer Cache => Active Blocks, Master Blocks, Index Blocks, Record Blocks, Free Blocks ... etc.

To get these statistics for different block types, PROMON scans buffer pool when the R&D menu is first accessed and whenever statistics updates are requested (U, L, Z options). This takes more time and CPU when the buffer pool is large and longer when there are secondary buffer pool statistics to consider.
 
Resolution
Upgrade to OpenEdge 11.7.6, 12.2.0 where the cost of scanning the buffer pool has been removed from the R&D startup and any statistics update operation in PROMON. 

The pause is isolated to the Buffer Status screen and not for the R&D menu as a whole or to each of the activity menus. The delay will only be encountered when explicitly looking at the Buffer Status Screen (R&D, 1. status, 7 Buffer Cache), when the buffer pool block type counts are then updated.

The first _ActBuffer VST query is still affected due to the buffer pool block type count metrics, subsequent querires are fast. How to increase speed of _ActBuffer when gathering performance metrics?

 
Workaround
Notes
Last Modified Date9/29/2021 3:49 PM
Attachment 
Files
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.