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?
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.
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.
Regards,Alain Krikilion No PM,please use the forum. || May the <SOLVED>-attribute be in your title!
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...
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?
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.
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.
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.
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)
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.
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.
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.
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.
Regards,Alain Krikilion No PM,please use the forum. || May the <SOLVED>-attribute be in your title!
Comments
run --> MMC from the start menu
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book
http://www.BiloBeauty.com
http://www.autismspeaks.org
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.
No PM,please use the forum. || May the <SOLVED>-attribute be in your title!
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...
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.
Are we talking about the same thing?
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?
http://www.mergetool.com/PerformanceReport-Compaq.pdf
http://www.BiloBeauty.com
http://www.autismspeaks.org
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.
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)
http://www.BiloBeauty.com
http://www.autismspeaks.org
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.
http://h20000.www2.hp.com/bc/docs/suppo ... 257513.pdf
I apologize for the hi-jacking of this thread O:)
http://www.BiloBeauty.com
http://www.autismspeaks.org
No PM,please use the forum. || May the <SOLVED>-attribute be in your title!
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.
No PM,please use the forum. || May the <SOLVED>-attribute be in your title!