Best practices for SMP cluster administration
In this document you will find some lessons learned and best practices in the form of guidelines for the administration of SAP Mobile Platform clusters. The list is in no particular order and any implementation steps given applies to the Sybase Unwired Platform 2.2. (SUP), but should be adaptable to all 2.x versions of SUP and SMP with little or no effort.
MBO Design Best Practices
Having application developers that are not intimately familiar with the various advantages and disadvantages of the available MBO design patterns is typically the biggest problem for a mobility project. If the data layer design of your app is not appropriate for the use-case that the stakeholders have in mind, then the solution cannot be successful. Even worse, the changes required to safe the project at a late stage are so fundamental that they will break most timelines.
Links: MBO Design Best Practices
Data Tier Memory Limits
All cluster installations of SMP come with three SQL Anywhere database servers running on the data tier machine. These are installed as Windows Services.
- Service "Sybase Unwired CacheDB" using port 5200 runs the Consolidated or Cache database under the name "default"
- Service "Sybase Unwired ClusterDB" using port 5300 runs the Cluster database under the name "clusterdb"
- Service "Sybase Unwired LogDataDB" using port 5400 runs both the Monitor and the DomainLogging database under the names "monitordb" and "domainlogdb"
It can happen that these database servers content for the memory of the machine, so limits need to be set up to control that behavior.
- On the data tier go to Sybase\UnwiredPlatform\Servers\SQLAnywhere12\BIN64
- Edit the three files "cdboptions.ini", "cldboptions.ini", "monitordboptions.ini"
- In each file add or change the startup options "-ch 2g" to add a hard limit of 2 GB.
- Restart the services
The actual limits that you use should suit the memory available on the machine. The usual reasoning is like this: leave 2 GB for the OS, take about 0.25 GB for the ClusterDB (cldboptions), 1 GB for the LogDataDB (monitordboptions), and give the rest to the CacheDB (cdboptions).
Server Memory Limits
The same phenomenon of memory contention can also occur on the SMP server machines. These typically run the following main processes.
- mlsrv16.exe J2EE server and replication-based synchronization
- OBMO.exe Messaging-based synchronization
Other minor processes are: OBServiceManager.exe (Server service process), sccservice.exe (SCC webserver), dbsrv11.exe (SCC database), AdminWebServices.exe (Messaging admin webserver), AMPService.exe (Messaging queue handler), JmsBridge.exe (Messaging .net client), MlsrvWrapper.exe (Replication .net client), rsoe.exe (Relayserver Outbound Enabler).
In total the minor processes should not consume more than 1GB. The main processes will only consume a lot, when the corresponding synchronization mechanism is used. Limit the mlsrv16.exe process by limiting both the Java Heap Memory and the Mobilink replication cache size. Both these settings are accessible in SCC (see replication parameters).
In order to avoid the situation that these main processes cannot allocate necessary memory during peak times, you can use virtual memory managed by Windows. To do this use Properties > Advanced System Settings > Performance > Settings > Advanced > Virtual Memory > Change and set 'Automatically manage paging file size for all drives'. Monitor the system to ensure that consumption of purely virtual memory only occurs during peak times.
Regular Database Maintenance
There are three important areas that are concerned with database maintenance. Make sure to use all of them regularly as well as running regular backups beforehand.
Enable SCC Maintenance Tasks
There are four database maintenance tasks that should be enabled in SCC for all domains that are used productively. All of these tasks are meant to keep the database from building up over time.
Domain Logging Setup
If you use domain logging, make sure to log the payload only for debugging purposes. Also make sure that you auto-purge your log data as it builds up quickly. In the SCC use the left side navigation panel, go to "SCC > Domains > [Domainname] > Log". On the right side tab bar go to "Settings", go through all domain logs and click "Configuration" in the tab bar. Finally select the auto-purging option.
Unload Data Tier SQL Anywhere Databases
Use the SQL Anywhere dbunload tool to make sure all the databases mentioned under the topic "Database Memory Limit" are regularly unloaded.
Tune Change Detection Interval and Cache Coherence Interval
Either during your MBO design phase, or (if your MBO package is already deployed) in SCC, you need to adapt these two settings to your business requirements. I will describe the SCC way because this is usually caught late. In the left side navigation panel go to "SCC > Domains > [Domainname] > Packages > [MBO package name]".
Change Detection Interval (CDI)
In the right tab bar click on "Subscriptions". Make note of all the Synchronization Groups which have subscriptions (can be none). Click on the "Synchronization Groups" tab. Set the CDI for all synchronization groups that do not have subscriptions to 0, this means change detection is disabled. Note that detecting changes only makes sense, when users have an MBO push subscription on that sync group. This is part of the MBO push notifications mechanism. Typically this push notification feature is not used at all, but the change detection still cause some noticeable load on the database.
Cache Coherence Interval (CCI)
In the right tab bar click on "Cache Groups". Order the groups by "Row Count" in descending order. Go through all cache groups with more than 25k rows and check their properties. If the "Refresh Policy" is set to OnDemand (default), then make sure that they have a positive > 0 "Cache Interval". If this is 0, the backend will be polled for every user request putting a lot of load on it. Conversely if CCI is set, it means the cache will be good for that amount of time after each backend request has refreshed it. So the bigger this value, the less your backend will be put under load, but your data will be increasingly less fresh.
Use Coordinated Universal Time On All Servers
This is particularly useful for international projects, but can be considered a general best practice. In order to run a system that produces synchronized log times across different timezones and independent of daylight savings time, we recommend that you switch all servers to Coordinated Universal Time (UTC).