Limit memory usage on Win7 x64

[Former Member]

We've migrate production machines some month back from Windows XP x86 to Windows 7 x64. It turnes out that the -ch parameter isn't being applied correctly in the new environment.

ODBC startup line: dbeng11.exe -ch 600M

Environement variable Path: %SystemRoot%system32;%SystemRoot%;%SystemRoot%System32Wbem;%SYSTEMROOT%System32WindowsPowerShellv1.0;C:Program Files (x86)NovellZENworksbin;C:Program Files (x86)Enterprise VaultEVClient;C:Program FilesSQL Anywhere 11bin64;C:Program FilesSQL Anywhere 11bin32;C:Program FilesTortoiseSVNbin

As the startup line specifies a relative path for dbeng11.exe, the 64bit version is being used as specified by the Path variable.

Issue: When running the x64 SQL Anywhere version, the memory limitation doesn't work. The dbeng11.exe process uses all the memory available to the system (>5GB), whereas when running the 32bit version (dbeng11.exe*32), it uses max ~630MB (whish is fine).

Is this a bug or do we have to configure another parameter?

IAnywhere Console after starting the 32bit version on a development machine:

SQL Anywhere Personal Server Version 11.0.1.2472

Developer edition, not licensed for deployment.

Copyright © 2001-2009, iAnywhere Solutions, Inc.
Portions copyright © 1988-2009, Sybase, Inc. All rights reserved.
Use of this software is governed by the Sybase License Agreement. Refer to http://www.sybase.com/softwarelicenses

8 logical processor(s) on 1 physical processor(s) detected.
Processor limit (Personal Server😞 1
Maximum number of physical processors the server will use: 1
This server is licensed to:
    Developer Edition
    Restricted Use
Running Windows 7 Build 7601 Service Pack 1 on X86_64
Server built for X86 processor architecture
614400K of memory used for caching
Minimum cache size: 2048K, maximum cache size: 614400K
Using a maximum page size of 8192 bytes
Database server started at Mon Oct 08 2012 11:16
Trying to start SharedMemory link ...
    SharedMemory link started successfully
Trying to start TDS (TCPIP) link ...
Starting on port 2638
    TDS (TCPIP) link started successfully
Now accepting requests
Starting database "RegressionTest_LD_V2" (C:\\VibroSight Data\\RegressionTest_LD_V2\\RegressionTest_LD_V2.db) at Mon Oct 08 2012 11:16
Starting checkpoint of "RegressionTest_LD_V2" (RegressionTest_LD_V2.db) at Mon Oct 08 2012 11:16
Finished checkpoint of "RegressionTest_LD_V2" (RegressionTest_LD_V2.db) at Mon Oct 08 2012 11:16
Database "RegressionTest_LD_V2" (RegressionTest_LD_V2.db) started at Mon Oct 08 2012 11:16
Performance warning: Server cache size is too small for database "RegressionTest_LD_V2"

IAnywhere Console after starting the 64bit version on a development machine:

SQL Anywhere Personal Server Version 11.0.1.2472

Developer edition, not licensed for deployment.

Copyright © 2001-2009, iAnywhere Solutions, Inc.
Portions copyright © 1988-2009, Sybase, Inc. All rights reserved.
Use of this software is governed by the Sybase License Agreement. Refer to http://www.sybase.com/softwarelicenses

8 logical processor(s) on 1 physical processor(s) detected.
Processor limit (Personal Server😞 1
Maximum number of physical processors the server will use: 1
This server is licensed to:
    Developer Edition
    Restricted Use
Running Windows 7 Build 7601 Service Pack 1 on X86_64
Server built for X86_64 processor architecture
614400K of memory used for caching
Minimum cache size: 2048K, maximum cache size: 614400K
Using a maximum page size of 8192 bytes
Database server started at Mon Oct 08 2012 11:20
Trying to start SharedMemory link ...
    SharedMemory link started successfully
Trying to start TDS (TCPIP) link ...
Starting on port 2638
    TDS (TCPIP) link started successfully
Now accepting requests
Starting database "RegressionTest_LD_V2" (C:\\VibroSight Data\\RegressionTest_LD_V2\\RegressionTest_LD_V2.db) at Mon Oct 08 2012 11:20
Starting checkpoint of "RegressionTest_LD_V2" (RegressionTest_LD_V2.db) at Mon Oct 08 2012 11:20
Finished checkpoint of "RegressionTest_LD_V2" (RegressionTest_LD_V2.db) at Mon Oct 08 2012 11:20
Database "RegressionTest_LD_V2" (RegressionTest_LD_V2.db) started at Mon Oct 08 2012 11:20
Performance warning: Server cache size is too small for database "RegressionTest_LD_V2"

Both x86 and x64 startup parameters are the same. According to the console output they seem to be read correctly, but when running hte x64, the memory grows indefinitely.

[johnsmirnios · Accepted solution]

Both servers seem to be accepting the maximum cache size correctly: Minimum cache size: 2048K, maximum cache size: 614400K

How far beyond 600MB have you seen the memory usage go to? What value are you actually looking at to get the memory usage?

If memory usage grows without bound, it's possible you are running in to a bug that is a leak outside of the cache. It can be caused by the server itself or, sometimes, by user-defined external stored procedures. I would recommend applying the latest v11 EBF and see if you still run into the problem.

[Former Member · Accepted solution]

Thanks, updating to 11.0.1.2867 solved the memory usage problem. When using the x64 version, the memory remains constant at ~630MB when setting the 600M limit. There must have been a bug fix between 2472-2867.

As for your question about how high it goes, the memory increased until the used memory by the system reached 7GB out of the available 8GB. If other processes required a lot of memory it didn't go as high as if it was the only process using memory. It seems the formula to use 90% of the available memory (for which I can't the reference anymore) was being applied.

[VolkerBarth · Accepted solution]

Here's the quote (from the v12.0.1 docs):

-ch dbeng12/dbsrv12 server option

This option limits the size of the database server cache during automatic cache growth. By default the upper limit is approximately the lower of the maximum non-AWE cache size and 90% of the total physical memory of the computer.

[johnsmirnios · Accepted solution]

That 90% you are seeing is probably not related to the 90% in the -ch documentation. If you are looking at the memory size in Task Manager, it is just the process's working set and it cannot exceed available memory. To look for leaks, you really want to look at Process/Virtual Bytes in Perfmon.