Kbase P19002: Using memory mapped shared libraries affects performance
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
13/11/2008 |
|
Status: Verified
GOAL:
Using memory mapped shared libraries affects performance
GOAL:
What are memory mapped shared libraries
GOAL:
How will the introduction of memory mapped shared libraries affect performance benchmarks?
FACT(s) (Environment):
Progress 9.1D
Progress 9.1E
OpenEdge 10.x
All Supported Operating Systems
FIX:
In understanding 'what' memory mapped shared libraries are and 'why' they will impact performance benchmarks, herewith a discourse on memory mapped procedure libraries, with particular emphasis on performance, followed by suggestions relating to further investigation. In the world of performance tuning - there are no silver bullets - each change made needs the benchmark tests to be analysed as to their effective execution of the change and then analysed as to their impact.
When loading and executing r-code procedures from a Procedure Library, Progress opens only one file, the library itself, to access all of the r-code files in the library. In theory running .pl's will give an application performance gain in the following ways:
- Faster access to r-code, because the clients can access and execute the same r-code segments in shared memory as opposed to each client managing their own copy.
- Fewer file open and close operations which means -
- Less I/O to srt files, the temporary sort files that are used to hold r-code that has been "swapped-out" of memory can be reduced in size, because r-code read in from a library can easily be reread from the same library.
There are a few other considerations:
1) Are the libraries in a network environment on file servers? If so, it will most likely be faster to use the sort file than to perform remote file server accesses to the library. The -pls startup parameter will direct Progress back to the conventional sort technique for library-based procedures, and can make use of the local- or RAM-disk to hold the sort file. This is a case where the 'advantages/disadvantages' of procedure libraries and -mmax need to be weighed up against each other in relation to the particular architecture of the performance environment (as is the delicate art of performance tuning). Memory management is simpler with memory mapped procedure libraries, because active r-code segments are no longer stored in the -mmax memory area, multiple clients can access and execute the same r-code segments in shared memory rather than each client maintaining individual copies. Whereas, with -mmax, the memory space is not shared and the space can dynamically expand beyond the value specified by -mmax (which makes memory management more complex).
2) Using a library consumes available memory by keeping the library available in memory, you may want to opt for reading the library directory in from disk as needed, trading off speed for memory availability. The PROGRESS switch -plm causes PROGRESS to use a 512 byte cache for the library directory, rather than reading the entire directory in from memory. Using the library requires memory for the library directories, which are dynamically allocated. The command line switch "-plm" allows you to opt for having the library directories cached in small chunks (rather than being read in, in their entirety) in the event that PROGRESS fails due to memory shortage when a library is used. This cache incurs a 512 byte overhead.
3) If the PROPATH environment variable is changed during a PROGRESS session, then any libraries that appeared on the old PROPATH but not on the new one are closed. Any libraries that were on the old PROPATH and the new one remain open.
Libraries are only opened as needed. If all requests for r-code files are satisfied by directories earlier on the PROPATH than any libraries, then no libraries are opened.
When using mapped drives, the Procedure Libraries that are needed for your application need to be identified and placed at the beginning of the PROPATH. Execution environment activity can be monitored by using the startup parameter -yc. Progress collects procedure access and usage statistics throughout the Progress session and writes them to an output file (by default, client.mon in the current working directory). The client.mon file can be viewed with any editor. It will show all the <filename.r> files that .were accessed during program execution. The particular Procedure Library that contains the .r file that was accessed then needs to be identified, by for example, running the following 4GL program:
Message search ("filename.r") view-as alert box.
This will help to identify the name of the procedure library that contained the .r file and it is this Procedure Library that should then be added to the beginning of the PROPATH.
It is not uncommon to find that there are several procedure libraries being used to gain access to a few .r files. These .r files can then be extracted using prolib.exe placed in their own directory and add that directory to the beginning of the PROPATH.
The Progress Client Deployment Guide, 'Managing Client Performance' and 'Monitoring R-code Activity' is worth referring to for more detail on the above.
All the above, having being said, with particular reference to the discussion of introducing memory mapped procedure libraries (.pl):
- At the time of witting, there are no known issues relating to procedure libraries and performance, there *may* be an issue here, but this will need detailed and specific investigation in breaking it down to prove it.
- Furthermore, in a similar vein, 'overall performance loss' needs to be broken down and quantified to fully understand the results of performance testing.
a) What were the number of user sessions involved and how are they connecting? The library is initially 'loaded' and mapped by a RUN statement, then only 'unloaded' when the last client session that opened it has exited. The 'load' is an overhead the first time, and thereafter 'faster' because it is already in shared memory. Which leads us to -
b) What is the total size of the shared memory libraries? Is the r-code all loaded into one big .pl (= 'loading hit' for sure), or many? If many, re-consider the grouping of the .r files and their order of access in the PROPATH.
c) There are 3 major players in the field: CPU overload - memory swapping - disk speed. Did memory utilisation decrease or increase? What was the difference in I/O? CPU utilisation (is the kernel sufficiently tuned for this exercise - was there swapping) ?
To assist in quantifying the above and highlight any differences in the runtime execution, introduce the ETIME statement in the benchmark code to message to a log file (accurate to 1/60th second) and specifically time this operation, together with system performance metrics, to understand your particular scenario and with these results, we may be able to further assist. As a matter of note, there is always our consultancy service which you may consider making use of in this exercise..