As explained in the Tech Tip "Maximizing Available Memory for 4D", 4D v11 SQL will acheive its maximum cache size on a 64-bit OS with at least 8GB of RAM. However even with this configuration you may have noticed that 4D cannot access, for example, 3.5GB of cache. Why is this?

The answer is quite simple: 4D asks the OS for the maximum chunk of memory (up to the size you specify) for the cache and allocates that much. In other words the OS decides the maximum amount of memory it can give to 4D. If the cache allocated is smaller than the desired size there is, in fact, nothing 4D can do about it.

As a developer you have some minimal control over this. Limiting the applications that are running on the machine and limiting the number of background processes will allow the OS to give 4D larger cache sizes. As more and more processes execute, they will occupy different sections of the address space (i.e. memory is not allocated contiguously) so the size of the largest chunk of free memory will decrease.

However it is also important to note that 4D's memory footprint, especially 4D Server, can be substantially larger in 4D v11 SQL (see the Tech Tip "Changing 4D Server stack sizes in 4D v11 SQL"). To prevent developers from inadvertantly shooting themselves in the foot with excessively large cache sizes, the maximum cache size in 4D v11 SQL Release 5 (11.5) was reduced to 2.3 GB (2,500,000 KB).