mirror of https://github.com/OpenIdentityPlatform/OpenDJ.git

Matthew Swift
20.44.2013 367dcd841167d003ac172edafd05b843d10ef8ee
Fix OPENDJ-943: Replication purge of changelogDb fails to keep up with changes

* use a larger DB cache (16MB vs 5MB) when using larger DB buffers
1 files modified
43 ■■■■■ changed files
opends/src/server/org/opends/server/replication/server/ReplicationDbEnv.java 43 ●●●●● patch | view | raw | blame | history
opends/src/server/org/opends/server/replication/server/ReplicationDbEnv.java
@@ -87,25 +87,40 @@
    envConfig.setConfigParam("je.cleaner.threads", "2");
    envConfig.setConfigParam("je.checkpointer.highPriority", "true");
    // If the JVM is reasonably large then we can safely default to
    // bigger read buffers. This will result in more scalable checkpointer
    // and cleaner performance.
    /*
     * Tests have shown that since the parsing of the Replication log is always
     * done sequentially, it is not necessary to use a large DB cache.
     */
    if (Runtime.getRuntime().maxMemory() > 256 * 1024 * 1024)
    {
      envConfig.setConfigParam("je.cleaner.lookAheadCacheSize", String
          .valueOf(2 * 1024 * 1024));
      /*
       * If the JVM is reasonably large then we can safely default to bigger
       * read buffers. This will result in more scalable checkpointer and
       * cleaner performance.
       */
      envConfig.setConfigParam("je.cleaner.lookAheadCacheSize",
          String.valueOf(2 * 1024 * 1024));
      envConfig.setConfigParam("je.log.iteratorReadSize", String
          .valueOf(2 * 1024 * 1024));
      envConfig.setConfigParam("je.log.iteratorReadSize",
          String.valueOf(2 * 1024 * 1024));
      envConfig.setConfigParam("je.log.faultReadSize", String
          .valueOf(4 * 1024));
      envConfig
          .setConfigParam("je.log.faultReadSize", String.valueOf(4 * 1024));
      /*
       * The cache size must be bigger in order to accommodate the larger
       * buffers - see OPENDJ-943.
       */
      envConfig
          .setConfigParam("je.maxMemory", String.valueOf(16 * 1024 * 1024));
    }
    // Tests have shown that since the parsing of the Replication log is always
    // done sequentially, it is not necessary to use a large DB cache.
    // Use 5M so that the replication can be used with 64M total for the JVM.
    envConfig.setConfigParam("je.maxMemory", "5000000");
    else
    {
      /*
       * Use 5M so that the replication can be used with 64M total for the JVM.
       */
      envConfig.setConfigParam("je.maxMemory", String.valueOf(5 * 1024 * 1024));
    }
    // Since records are always added at the end of the Replication log and
    // deleted at the beginning of the Replication log, this should never