Basic Variable Allocation Heaped vs Shared Memory UniData 8

October 16, 2019

What changed at UniData 8: Memory Allocation

Prior to UniData 8.1.0, UniBasic variable space was allocated via shared memory from a system wide shared pool (some of these go back to the original design in the 1990s). Why? It was done to reduce total system wide memory consumption and to ensure that UniData had enough memory available for a user application to function. This memory allocation reserved the base memory requirement, as defined by the shared memory parameters, for use by UniData only. And, the shared memory segment was divided into smaller segments, allowing multiple processes to use the same memory area.

Shared Memory Challenges prior to UniData 8

If a process overran its allocated shared memory buffer space and UniData did not detect this, the result was the process ran in another process’s working area, possibly causing corruption of the memory area with multiple processes aborting or producing abnormal results.

There were constraints within the UniData configuration that controlled how many segments a process could attach to and tech support and services spent time tuning the segment configurables to ensure problems did not occur.

Why we changed to Heaped Memory

The potential problems of shared memory overruns and the impact on other UniData processes (e.g. it’s very unlikely to only impact one process) included exceeding the limits of the configurables, which requires analysis, retuning and restarting of UniData.

In UniData 7.3, as part of our internal diagnostic memory checking project, we added the ability to use a heap memory allocation instead of shared memory allocation for testing purposes. The support case results in UniData 7.3 where we instructed customers to turn on heap memory allocation demonstrated that the potential issues were avoided.

Today, on most systems, memory is no longer a scarce resource. UniBasic variable allocation problems or exceeding the configurable limits was a common support call topic prior to UniData 8. UniData 8 has almost completely eliminated support calls related shared memory allocation, making debugging any problem that does occur much simpler for tech support and R&D.

Shared Memory Overview

UniData has a Shared Memory Manager (smm) and a Shared Basic Code Server (sbcs) that create shared memory segments. UniData processes attach and use those segments. Other parts of UniData such as replication and RFS also create memory segments but we are not discussing them in this post.

• sbcs Rn.n allows for a single shared copy of globally cataloged UniBasic programs
• smm Rn.n (glm) UniData record locks (e.g. READU)
• smm Rn.n (ctl) global control table, dynamic file current modulo table, group/physical locks
• smm Rn.n (shmbuf) storage for UniBasic variable contents & ECL command intermediate results – known as Global Segments (GSM)
• smm Rn.n (indirect) ‘Self-created’ or ‘private’ segments used by an individual UniData user-process to store a large record or string

We are interested in the (shmbuf) segments. For the purpose of this post (indirect) segments are not included in the size of the main shmbuf segment.

Shared Memory Baseline

The next four graphics are from a UniData system after it has just started. The graphics show three tools that you can use to determine the size and number of segments created. On a system that is under load the output will look different.

Shared memory baseline: $UDTBIN/ipcstat –mb shows the current segments and the shmbuf segment is used for Basic Variable Allocation

Basic Variable Allocation prior to UniData 8

The next two graphics represent what happens when UniBasic programs start working on the system. We are using the same 10 identical phantoms to simulate memory usage as we did for 7.3.

Moving to UniData 8 And Doing Nothing

If your application is on a version of UniData prior to version 8, the shared memory parameters for your configuration may have been heavily tuned to both:

• Improve performance
• Allow processes to access the memory they require and avoid shared memory allocation errors

If the shared memory parameters were changed, you can leave them “as is” and UniData 8 will continue working. But you could potentially be wasting memory by having it reserved in the shared memory segment that will never get used.

Moving to UniData 8: The Opportunities

Each process as a minimum will have only one T-G attachment. The T-G and T-S attachments still exist as they are still used as a temporary workspace for ECL commands and such. Historically it hasn’t been necessary to increase the size for a T-G segment; the tuning was only done around the B-G and B-S segments. Now we have a chance to reduce the size of the shmbuf segment.

Please note:  SHM_GNPAGES * SHM_GPAGESZ * 512.

We can reduce the amount of shared memory reserved and used by UniData processes with Basic Variables to only take up the space they need.

Before making the memory changes at UniData 8, we discussed internally that some of the base values as shipped were too restrictive for the modern user load, so in line with the discussions, now UniBasic Variable Allocation when done at an appropriate base line for UniData 8 installs is:

• SHM_GPAGESZ = 256
• SHM_GNPAGES = 64

This means that each UniData process will take one 128K slot of temporary workspace for ECL commands and if more slots are needed for temporary workspace and the extra memory that is required is less than 128K for the workspace slot, then another 128K slot is used. If the workspace required exceeds 128K, a new self-created workspace segment will be necessary.

The values suggested are base line values only and should be reviewed in the same way as previous shared memory values (along with the tools discussed in this presentation) to ensure they are optimal for your application.

The values should result in a system load of around 60 users having one main memory segment of 8.3 Mb. If the user load increased to 120 it would have two main memory segments totaling 16.6Mb. Even if doubled, SHM_GNPAGESZ to 512, each main memory segment would be 16.6Mb.

Although we have produced these values based on our experience, they are still application dependent and should be reviewed to fit your needs.

If you know your user load is going to be higher than this, then these values need to be adjusted accordingly.

There are other configurables that could be reduced as a result of the allocation change but in terms of performance and memory usage, they will make no difference

If you require more information on the related configurables, they are documented in the manuals. Support and Services can also provide more information or assistance as required.