In Microsoft visual studio 2005 you need to go into the project options to change the “Struct Member Alignment” to be 1 byte when using the fat client. They use a more liberal 4 bytes when compiling the server code. This puts a /Zp1 or /Zp4 in the linking command line.
If you don’t do this, when you look at your variables in the viewer, they’ll be missing some chars at the front.
Table 7-1 Windows Server Memory Shares
| Pool | Percent of Total Memory |
| Kernel and other system services | 9% |
| File Cache | 41% |
| Paged Memory | 50% |
Windows Server memory manager tries to balance each application's usage of memory by dynamically paging memory between physical RAM and a virtual memory paging file. If an application is particularly memory-intensive (like Oracle Database) or if a large number of applications are running concurrently, then combined memory requirements of the applications may exceed physical memory capacity.
The large proportion of memory reserved for file caching (41%) can be quite beneficial to file and print servers. But it may not be advantageous to application servers that often run memory-intensive network applications. A Windows Server file cache is particularly unnecessary for Oracle Database, which performs its own caching through System Global Area.
You can reset the Windows Server memory model from the default file and print server, with its large file cache, to a network applications model, with a reduced file cache and more physical memory available for Oracle Database.
| See Also: Your operating system documentation for instructions |
This is harder in a cluster, as you cannot access these programs from the control panel.
So, if you have 14GB of memory, and the system is reserving 41% for file cache, this means that there is 5.74 reserved. Your application can only use 8.26, 8.26 is reduced by 2 for the OS – and this might tell you why you are constantly paging!
If you are getting kernels failing (turning to Zombie), there are two places that you need to look:
1. Look in the kernel logs themselves for any relevant messages
2. Look in the jdenet logs, this will contain the "call stack" for the failure of the logic kernel. This occurs on ALL platforms.
CTRAN.dll/N4900080/RouteShipment
CTRAN.dll/N4900200/LoadRoutingOptions
CTRAN.dll/B4900400/F4950SelectRoutingEntries
CTRAN.dll/N4900420/VerifyRoute
CTRAN.dll/N4901350/CalculateDates
CTRAN.dll/B4900890/CalculateWorkday
CMFGBASE.dll/UNKNOWN/GetWorkDayCalendar
CCORE.dll/UNKNOWN/GetDataDictionaryDefinition
A call stack is read top down, so the faulting program in the above call stack is "CCORE.dll/UNKNOWN/GetDataDictionaryDefinition".
From the logs, all kernels were failing with the same call stack, so it would seem from the name of the function that there is a problem with the PD812\dddict or ddtext files - or maybe glbltbl.
The above tells us that NER N4900080 function RouteShipment was calling NER N4900200 function LoadRoutingOptions and so on! This is a deep callstack.
Note that the JDE logs had similar messages about DD spec problems.
