In einem typischen MobiLink-Server wird der meisten Speicherplatz vom Cache verwendet, der Zeilendaten sowie die dazugehörigen Datenstrukturen und Netzwerkpuffer speichert. Im Allgemeinen werden im Cache Daten gespeichert, die entweder in der Größe oder in der Menge unbegrenzt sind. Wenn die Menge der im Cache zu speichernden Daten die Größe des Cachespeichers überschreitet, wird der Überschuss auf die Festplatte übertragen, was einen potenziellen Engpass in der Performance der Synchronisation bedeutet. Das Ausmaß, in dem die Auslagerung auf die Festplatte ein Problem darstellt, ist abhängig vom Umfang und der Häufigkeit des Festplatten-I/O und von der Geschwindigkeit der Festplatte. Um diesen potenziellen Engpass zu beseitigen, wird empfohlen, möglichst keine Daten auf die Festplatte auszulagern. Achten Sie auf die Warnung 10082 im MobiLink-Serverlog oder den Alarm "Cache ist voll" im SQL Anywhere-Monitor.

Standardmäßig vergrößert der MobiLink-Server seinen Cache automatisch auf bis zu 60% des verfügbaren Prozess-Adressraumes und verkleinert seinen Cache, wenn andere Prozesse im System mehr Speicher benötigen oder der Nicht-Cache-Speicher des Servers größer wird. Die anfängliche maximale und minimale Cachegröße kann mit den mlsrv12-Serveroptionen -cinit, -cmax und -cmin gesteuert werden. Falls gewünscht, kann der Server die dynamische Cachedimensionierung deaktivieren, indem er für die Optionswerte -cmax und -cmin denselben Wert angibt.

Siehe:

• mlsrv12-Option -cmax
• mlsrv12-Option -cmin
• mlsrv12-Option -cinit

Es gibt mehrere Möglichkeiten, Informationen über den Cache herauszufinden:

Ein weiterer Bereich innerhalb des MobiLink-Servers, der viel Speicherplatz in Anspruch nimmt, sind die VMs für Embedded Java und .NET. In Deployments mit intensiver Nutzung der API für die direkte Zeilenbehandlung oder mit eingebetteten Anwendungsservern wie JBoss oder Tomcat, kann der von den VMs belegte Speicherplatz die Größe des Cachespeichers übersteigen.

Wenn Sie eine Java VM verwenden, haben Sie normalerweise eine gewisse Kontrolle über den von dieser belegten Speicherplatz. Die meisten Java VMs bieten die Parameter -Xms und -Xmx, die es Ihnen gestatten, die maximale bzw. anfängliche VM-Heap-Größe festzulegen

Um den von den eingebetteten VMs belegten Speicherplatz zu ermitteln, können Sie entweder die Metrik Speichernutzung der VM des SQL Anywhere-Monitors oder den Wert VM_MEM_USE für die Option -ppv verwenden.

Siehe:

• Liste von Metriken
• mlsrv12-Option -ppv

Der verbleibende Speicherpaltz dient zum Speichern von Statusinformationen über jede Synchronisation, Thread-Stacks, Thread-übergreifender Kommunikation und ODBC-Treiber. In der Regel macht dies ein paar Dutzend Megabyte Speicherplatz aus und dieser wird begrenzt durch die Optionen -nc, -sm und -w für mlsrv12. Es ist erwähnenswert, dass nicht auf SQL Anywhere basierende ODBC-Treiber sehr viel Speicherplatz belegen können, vor allem bei der Verarbeitung von BLOB-Spalten.

Siehe:

• mlsrv12-Option -nc
• mlsrv12-Option -sm
• mlsrv12-Option -w