Increase Commit Cache

theholysyrup

We recently upgraded the RAM on our Navision server. Is there a way to change (increase) the size of the Commit Cache, without reinstalling the server?

themave

on the server the setting can be changed by opening the microsoft managment console and changing the setting their.

run --> MMC from the start menu

kine

Commit cache can be just Enabled/Disabled, you can change only DBMS Cache...

theholysyrup

Can the DBMS cache size be changed anywhere other thatn during Server setup?

Alex_Chow

The commit cache has been increased in Navision 4.0 to 32,000kb. Whereas any version of Navision prior to 4.0 was only 8,000kb.

Savatage

Tommy Schou wrote:

Sounds odd!

I have heard somewhere (I think) that you should not use 1GB as a cache size. Sorry I cannot substantiate it a bit more but I would recommed you try and lower it to ie. 850mb just to try it out.

Changing the cache size should be easy enough and you have tried everything it seems so I don't really have a clue what is wrong with your installation but I would try

Server.exe uninstallasservice

followed by

server.exe <all your parameters incl. new cache size> WITHOUT installasservice just to see if you can start the server.exe in a command-prompt. If it won't start.. maybe it will tell you why.

If it starts ok then just stop it and do a

server.exe installasservice

Then it should work.

Good luck

kriki

theholysyrup wrote:

Can the DBMS cache size be changed anywhere other thatn during Server setup?

Yes, stop the service. Open the properties of the service.
In it you will see a field "Start parameter". Put in this field the parameters you want to change. In your case this could be "CACHE=800000". And start the service from the properties.

kine

Or use the Navision Server MMC Snapin to change the value... :-)

The commit cache has been increased in Navision 4.0 to 32,000kb. Whereas any version of Navision prior to 4.0 was only 8,000kb.

Commit cache is just Enabled/Disabled. You can change only Object cache (on client) or DBMS cache (on client - if one user mode - else on server). Commit cache is part of the DBMS cache...

ajhvdb

Yes correct. Where did you get this info on 32,000kb. I thought the maximum dbms cache was 1000Kb but if that didn't work use 800Kb. :?
Are we talking about the same thing?

bbrown

Commit Cache uses a portion of the DBMS cache. It can dynamically use up to 2/3 of the DBMS cache.

ajhvdb

..and you only set Commit cache to ON if your database has more then one physical part.

bbrown

ajhvdb wrote:

..and you only set Commit cache to ON if your database has more then one physical part.

Can you elaborate on this statement?

Commit Cache is a write cache managed by the Navision DB Server service. Why would the number of database parts (files) make a difference?

ajhvdb

I learned to set "commit cache" to enable only if the database is splitup into different parts. F:\DB-Part1.fdb, G:\DB-Part2.fdb, etc. I think a got this info from mbsonline. Can't check it because the site doesn't work now.

Savatage

Here is a great explanation of the commit cache on page 10

http://www.mergetool.com/PerformanceReport-Compaq.pdf

The Commit Cache

The Commit Cache is a special write buffer storage for the disk(s) in your system.
The Commit Cache has been designed to:
Quickly absorb committed transaction from the DBMS. This frees the DBMS for other tasks:

Enable asynchronous disk writes
Enable parallel disk writes when using multiple disks
Guarantee that the disk file always is consistent

The Commit Cache is placed between the DBMS and the database, and absorbes committed transactions from the DBMS. When the Commit Cache has received a committed transaction, it takes care of writing the data to the disk(s). In this way the DBMS is free to perform other tasks while data is being written to the disk. The data is said to be written asynchronously to the disk, as the time for the disk write is independent of the time when the transaction was committed by the DBMS. When using more than one disk, each of these disks are controlled by a separated commit cache process, which are linked to each other in order to enable and control (asynchronous) parallel write operations.

The Commit Cache always guarantees that data is written to the disk in the same sequence as the data is sent to the Commit Cache. This assures that the database file always is consistent. The database file is consistent, even if a power failure should occur during a write operation to the disk. However, the data which is currently in the Commit Cache memory when a power failure occurs, is lost, and must be re-entered via the NAVISION user interface.

bbrown

I learned to set "commit cache" to enable only if the database is splitup into different parts

I would definitely question that information. Commit Cache is a feature of the Navision DBMS cache. The number of database parts has no bearing on the behavior of the cache.

Savatage

Savatage wrote:

Here is a great explanation of the commit cache on page 10

http://www.mergetool.com/PerformanceReport-Compaq.pdf

The Commit Cache

The Commit Cache is a special write buffer storage for the disk(s) in your system.
The Commit Cache has been designed to:
Quickly absorb committed transaction from the DBMS. This frees the DBMS for other tasks:

Enable asynchronous disk writes
Enable parallel disk writes when using multiple disks
Guarantee that the disk file always is consistent

The Commit Cache is placed between the DBMS and the database, and absorbes committed transactions from the DBMS. When the Commit Cache has received a committed transaction, it takes care of writing the data to the disk(s). In this way the DBMS is free to perform other tasks while data is being written to the disk. The data is said to be written asynchronously to the disk, as the time for the disk write is independent of the time when the transaction was committed by the DBMS. When using more than one disk, each of these disks are controlled by a separated commit cache process, which are linked to each other in order to enable and control (asynchronous) parallel write operations.

The Commit Cache always guarantees that data is written to the disk in the same sequence as the data is sent to the Commit Cache. This assures that the database file always is consistent. The database file is consistent, even if a power failure should occur during a write operation to the disk. However, the data which is currently in the Commit Cache memory when a power failure occurs, is lost, and must be re-entered via the NAVISION user interface.

Even tho it's kinda old - this pdf has some interesting info on benchmark tests. I'm sure it's still in the ballpark.

For example the performance scale

Split database from 1 to 2 disks Performance Increase additional %100
Split database from 2 to 3 disks Performance Increase additional %52
Split database from 3 to 4 disks Performance Increase additional %30.6
Split database from 4 to 5 disks Performance Increase additional %21
Split database from 5 to 6 disks Performance Increase additional %10.8

so I guess if you compare a 1 disk to a 6 disk system there is a %214.4 speed increase.

The other interesting benchmark is the Raid 1 vs. Raid 5 (for those using raid 5)

bbrown

Great document!

What I get from the document, is that navision will use a separate Commit Cache process for each database part. If you have only 1 part it will run 1 commit cache process. So I see this would be helpful even with only 1 database part.

A comment about Compaq SmartArray:

Yes, it is true that the Compaq SmartArray controllers have battery backup for their hardware cache (not all models - optional on some), but before deciding to turn on hardware write cache consider the following. If using Compaq's top line RAID controller (SMART-6404) with the maximum cache, the battery backup is rated to maintain memory for 24 hours. This means that if you suffer a controller failure, you must replace within 24 hours.

Decreasing the memory will increase battery life.

ajhvdb

Yes thx for the info, from reading the document; setting commit cache to enable should speed things up (in practice never noticed it) but you must have a ups for the server or battery on the controller.

bbrown

Don't confuse having a UPS with having a battery-backed RAID controller, they do not offer the same type of protection.

Savatage

Advantages of battery-backed up cache

http://h20000.www2.hp.com/bc/docs/suppo ... 257513.pdf

I apologize for the hi-jacking of this thread O:)

bbrown

Yes, RAID controllers with battery-backed write-cache are a wonderful thing. Just have a service contract in place, so you can get the controller replaced before the battery dies.

kriki

bbrown wrote:

I learned to set "commit cache" to enable only if the database is splitup into different parts

I would definitely question that information. Commit Cache is a feature of the Navision DBMS cache. The number of database parts has no bearing on the behavior of the cache.

Exactly: ALWAYS use the commit cache! Otherwise you will have a VERY slow Navision-installation.

DeSp

Should we use the Commit Cache with Navision SQL Option?
What is the best value for Object Cache?

kriki

DeSp wrote:

Should we use the Commit Cache with Navision SQL Option?

With SQL, there is no such thing as Commit cache. Everything is handled by the SQL-server.

DeSp wrote:

What is the best value for Object Cache?

In general:take the default one. That is good enough. Only in case you have a lot of (or big) single instance codeunits, you might increase the value.