In a typical MobiLink server, most of the memory is used by the memory cache, which stores row data and related data structures
and network buffers. In general, data that is unbounded in either size or quantity is stored in the cache. If the amount of
data to store in the memory cache exceeds the cache's size the excess is transferred to disk, which can become a potential
bottleneck in synchronization performance. The degree to which swapping to disk is a problem depends on the amount and frequency
of disk I/O and the speed of the disk. To eliminate this potential bottleneck, it is recommended that you avoid swapping data
to disk completely. Watch for warning 10082 in the MobiLink server log, or the "Cache is full" alert in the SQL Anywhere Monitor.
By default, the MobiLink server automatically grows its cache up to 60% of the available process address space and shrinks
its cache if other processes on the system require more memory, or the server's non-cache memory grows larger. The initial
maximum and minimum cache sizes can be controlled with the -cinit, -cmax and -cmin mlsrv12 server options. If desired, the
server can disable dynamic cache sizing by specifying the same value for the -cmax and -cmin option values.
Another major use of memory within the MobiLink server is the embedded Java and .NET VMs. In deployments that make heavy use
of the direct row API or that embed application servers like JBoss or Tomcat, the VM memory use can exceed the memory cache.
When using a Java VM, you usually have some control over the amount of memory the VM uses. Most Java VMs provide the -Xms
and -Xmx switches that allow you to specify the maximum and initial VM heap size, respectively.
You can find out the amount of memory being used by the embedded VMs with the VM Memory Usage SQL Anywhere Monitor metric, or with the VM_MEM_USE -ppv value.
The remaining memory is used for storing state information about each synchronization, thread stacks, inter-thread communication
and the ODBC driver. Typically, this accounts for a few tens of megabytes of memory and the amount used is bounded by the
-nc, -sm and -w options for mlsrv12. It is worth noting that non-SQL Anywhere ODBC drivers can use a significant amount of
memory, particularly when processing BLOB columns.