Spark::red SRSD and JIRA will undergo scheduled maintenance Saturday 16-December-2017 1700-2300 UTC. SRSD + JIRA will be unavailable during this window.

For Production outages, please call the support lines 888.666.5582 or +44.870.820.0056

Skip to end of metadata
Go to start of metadata
  • Testing (as of 2015) has shown that 1 JVM per 1 VM is optimal, with 5 physical cores devoted to the VM. Heap size should be 12 GB, with the parallel garbage collector used for new and tenured spaces
  • Ensure that the JDK is supported per Oracle's supported environments matrix. Take note of the FAQThe major version (e.g. 1.6, 1.7) must match what's listed in the matrix, but the minor versions need not match
  • Don't mix and match JDKs between the build environment and the application environment. Ensure the vendor, version and system architecture are all identical.
  • Ensure that thread dumps that have been taken under load show no deadlocks or contention
  • Verify that -Xms and -Xmx are set to the same value and that the values follow the format of "-Xms[n]g or -Xmx[n]m" NOT "-Xms[n]gb or -Xmx[n]mb"
  • Verify that java.rmi.server.hostname is set. This is often required when the instance is to be accessed using the ACC or JRockit Mission Control
  • Verify that garbage collection patterns look healthy during load tests and during soak tests. Restarting instances periodically to alleviate memory issues is not acceptable in a production environment
  • Verify that the objects in the heap look normal when the instance is under load
  • Perform an extended load test (12+ hrs) to look for memory leaks
  • Be sure to remove any duplicate JVM args (e.g. -Xms8g -Xmx8g -Datg.dynamo.liveconfig=on -Xm4g)
  • Do not limit the number of lines in a stack trace via the -XX:MaxJavaStackTraceDepth JVM argument; this will make troubleshooting production issues much more difficult
  • Be sure to write a heap dump in the event of an OutOfMemory error using -XX:+HeapDumpOnOutOfMemoryError. Know where they're written and how to download them

HotSpot JVM

  • Ensure that -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -verbose:gc -Xloggc:<file> is used. These options should stay enabled even in production
  • Make sure that -XX:+DisableExplicitGC is used. This replaces sun.rmi.dgc.server.gcInterval
  • Ensure that -XX:ThreadStackSize=256 or 128. By default, a 64-bit JVM running on Linux allocates 1m per thread
  • If large pages are supported and enabled in the OS, enable with the argument: -XX:+UseLargePages
  • Make sure that -XX:-TraceClassUnloading is not being used. It's only for debugging and adds a lot of overhead
  • Make sure that -XX:+UseTLAB is being used. This has been found to lower CPU utilization by 2.44% with ATG
  • No labels