#Mandatory parameters
# We need to define the benchmark, we need to point out the tarballs
# used to drive the benchmark, this will also point to the binaries
# produced when building the software. We also always need to define
# the MySQL base version to ensure we use the correct parameters in
# various situations.
# We also need to point out where the binaries are placed (and to be
# placed by builds).
# If one want to use a binary tarball one can set
# USE_BINARY_MYSQL_TARBALL to yes.
#
BENCHMARK_TO_RUN="sysbench"
TARBALL_DIR="/Users/mikael/bench/tarballs"
MYSQL_VERSION="mysql-cluster-gpl-7.5.4"
SYSBENCH_VERSION="sysbench-0.4.12.11"
DBT2_VERSION="dbt2-0.37.50.12"
MYSQL_BASE="5.6"
REMOTE_BIN_INSTALL_DIR="/Users/mikael/bench/mysql"
#
# Next comes a number of parameters used to define how to access the
# MySQL Server. This is a required parameter when executing sysbench
# and DBT2 benchmarks. FlexAsynch doesn't need this parameter.
# Here one also needs to define the storage engine which normally
# is NDB, but the scripts also support running benchmarks with InnoDB.
#
SERVER_HOST="127.0.0.1"
SERVER_PORT="3316"
ENGINE="ndb"
#
# We can run either sysbench, dbt2 or flexAsynch benchmarks with these
# benchmark scripts.
# The definition of how to run the benchmark is defined in this
# config file.
#
# ---------------------------------------------------------------
# Common CPU locking of benchmark programs
# ---------------------------------------------------------------
# All benchmark programs can be locked to CPUs.
# We need to set the TASKSET parameter to either taskset or
# numactl to perform this.
# The actual CPUs locked to are set in BENCHMARK_CPUS, for
# taskset it is on the form 0x1234 and for numactl it is on the
# form 0-2,60-62. One can also set BENCHMARK_BIND to decide which
# numa node to get memory from. Finally one can also set
# BENCHMARK_MEM_POLICY to set the memory allocation policy
# (only used by numactl).
#
# ---------------------------------------------------------------
# SYSBENCH configuration section
# ---------------------------------------------------------------
# 
# At first we need to define the benchmark variant to execute.
# We can run seven variants, one sets the variable to yes to
# define the benchmark to execute. RUN_RW defaults to yes all
# other defaults to no.
# RUN_RW: This is the classic Sysbench OLTP RW benchmark
# RUN_RO: This is the classic Sysbench OLTP RO benchmark
# RUN_RO_PS: Run only Point Select queries in OLTP RO benchmark
# RUN_RW_WRITE_INT: Write intensive variant of OLTP RW benchmark
# RUN_RW_LESS_READ: OLTP RW with less reads
# RUN_WRITE: OLTP RW without any reads
# RUN_NONTRX: Special benchmark for all insert/update/...
#
# Each of those benchmark can be affected by the following
# parameters:
# THREAD_COUNTS_TO_RUN: This is a list of the number of threads that wants to
# to be tested with ; as separator.
# NUM_TEST_RUNS: How many times to run the benchmark in a row.
# SYSBENCH_DB: This specifies the database to be used, defaults to sbtest
# SYSBENCH_ROWS: Number of rows to be inserted in prepare phase (Default: 1000000)
# SB_USE_AUTO_INC: Set to yes if auto increment primary key is desired. (Default: no)
# SB_VERBOSITY: Set to yes if more verbose printouts are desired
# SB_MAX_REQUESTS: Set if maximum requests are desired instead of
# maximum time, useful for RUN_NONTRX benchmark variant.
# MAX_TIME: Time to run the execution phase of the benchmark
# SB_DIST_TYPE: Affects algorithm to pick keys (Default: uniform)
# SB_POINT_SELECTS: Affect number of point selects in RUN_RW/RO (Default: 10)
# SB_RANGE_SIZE: Affect range size in RUN_RW/RO (Default: 100)
# SB_SIMPLE_RANGES: Affect number of range scans in RUN_RW/RO (Default: 1)
# SB_SUM_RANGES: Affect number of sum scans in RUN_RW/RO (Default: 1)
# SB_ORDER_RANGES: Affect number of order range scans in RUN_RW/RO (Default: 1)
# SB_DISTINCT_RANGES: Affect number of distinct range scans in RUN_RW/RO (Default: 1)
# SB_USE_IN_STATEMENT: Set to 1 to use IN statement for point selects
#
# SB_NONTRX_MODE: Set to whether to use insert/delete/update_no_key for RUN_NONTRX
#
# SB_USE_MYSQL_HANDLER: Set to yes uses MySQL Handler instead of normal SQL
# SB_USE_SECONDARY_INDEX: Adds a secondary index to all tables
# SB_TX_RATE: Sets specified TX rate rather than simply maximum one
# SB_TX_JITTER: Jitter for TX rate
# SB_NUM_PARTIITONS: Use user-defined partitioning with specified number of partitions
# SB_NUM_TABLES: Number of tables to use in benchmark
# SB_AVOID_DEADLOCKS: Sysbench generates a lot of deadlocked transactions, setting this
# to yes avoids those deadlocks (Default: yes)
# MYSQL_CREATE_OPTIONS can be set to affect --mysql-create-options parameter in call
# to sysbench.
#
# Finally we have also a half-baked version that can be used to run several sysbench
# tests in parallel. To do this one sets BENCH_INSTANCES to the number of parallel
# sysbenchs to run. To be a meaningful test it is also necessary to have a set of
# MySQL Servers to point each test to. We will use round robin to decide which test
# to point at which MySQL Server. In order to run in this variant it is necessary
# define at least as many databases as number of test runs since each sysbench
# run will use a different database.
#
# To give meaningful results it is recommended to set NUM_TEST_RUNS to 1 and also
# to run only for 1 thread count since otherwise the different tests might easily
# become unsynchronized. We don't do any detailed synchronisation between the
# sysbench runs currently.
#
# There are some parameters affecting benchmark execution also:
# BETWEEN_RUNS: This sets the time waited between prepare phase and execution phase.
# It defaults to 5 seconds.
# We also create databases in the beginning of the test, if not successful we retry
# every BETWEEN_CREATE_DB_TEST which defaults to 10 seconds and it is retried up to
# NUM_CREATE_DB_ATTEMPTS which defaults to 18. The normal reason for unsuccessful
# attempts is that the MySQL Server is still starting up.
#
RUN_RW="yes"
THREAD_COUNTS_TO_RUN="64"
NUM_TEST_RUNS="1"
MAX_TIME="90"
#
# ---------------------------------------------------------------
# DBT2 configuration section
# ---------------------------------------------------------------
DBT2_DATA_DIR="/Users/mikael/bench/dbt2_data"
DBT2_WAREHOUSES="64"
DBT2_TIME="90"
#
# DBT2 benchmark has a load phase that requires pre-built CSV files
# The benchmark can both create those files and reads them, the
# DBT2_DATA_DIR specifies where those files are placed and this is
# mandatory.
# We need to specify the maximum number of warehouses used in
# benchmark, this is used to decide how many warehouses to load
# in the beginning of the benchmark. This is more or less
# mandatory to set.
# We need to set the number of threads to use per warehouse
# (called terminals in TPC-C language). TPC-C was designed to use
# 10 per warehouse. However TPC-C was designed for large disk-based
# applications whereas DBT2 is mostly designed for smaller databases
# where the think time is set to 0 instead which means that it is
# very easy to get contention using many threads per warehouse.
# So mostly one sets this to a value between 1 to 3. This is also
# more or less mandatory to set. It is however normally set in
# dbt2_run_1.conf described below.
#DBT2_TERMINALS="1"
# Next we need to define the execution part of the DBT2 benchmark.
# This is normally done in a separate file called dbt2_run_1.conf.
# In this file one describes the number of MySQL Servers to use
# in each test run, how many warehouses to use in this test run
# and how many terminals (threads) to use per warehouse in this
# test run. Multiple test runs can be executed and described in
# this file.
# Here is an example of how this file can look like:
##NUM_MYSQL_SERVERS NUM_WAREHOUSES NUM_TERMINALS
# 1                 1              1
# 2                 2              2
# 4                 4              1
#
# Results from the test run is placed in 3 different directories,
# these are all placed in the same directory as the autobench.conf
# is placed.
# dbt2_logs Here various logs produced are placed
# dbt2_output Here output from benchmark programs are placed
# dbt2_results Here we place the calculated results of the test runs
#
# There is also a set of configuration parameters affecting various
# parts of the DBT2 benchmark.
# DBT2_INTERMEDIATE_TIMER_RESOLUTION this sets the time between
# intermediate reports from the dbt2 program. It is set to 3 by default.
# DBT2_LOADERS this specifies how many parallel loader programs
# that are executed. It defaults to 8, it is important to set this
# high to ensure we don't have to wait for too long, at the same
# time we cannot set it to any value since this will overload the
# REDO log buffer.
# DBT2_PARTITION_FLAG This can be set to HASH or KEY dependent on
# which variant of partitioning that we want to use.
# DBT2_NUM_PARTITIONS This is set to the number of partitions
# wanted, if not set it will adjust to the configuration of
# MySQL Cluster as a normal table is.
# DBT2_PK_USING_HASH_FLAG This is by default set to only use a
# hash index on the primary key. Setting this to nothing means
# that also an ordered index will be used on the primary key.
# FIRST_CLIENT_PORT is set to 30000 and is the port numbers
# used to communicate between DBT2 driver program and the
# DBT2 client program.
# DBT2_TIME is more or less mandatory set, it is the time to use for
# running each instance of the DBT2 benchmark.
# DBT2_SPREAD is used to ensure that each MySQL Server always works
# against the same node group of data nodes. So setting this to
# number of node groups used in benchmark achieves a more or less
# perfect scaling of DBT2.
#
# ---------------------------------------------------------------
# flexAsynch configuration section
# ---------------------------------------------------------------
FLEX_ASYNCH_API_NODES="127.0.0.1;127.0.0.1"
FLEX_ASYNCH_NUM_THREADS="16"
FLEX_ASYNCH_NUM_PARALLELISM="128"
FLEX_ASYNCH_NUM_OPS_PER_TRANS="1"
FLEX_ASYNCH_EXECUTION_ROUNDS="500"
FLEX_ASYNCH_NUM_ATTRIBUTES="2"
FLEX_ASYNCH_ATTRIBUTE_SIZE="1"
FLEX_ASYNCH_NUM_MULTI_CONNECTIONS="1"
FLEX_ASYNCH_EXECUTION_TIMER="60"
FLEX_ASYNCH_WARMUP_TIMER="10"
FLEX_ASYNCH_COOLDOWN_TIMER="10"
# Running flexAsynch requires setting a fair amount of parameters also
# in mandatory setting. This benchmark isn't very standardized, so it
# all depends on what you want to achieve.
# First use FLEX_ASYNCH_API_NODES to define hostnames of where you
# want the flexAsynch programs to execute. The flexAsynch programs
# are started using SSH if not started on localhost or 127.0.0.1.
# Next we need to define number of threads to execute in each
# flexAsynch program using FLEX_ASYNCH_NUM_THREADS.
# Next we need to define parallelism (number of parallel transaction
# in each thread). This is set in FLEX_ASYNCH_NUM_PARALLELISM.
# Next we define the number of operations per transaction. This is
# set in FLEX_ASYNCH_NUM_OPS_PER_TRANS.
# Next we set number of execution rounds for insert and delete part
# of benchmark. This is set in FLEX_ASYNCH_EXECUTION_ROUNDS.
# The total number of rows inserted in one benchmark run is all
# those numbers multiplied by each other. So if we run with 2
# programs, with 16 threads, with 128 parallel transactions and
# 1 operation per transaction and we do 500 rounds then we will
# insert 2 * 16 * 128 * 1 * 500 rows = 2048000 rows.
# The number of attributes in the table is set by setting the
# FLEX_ASYNCH_NUM_ATTRIBUTES.
# The attribute size (in number of 4-byte words) is set in
# FLEX_ASYNCH_ATTRIBUTE_SIZE. There will always be an 8-byte
# primary key as well.
# Finally for the read and update part of the benchmark we will
# define warmup time, execution time and cooldown time. This
# is to ensure that all flexAsynch programs are active when
# we actually execute the execute phase of the benchmark.
# A normal execution of flexAsynch goes through a number of
# phases where we first create the table, then we insert
# the rows, next we update the rows (which rows to update is
# random), next we read rows (which rows to read is random),
# next we delete all rows and finally we drop the table(s).
# To change the execution we can set FLEX_ASYNCH_NO_UPDATE to
# to yes to skip the update part. Similarly we can skip the
# delete phase by setting FLEX_ASYNCH_NO_DELETE, we can skip
# the read phase by setting FLEX_ASYNCH_NO_READ and we can
# skip the drop table part by setting FLEX_ASYNCH_NO_DROP.
#
# We can also end after each phase by setting FLEX_ASYNCH_END_AFTER_CREATE to
# to yes (quit after create table), FLEX_ASYNCH_END_AFTER_INSERT (quit
# after inserts), FLEX_ASYNCH_END_AFTER_UPDATE (quit after updates),
# FLEX_ASYNCH_END_AFTER_READ (quit after reads), FLEX_ASYNCH_END_AFTER_DELETE
# (quit after deletes).
#
# We can use several tables, in this case we will round robin on the tables
# so the primary key will still be unique over all tables. The number of
# tables is set in FLEX_ASYNCH_NUM_TABLES (default 1), we can also use
# a number of ordered indexes, the number of such ordered indexes cannot
# be higher than the number of attributes in the table. This can be set
# using FLEX_ASYNCH_NUM_INDEXES (default 0).
#
# Normally flexAsynch always "guestimates" where the data resides and sends
# the transaction to the proper data node. If one wants to test with round
# robin instead one can set FLEX_ASYNCH_NO_HINT set to yes.
#
# One can affect the parameter how to send in the sendPollNdb call.
# Default is to force a send in this case. This can be set through
# FLEX_ASYNCH_FORCE_FLAG. Default is force, but also adaptive and
# non-adaptive can be used.
#
# We can use Write instead of Insert by setting FLEX_ASYNCH_USE_WRITE to yes.
#
# We can create NOLOGGING tables (no REDO logging or local checkpointing done
# on table). This is done by setting FLEX_ASYNCH_NO_LOGGING to yes.
#
# We can decide to use only operations that are local to our program in some
# sense. By setting FLEX_ASYNCH_USE_LOCAL to 1 we only execute transactions
# against "our" node, setting it to 2 only executes against random node and
# 3 to round robin. This mode isn't extremely useful.
#
# flexAsynch uses a complex thread model to ensure fastest possible execution.
# In this model there are also a number of definer threads. These threads
# needs to generate rows for the execution threads fast enough. The number
# definer threads is set by FLEX_ASYNCH_DEF_THREADS (default 3). Normally
# default is good enough.
#
# The insert process can sometimes cause problems with REDO logs and
# checkpoints, so in some cases where we want to focus on read performance
# we need to insert a few threads at a time. This can be achieved by
# setting TMP_MAX_INSERTERS to the desired number of parallel inserter
# threads.
#
# It is also possible to lock the various thread types in flexAsynch.
# Execution CPUs are set by using FLEX_ASYNCH_EXEC_CPUS, definer threads
# are locked down using FLEX_ASYNCH_DEF_CPUS and finally we can also
# lock the receiver threads (one such for each cluster connection)
# using FLEX_ASYNCH_RECV_CPUS.
#
# ---------------------------------------------------------------------------
# Build process
# ---------------------------------------------------------------------------
# 
# If we build the software from a source tarball then we need to set a
# a number of parameters for the build process.
#
# Set STATIC_LINKING_FLAG to yes if static linking is desired
# Set DEBUG_FLAG to no if no debug symbols are wanted in the binary
# Set WITH_DEBUG to --with-debug if debug build is desired
# Default compiler is gcc, other allowed values are open64, icc, forte
# Set LINK_TIME_OPTIMIZER to "yes" if interprocedural optimisations are desired
# For Open64 compiler one can set --mso to get multi-core scalability
# optimisations. Set MSO_FLAG to "yes" to get this.
# Set USE_FAST_MYSQL to no to not get most optimal compiler options
# Set COMPILE_SIZE_FLAG to --32 or --64 if specifically want a 32 or 64-bit build
# Set WITH_PERFSCHEMA_FLAG to yes to compile with performance schema
# Set FEEDBACK_COMPILATION to yes to enable feedback compilation
#
# After building the software the next step is to generate the internal
# benchmark config files and also the NDB config file. These are all
# generated and saved in the same directory where the autobench.conf
# is placed.
# We will create one file called iclaustron.conf that is used by
# all scripts to define variables in the scripts.
# We will create a file called dbt2.conf for use in executing DBT2
# benchmarks. This also defines variables for the scripts used to
# execute the benchmark.
# We will create a file called sysbench.conf for use in executing
# sysbench benchmarks. This is also used to define variables for
# scripts that execute the sysbench benchmark.
# We will create 
#
# We can run against an existing cluster with all MySQL Servers and NDB
# management server and NDB data node already up and running. In this
# case the next section isn't needed. In this case if we run flexAsynch
# we still need to define the host of the NDB manangement server and
# the NDB management server port.
# Normal operation for a benchmark is however to also start and stop
# cluster from these benchmark scripts.
# In this case we need to define settings for first NDB management
# server.
# Set NDB_MGMD_PORT to port number unless default 1186 is used.
NDB_MGMD_NODES="127.0.0.1"
#
# One setting which is common to all nodes is that we can set
# CORE_FILE_USED to yes if we want to produce a core file when
# a crash occurs.
# 
# Another common parameter is DATA_DIR_BASE. This is where the MySQL
# Server and NDB data node and also NDB management server place their
# files.
#
# -----------------------------------------------------
# Define the settings for MySQL Server
# -----------------------------------------------------
# We first need to set the host names and port numbers of the MySQL
# Servers, this was however covered already above. This also included
# setting the storage engine used when creating tables.
# For the MySQL Server we set all parameters as command line
# parameters, so all parameter settings for started MySQL Servers
# comes from settings in autobench.conf.
#
# An important parameter for the MySQL Server is to set a specific
# Malloc library. To use such a specific one sets USE_MALLOC_LIB to
# yes, the reference to the Malloc library is put in MALLOC_LIB.
# There is a scalability hog in in modern jemalloc versions. This
# can be handled by setting PREPARE_JEMALLOC to yes. So for best
# performance we set USE_MALLOC_LIB and PREPARE_JEMALLOC to yes
# and in our case we set MALLOC_LIB to /usr/local/lib/libjemalloc.so.1
#
# There is a few common MySQL Server parameters settable:
# KEY_BUFFER_SIZE (defaults to 50M)
# MAX_HEAP_TABLE_SIZE (defaults to 1000M)
# SORT_BUFFER_SIZE (defaults to 32768)
# TMP_TABLE_SIZE (defaults to 100M)
# MAX_TMP_TABLES (defaults to 100)
# TABLE_CACHE_SIZE (defaults to same default as MySQL Server)
# this is used to set both table_open_cache and table_definition_cache.
# TABLE_CACHE_INSTANCES (defaults to 16)
#
# MySQL Server started through the benchmark always sets
# --skip-grant-tables. If not wanted one can set the variable
# GRANT_TABLE_OPTION to empty.
#
# It is also possible to set transaction-isolation by setting
# it in the variable TRANSACTION_ISOLATION.
#
# query-cache-size is always set to 0, query_cache_type is also set to 0
# and temp-pool is also set to 0. max_prepared_stmt is set to 1048576.
#
# One can set metadata_locks_cache_size by setting META_DATA_CACHE_SIZE
# in which case we set metadata_locks_hash_instances to 16.
# 
# One can set max_connections by setting MAX_CONNECTIONS, default it
# is 1000.
# We set language to english.
#
# When starting the MySQL Server we start it using SSH unless we are
# using localhost or 127.0.0.1 in which case we start it on local
# server.
#
# We can set USE_LARGE_PAGES to yes to set large_pages. We can set
# LOCK_ALL to yes to set memlock config parameter.
#
# There is also a set of specific MySQL Server config parameters
# only used with NDB storage engine.
# We can set ENGINE_CONDITION_PUSHDOWN to yes to enable condition
# pushdown. ndb_autoincrement_prefetch_sz is set through
# NDB_AUTOINCREMENT_OPTION, it defaults to 256.
#
# In 7.5 we also can use NDB_READ_BACKUP set to yes to set ndb_read_backup
# also NDB_FULLY_REPLICATED to yes to set ndb_fully_replicated and we can
# set NDB_DATA_NODE_NEIGHBOUR to set ndb_data_node_neighbour. We set
# ndb_default_column_format to fixed and to set it to DYNAMIC we can
# NDB_DEFAULT_COLUMN_FORMAT to DYNAMIC.
#
# A very important parameter for benchmarks is NDB_MULTI_CONNECTION which
# is used to set ndb_cluster_connection_pool, this is the number of
# API nodes used by the MySQL Server to connect to the cluster.
#
# We can also set ndb_recv_thread_activation_threshold and also
# ndb_recv_thread_cpu_mask through NDB_RECV_ACTIVATION_THRESHOLD
# and NDB_RECV_THREAD_CPU_MASK.
#
# We always set ndb_use_exact_count to to 0 and we always set
# ndb_use_transactions to 1 and we set ndb_force_send to 1 unless
# we set NDB_FORCE_SEND to no. We never enable index statistics
# through setting ndb_index_stat_enable to 0.
# We always ndb_extra_logging to 0 and we set the new parameter
# to enable user defined partitioning for NDB tables.
#
# We can also run with thread pool plugin set through setting
# THREADPOOL_SIZE to set thread_pool_size, it is also possible
# to set THREADPOOL_ALGORITHM, THREADPOOL_STALL_LIMIT and
# THREADPOOL_PRIO_KICKUP_TIMER.
#
# All other MySQL Server parameters are set to their default value.
#
# We can also lock the MySQL Server using either taskset or using
# numactl.
#
# With taskset set in TASKSET then one sets the CPUs to lock it to
# in SERVER_CPUS (in the form 0x1234).
#
# With numactl set in TASKSET we set the CPUs to lock to in
# SERVER_CPUS (in the form 0-2,60-62).
#
# With numactl we can also set SERVER_BIND to numa node to lock
# memory to and we can set SERVER_MEM_POLICY.
#
# Setting TASKSET to empty means no CPU locking of MySQL Server.
#
# That concludes the settings possible for the MySQL Server.
# There is also a wide set of options available to set for InnoDB
# when running tests with InnoDB as storage engine, we will here
# however focus on running with NDB as storage engine.
#
# ----------------------------------------------------------
# Definition of configuration of NDB data nodes.
# ----------------------------------------------------------
# We also generate a configuration file for NDB.
# This sets up the proper number of data nodes, management servers
# and API nodes.
# At first we need to define the hostnames of the NDB data nodes.
# We also need to define the number of replicas desired in the
# cluster. This is set by setting NDB_REPLICAS which sets NoOfReplicas in config.
NDBD_NODES="127.0.0.1;127.0.0.1"
NDB_REPLICAS="2"
#
# It is possible write your own config.ini-file, in this case call
# it config_c1.ini and place it next to autobench.conf, this file
# is generated otherwise. After generating it is possible to manually
# change this file to update the config.
#
# The normal is to use ndbmtd as binary for data nodes, to use ndbd
# instead set USE_NDBMTD to no.
#
# We generate node ids for all nodes defined in the config.
# We start at 1 for management servers, then we add one for
# each new node, after management servers we define the data
# nodes and then last the API/MySQL Server nodes.
# The number of API nodes is the number of MySQL Server nodes
# multiplied by the number of cluster connections per
# MySQL Server plus one for debug usage.
#
# The following parameters are possible to change for send/receive
# ................................................................
# NDB_SEND_BUFFER_MEMORY (Default SendBufferMemory=2M)
# NDB_RECEIVE_BUFFER_MEMORY (Default ReceiveBufferMemory=2M)
# NDB_TOTAL_SEND_BUFFER_MEMORY (Default TotalSendBufferMemory not set)
# NDB_TCP_SEND_BUFFER_MEMORY (Default TCP_SND_BUF_SIZE not set)
# NDB_TCP_RECEIVE_BUFFER_MEMORY (Default TCP_RCV_BUF_SIZE not set)
# NDB_EXTRA_SEND_BUFFER_MEMORY (Default ExtraSendBufferMemory=16M)
# NDB_MAX_SEND_DELAY (Default MaxSendDelay not set)
#
# The following parameters are possible to set for CPU locking
# ............................................................
# We can set LockExecuteThreadToCPU for each data node separately
# by setting NDB_EXECUTE_CPU. As usual in cases like these we
# can use lists by separating each node specification by ;
# Only one specification can also be given in which case this is
# used for all nodes.
# Similarly we can set LoCkMaintThreadsToCPU through
# NDB_MAINT_CPU.
# Similarly we can also set MaxNoOfExecutionThreads through setting
# NDB_MAX_NO_OF_EXECUTION_THREADS.
# Finally we can also set ThreadConfig for each node in a similar
# manner using NDB_THREAD_CONFIG.
#
# The following parameters affect Local Checkpoint execution and REDO log handling
# ................................................................................
# FragmentLogFileSize is set to 256M
# DiskSyncSize is set to 32M
# BackupWriteSize is set to 512k
# BackupLogBufferSize is set to 2M
# BackupDataBufferSize is set to 1M
# InitFragmentLogFiles is set to full
# NDB_COMPRESSED_LCP (Default CompressedLcp=0)
# NDB_NO_OF_FRAGMENT_LOG_FILES (Default NoOfFragmentLogFiles=15)
# NDB_FRAGMENT_LOG_PARTS (Default NoOfFragmentLogParts not set)
# NDB_REDO_BUFFER (Default RedoBuffer=64M)
# NDB_TIME_BETWEEN_LOCAL_CHECKPOINTS (Default TimeBetweenLocalCheckpoints not set)
# DISK_CHECKPOINT_SPEED (Default DiskCheckpointSpeed not set) only 7.3 and earlier
# The next set is only 7.4 and upwards
# NDB_MIN_DISK_WRITE_SPEED (Default MinDiskWriteSpeed not set)
# NDB_MAX_DISK_WRITE_SPEED (Default MaxDiskWriteSpeed not set)
# NDB_MAX_DISK_WRITE_SPEED_OTHER_NODE_RESTART (Default MaxDiskWriteSpeedOtherNodeRestart)
# NDB_MAX_DISK_WRITE_SPEED_OWN_NODE_RESTART (Default MaxDiskWriteSpeedOwnNodeRestart)
#
# The following parameters affect the scheduling in OS and internally in NDB
# ..........................................................................
# NDB_REALTIME_SCHEDULER (Default RealtimeScheduler not set)
# NDB_SCHEDULER_RESPONSIVENESS (Default SchedulerResponsiveness not set) 7.4 and onwards
# NDB_SCHED_SCAN_PRIORITY (Default __sched_scan_priority not set) 7.4 and onwards
# NDB_SCHEDULER_SPIN_TIMER (Default SchedulerSpinTimer=0)
#
# The following parameters are also set
# .....................................
# BatchSizePerLocalScan is set to 128
# MaxBufferedEpochs is set to 500
# RedoOverCommitLimit is set to 45
# Numa is set to 1
# TransactionDeadlockDetectionTimeout is set to 10000 (measured in milliseconds)
# NDB_TIME_BETWEEN_WATCHDOG_CHECK_INITIAL (Default TimeBetweenWatchDogCheckInitial=180000)
#
# The following parameters set the memory sizes for data storage
# ..............................................................
# NDB_DATA_MEMORY (Default DataMemory=3G)
# NDB_INDEX_MEMORY (Default IndexMemory=300M)
# NDB_DISK_PAGE_BUFFER_MEMORY (Default DiskPageBufferMemory=1G)
#
# The following parameters affect various internal pool sizes
# ...........................................................
# LongMessageBuffer is set to 128M
# NDB_MAX_NO_OF_CONCURRENT_TRANSACTIONS (Default MaxNoOfConcurrentTransactions=131072)
# NDB_MAX_NO_OF_CONCURRENT_OPERATIONS (Default MaxNoOfConcurrentOperations=131072)
# NDB_MAX_NO_OF_CONCURRENT_SCANS (Default MaxNoOfConcurrentScans=500)
# NDB_MAX_NO_OF_LOCAL_SCANS (Default MaxNoOfLocalScans=8000)
#
# The following parameters affect disk handling
# .............................................
# NDB_DISKLESS (Default Diskless not set)
# USE_NDB_O_DIRECT set to yes => ODirect=1
# NDB_DISK_IO_THREADPOOL (Default DiskIOThreadPool not set)
#
# Setting NDB_LOG_LEVEL sets all LogLevelX config parameters to this level.
#
# The following parameters are set on API nodes
# .............................................
# BatchSize on API nodes set to 128
# DefaultOperationRedoProblemAction set to abort
