Kbase P76885: Unix Kernel Tuning for 64 bits Recommendations and Suggestions
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
2/7/2005 |
|
Status: Verified
GOAL:
Unix Kernel Tuning for 64 bits Recommendations and Suggestions
GOAL:
What are the Progress relevant kernel parameters for 64 bits?
GOAL:
Tuning a 64 bits Unix Kernel for Progress
FACT(s) (Environment):
Unix 64 bits Kernel Formulas
FIX:
Each shared memory segment requires one identifier. How many you need depends on the number of databases you run in multi-user mode at the same time and how much shared memory each of them needs, and what the maximum shared memory segment size is set to. However: the data structures allocated by the kernal are fairly small so oversizing this parameter is not harmful.
You also need to set shmseg on some operating systems. This limits the number of shared memory segments a process can be attached to at one time.
It should be set at least as large as the total number of segments for all the databases a progress self-serving session will be attached to. Or, if self-serving sessions are not being used, then at least as large as the total number of segments used by the database that has the most segments.
Again, oversizing this should not be harmful.
In 64-bit progress releases, the database shared memory segment size limit is set to 1 GB (it is a minor bug that this number was chosen and it should be changed, but not a major problem right now). The operating system segment size limit (shmmax) should be at least this large. How many segments are needed for one database depends on the values of the startup parameters.
The exact formula for calculating how much shared memory is needed is not published - it is very complicated and changes from release to release and one patch to the next. Every time there is a shared memory version change the formula has probably been affected.
For most purposes, you don't need an exact number. If you look in the R&D section of promon, there is a display that will tell you how much shared memory is allocated.
The major contributors are roughly
1. database buffers (-B times database block size)
2. database buffer headers (-B times 200)
3. lock table (-L times 34)
4. connection table (((-n+3) times 900) + (-Mn times 900))
5. transaction table (size of connection table * 50)
These are just rough numbers. To get the actual amount allocated, see promon.