You want to know how the liveCache in versions < 7.4 uses the extended memory (PSE36 under Windows NT / AWE under Windows 2000). Other terms
For version 7.4, please refer to Note 561338.
liveCache, AWE, PAE, PSE36, Windows NT, memory, Windows 2000 Reason and Prerequisites
- Windows NT 4.0 Enterprise Edition
- Intel PSE36 driver installed
- PAE / AWE was activated on OS side
- if the liveCache service should not run under the SYSTEM account, the following right should be granted to the relevant account:
local security policy ->
local policies ->
user right assignement ->
lock pages in memory
- liveCache version > 7.1.4.02
- liveCache version > 7.2.3.02
1. General information:
The solutions provided by Intel Intel (PSE36 / Windows NT) or Microsoft (AWE) in order to be able to address more than 4GB main memory on the application side apply only to a 32 bit environment (CPU). You must address the memory area > 4GB with special methods and thus the memory area does not increase the virtual address area of a process. Thus the maximum address area available remains limited to 3GB, even if a machine was upgraded to the maximum limit of 64 GB RAM. The support of the liveCache regarding memory > 4GB is not an extension of the DATA_CACHE, that means even if the machine has more than 4GB physical main memory, the DATA_CACHE and the OMS_HEAP will always be in the virtual address space of max. 3GB. Thus you cannot increase parameter DATA_CACHE with increasing memory extension (>4GB) of the machine. 2. How much extended memory the liveCache uses:
Because only one process can work systemwide with PSE36 under Windows NT, the liveCache uses the whole area (that is main memory size - 4GB) for itself. 3. Use of the extended memory in the liveCache:
Under Windows 2000, several applications can work with AWE. Therefore the area to be used by the liveCache can be limited by parameter MEM_ENHANCE_LIMIT (refer to Note 384680). By using command
x_cons <liveCacheName> show pse_stat
you can determine how much extended memory the liveCache uses:
configured pages : 51750 pages to flush : 1428
In addition you can obtain this information also from the beginning of file "knldiag" which is in the RUNDIRECTORY of the liveCache. Example: ... PSE/AWE 51750 pages used for data pages ...
The liveCache can only change the data which is in the DATA_CACHE. If the DATA_CACHE is full and if you want to import or create new data, the system must page out data from the DATA_CACHE to the data Devspaces. The I/O required for that is very slow and you should avoid it especially in the liveCache environment. Example:
If you activated the use of the extended memory by setting the respective liveCache configuration parameter (refer to Note 384680), the liveCache uses the extended memory as a hard disk Cache. If data has to be paged out from the DATA_CACHE (due to lack of space) of if required data has to be imported, you should transfer this data not with I/O by using the data Devspaces, but with "copy" by using the extended memory. The latter method is much faster and works as long as the extended memory is able to include the affected data. That in turn depends on the PNO (page number) that is assigned by the liveCache for every data page. Because the PNO of a data page is used as an index for the position within the extended memory, you can calculate exactly which data page the extended memory can include and which not. The goal is that the extended memory is able to include ALL data pages used by the liveCache. All data pageswhich cannot be included in the extended memory due to their high PNO, are only addressed via the data Devspaces. This goes together with a (slow) physical I/O.
The PNOs of the data pages also increase with increasing liveCache. The PNO of a data page alone (and not the actual fill level of the extended memory) decides whether or not to keep this data page in the extended memory. If the size of the liveCache exceeds the size of the extended memory, the system accesses (import into / displace from the DATA_CACHE) all data pages (that cannot be included in the extended memory due to their high PNO) via physical I/O! The system continues to access these data pages via physical I/O even if the size of the liveCache decreases below the size of the enhanced memory again, because the PNO of a data page remains the same during the entire lifetime of the data page.
Via command "x_cons <liveCacheName> show pse_stat" you can retrieve information on the PSE configuration or PSE accesses.
configured pages : 51750 pages to flush : 1428
read pages : 62808 reads out of range : 0
written pages : 14491 writes out of range: 0
Values "read pages" and "written pages" in each case represent the corresponding accesses to the extended memory.
Under "reads out of range" and "writes out of range" the system counts displacements from or requests from the DATA_CACHE that could not be made via the extended memory. For all these accesses the system needed to trigger a physical I/O.
These two values should always be 0, if possible!
At the time of the checkpoint the system writes the data pages changed in the extended memory (in this case pages to flush: 1428) onto the data Devspaces.