Kbase P92012: Multiple Reads of PROMSGS causes a drop in performance
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
03/04/2008 |
|
Status: Verified
FACT(s) (Environment):
Progress 9.x
OpenEdge 10.0x
OpenEdge 10.1A
OpenEdge 10.1B
All Supported Operating Systems
SYMPTOM(s):
Frequent reads of PROMSGS causes a high level of disk IO
FIND ... NO-ERROR is used frequently in the code
On UNIX, Truss output shows many reads of the promsgs file.
ON PC, FileMon log file shows many entries similar to the following:
prowin32.exe:xxxx FASTIO_READ DLC$\promsgs SUCCESS Offset: 11178 Length: 81
Offset: 11178 Length: 81 resolves to error 138
** <file-name> record not on file. (138)
PROMSGS file is local to the client.
Problem is exacerbated on multi-user systems where multiple users reference the same PROMSGS file
CAUSE:
Bug# OE00093132
CAUSE:
Enhancement Request# 0000003334
CAUSE:
"FIND ... NO-ERROR" statement that returns not available in a loop causes the PROMSGS file to be read many times. This behaviour is expected but could be improved.
FIX:
Upgrade to 10.1B03
Upgrade to 10.1C
In 10.1B03 and later, the PROMSGS file is cached in memory by the first client who needs to access a message in the file. Once the file is in memory, all other client sessions will leverage off the file in memory instead of performing an additional I/O against the file on disk.