Increase Commit Cache

theholysyruptheholysyrup Member Posts: 11
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?

Comments

  • themavethemave Member Posts: 1,058
    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
  • kinekine Member Posts: 12,562
    Commit cache can be just Enabled/Disabled, you can change only DBMS Cache...
    Kamil Sacek
    MVP - Dynamics NAV
    My BLOG
    NAVERTICA a.s.
  • theholysyruptheholysyrup Member Posts: 11
    Can the DBMS cache size be changed anywhere other thatn during Server setup?
  • Alex_ChowAlex_Chow Member Posts: 5,063
    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.
  • SavatageSavatage Member Posts: 7,142
    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 :wink:
  • krikikriki Member, Moderator Posts: 9,116
    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!


  • kinekine Member Posts: 12,562
    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...
    Kamil Sacek
    MVP - Dynamics NAV
    My BLOG
    NAVERTICA a.s.
  • ajhvdbajhvdb Member Posts: 672
    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?
  • bbrownbbrown Member Posts: 3,268
    Commit Cache uses a portion of the DBMS cache. It can dynamically use up to 2/3 of the DBMS cache.
    There are no bugs - only undocumented features.
  • ajhvdbajhvdb Member Posts: 672
    ..and you only set Commit cache to ON if your database has more then one physical part.
  • bbrownbbrown Member Posts: 3,268
    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?
    There are no bugs - only undocumented features.
  • ajhvdbajhvdb Member Posts: 672
    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.
  • SavatageSavatage Member Posts: 7,142
    edited 2006-05-26
    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.
  • bbrownbbrown Member Posts: 3,268
    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.
    There are no bugs - only undocumented features.
  • SavatageSavatage Member Posts: 7,142
    edited 2006-07-07
    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)
  • bbrownbbrown Member Posts: 3,268
    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.
    There are no bugs - only undocumented features.
  • ajhvdbajhvdb Member Posts: 672
    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.
  • bbrownbbrown Member Posts: 3,268
    Don't confuse having a UPS with having a battery-backed RAID controller, they do not offer the same type of protection.
    There are no bugs - only undocumented features.
  • SavatageSavatage Member Posts: 7,142
    edited 2006-05-27
    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:)
  • bbrownbbrown Member Posts: 3,268
    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.
    There are no bugs - only undocumented features.
  • krikikriki Member, Moderator Posts: 9,116
    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.
    Regards,Alain Krikilion
    No PM,please use the forum. || May the <SOLVED>-attribute be in your title!


  • DeSpDeSp Member Posts: 105
    Should we use the Commit Cache with Navision SQL Option?
    What is the best value for Object Cache?
    Nil desperandum
  • krikikriki Member, Moderator Posts: 9,116
    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.
    Regards,Alain Krikilion
    No PM,please use the forum. || May the <SOLVED>-attribute be in your title!


Sign In or Register to comment.