Documentation > Configuration > Properties File > Site Parameters

System & Environment Parameters

  • site.jvm_asserts
    Default: false
    Permitted Tye: boolean
    Execute each HStoreSite with JVM asserts enabled. This should be set to false when running benchmark experiments.
  • site.memory
    Default: 2048
    Permitted Tye: int
    The amount of memory to allocate for each site process (in MB)
  • site.preload
    Default: true
    Permitted Tye: boolean
    When enabled, the HStoreSite will preload objects when the system is started. This should only be disabled for regression test cases.
  • site.profiling
    Default: false
    Permitted Tye: boolean
    Enable profiling for the HStoreSite. This data can be retrieved using the @Statistics sysproc.


Debug Logging Parameters

  • site.log_dir
    Default: global.log_dir/sites
    Permitted Tye: string
    HStoreSite log directory on the host that the BenchmarkController is invoked from.
  • site.log_backup
    Default: false
    Permitted Tye: boolean
    Whether to back-up log files before the benchmark is exceuted


CPU Affinity Parameters

  • site.cpu_affinity
    Default: true
    Permitted Tye: boolean
    When enabled, the PartitionExecutor threads will be pinned to the first n CPU cores (where n is the total number of partitions hosted by the local HStoreSite). All other threads (e.g., for network handling) will be pinned to the remaining CPU cores. If there are fewer CPU cores than partitions, then this option will be disabled.
  • site.cpu_affinity_one_partition_per_core
    Default: true
    Permitted Tye: boolean
    When used in conjunction with site.cpu_affinity, each PartitionExecutor thread will be assigned to one and only CPU core. No other thread within the HStoreSite (including all other PartitionExecutors) will be allowed to execute on that core. This configuration option is mostly used for debugging and is unlikely to provide any speed improvement because the operating system will automatically maintain CPU affinity.
  • site.cpu_partition_blacklist Experimental
    Default: 0
    Permitted Tye: string
    Comma-separated list of CPU Ids (starting at zero) that the PartitionExecutors should not be scheduled to execute on. This is used whenever we need to doscaling experiments and want to avoid hyper-threading cores. We will always avoid executing on the first CPU by default because that’s where the JVM likes to execute system threads.
  • site.cpu_utility_blacklist Experimental
    Default: null
    Permitted Tye: string
    Comma-separated list of CPU Ids (starting at zero) that the HStoreSite’s utility should not be scheduled to execute on. This is used whenever we need to doscaling experiments and want to avoid hyper-threading cores.


Execution Parameters

  • site.exec_ee_log_level
    Default: 500
    Permitted Tye: int
    ExecutionEngine log level.
  • site.exec_profiling
    Default: false
    Permitted Tye: boolean
    Enable execution site profiling. This will keep track of how busy each PartitionExecutor thread is during execution (i.e., the percentage of time that it spends executing a transaction versus waiting for work to be added to its queue). The profiling data collected can be retrieved using the @Statistics sysproc.
  • site.exec_speculative_execution Experimental Deprecated
    Default: true
    Permitted Tye: boolean
    Replaced By: site.specexec_enable
    If this feature is enabled, then each HStoreSite will attempt to speculatively execute single-partition transactions whenever it completes a work request for a multi-partition transaction running on a different node.
  • site.exec_no_undo_logging Experimental
    Default: false
    Permitted Tye: boolean
    If this feature is enabled, then those non-speculative single partition transactions that are deemed to never abort will be executed without undo logging. Requires Markov model estimations.
  • site.exec_no_undo_logging_all Experimental
    Default: false
    Permitted Tye: boolean
    All transactions are executed without any undo logging. For testing purposes only.
  • site.exec_force_undo_logging_all Experimental
    Default: true
    Permitted Tye: boolean
    Force all transactions to execute with undo logging. For testing purposes only.
  • site.exec_db2_redirects Experimental
    Default: true
    Permitted Tye: boolean
    If this configuration parameter is true, then H-Store will use DB2-style transaction redirects. Each request will execute as a single-partition transaction at a random partition on the node that the request originally arrives on. When the transaction makes a query request that needs to touch data from a partition that is different than its base partition, then that transaction is immediately aborted, rolled back, and restarted on the partition that has the data that it was requesting. If the transaction requested more than partition when it was aborted, then it will be executed as a multi-partition transaction on the partition that was requested most often by queries using random tie breakers). See http://ibm.co/fLR2cH for more information.
  • site.exec_force_singlepartitioned
    Default: true
    Permitted Tye: boolean
    Always execute transactions as single-partitioned (excluding sysprocs). If a transaction requests data on a partition that is different than where it is executing, then it is aborted, rolled back, and re-executed on the same partition as a multi-partition transaction that touches all partitions. Note that this is independent of how H-Store decides whatpartition to execute the transaction’s Java control code on.
  • site.exec_force_allpartitions Experimental
    Default: false
    Permitted Tye: boolean
    Always execute all requests as distributed transactions that lock all partitions in the cluster.
  • site.exec_voltdb_procinfo
    Default: false
    Permitted Tye: boolean
    Use the VoltDB @ProcInfo annotations for stored procedures to determine whether a new request will be executed as a single-partitioned or distributed transaction. Note that if this option is enabled, any distributed transaction will have to lock all of the partitions in the cluster.
  • site.exec_force_localexecution
    Default: false
    Permitted Tye: boolean
    Always execute each transaction on a random partition on the node where the request originally arrived on. Note that this is independent of whether the transaction is selected to be single-partitioned or not. It is likely that you do not want to use this option.
  • site.exec_mispredict_crash
    Default: false
    Permitted Tye: boolean
    Whether the VoltProcedure should crash the HStoreSite when a transaction is mispredicted. A mispredicted transaction is one that was originally identified as single-partitioned but then executed a query that attempted to access multiple partitions. This is primarily used for debugging the TransactionEstimator.
  • site.exec_preprocessing_threads
    Default: false
    Permitted Tye: boolean
    If this enabled, HStoreSite will use a separate thread to process inbound requests from the clients.
  • site.exec_preprocessing_threads_count Experimental
    Default: -1
    Permitted Tye: int
    The number of TransactionPreProcessor threads to use per HStoreSite. If this parameter is set to -1, then the system will automatically use all of the non-PartitionExecutor cores for these processing threads. The site.exec_preprocessing_threads parameter must be set to true.
  • site.exec_postprocessing_threads
    Default: true
    Permitted Tye: boolean
    Use a separate TransactionPostProcessor thread in the HStoreSite to return results back to the client. This will to improve the throughput of the CommandLogWriter, since this thread will take care of all of the outbound network communication with clients.
  • site.exec_queued_response_ee_bypass Experimental
    Default: true
    Permitted Tye: boolean
    If this enabled with speculative execution, then HStoreSite only invoke the commit operation in the EE for the last transaction in the queued responses. This will cascade to all other queued responses successful transactions that were speculatively executed.
  • site.exec_response_timeout Experimental
    Default: 10000
    Permitted Tye: int
    The maximum amount of time that the PartitionExecutor will wait for the results of a distributed query to return to the transaction’s base partition. Usually if this limit is reached, then there is something very wrong with the distributed transaction protocol.
  • site.exec_validate_work Experimental
    Default: false
    Permitted Tye: boolean
    If this parameter is enabled, then the PartitionExecutor will check for every SQLStmt batch for each distributed transaction contains valid WorkFragments.
  • site.exec_early_prepare
    Default: true
    Permitted Tye: boolean
    Enables the early 2PC prepare optimization.
  • site.exec_adhoc_sql
    Default: true
    Permitted Tye: boolean
    Setting this configuration parameter to true allows clients to issue ad hoc query requests use the @AdHoc sysproc. This should be set to false if you are running benchmarking experiments because it will reduce the number of threads that are started per HStoreSite.
  • site.exec_prefetch_queries Experimental
    Default: false
    Permitted Tye: boolean
    If this parameter is enabled, then the DBMS will attempt to prefetch commutative queries on remote partitions for distributed transactions.
  • site.exec_deferrable_queries Experimental
    Default: false
    Permitted Tye: boolean
    If this parameter is enabled, then the DBMS will queue up any single-partitioned queries for later execution if they are marked as deferrable.
  • site.exec_periodic_interval
    Default: 50
    Permitted Tye: int
    How often in milliseconds should the HStoreSite check for periodic work. This work includes checking for dead network connections and processing any ad-hoc SQL invocatons. You probably do not need to change this unless you want a lower latency for ad-hoc SQL queries or you want to completely remove the overhead of performing periodic checks.
  • site.exec_readwrite_tracking Experimental
    Default: false
    Permitted Tye: boolean
    Enables H-Store’s ExecutionEngine to track of what tuples a transaction reads and writes at each partition. This is currently only used for the OPTIMISTIC speculative executionconflict checker. See site.specexec_scheduler_checker.


Speculative Execution Parameters

  • site.specexec_enable Experimental
    Default: true
    Permitted Tye: boolean
    If this feature is enabled, then each HStoreSite will attempt to speculatively execute single-partition transactions whenever it completes a work request for a multi-partition transaction running on a different node.
  • site.specexec_scheduler_checker
    Default: TABLE
    Permitted Tye: string
    Permitted Values: [TABLE, MARKOV, UNSAFE, OPTIMISTIC]
    See Also: org.voltdb.types.SpeculationConflictCheckerType
    This controls what conflict detection algorithm the SpecExecScheduler will use to use at run time to decide what transactions to run speculatively.
  • site.specexec_scheduler_policy
    Default: FIRST
    Permitted Tye: string
    Permitted Values: [FIRST, LAST, SHORTEST, LONGEST]
    See Also: org.voltdb.types.SpecExecSchedulerPolicyType
    Speculative policy to pick the transactions to run speculatively.
  • site.specexec_scheduler_window
    Default: 10
    Permitted Tye: int
    The window size to pick up txn to run speculatively.
  • site.specexec_ignore_all_local Experimental
    Default: false
    Permitted Tye: boolean
    If this parameter is true, then the SpecExecScheduler will not attempt to speculatively execute any transactions if the current distributed transaction is using only partitions that are all on the same site.
  • site.specexec_ignore_queue_size_change Experimental
    Default: false
    Permitted Tye: boolean
    If this parameter is true, then the SpecExecScheduler will not reset its internal iterator if the partition’s lock queue changes in size. This will provide a minor speed up when checking for speculative transactions, but it also means that new transactions that are added to the front of the queue will be missed.
  • site.specexec_ignore_interruptions Experimental
    Default: false
    Permitted Tye: boolean
    This parameter controls whether the SpecExecScheduler will ignore any interrupts from incoming WorkFragments added to its PartitionExecutor’s queue. You most likely do not want to enable this because it will slow down the execution of distributed transactions.
  • site.specexec_ignore_stallpoints
    Default: null
    Permitted Tye: string
    Permitted Values: [NULL, SP1_IDLE, SP1_LOCAL, SP2_LOCAL, SP3_REMOTE_BEFORE, SP3_REMOTE_AFTER, SP4_LOCAL, SP4_REMOTE]
    See Also: org.voltdb.types.SpeculationType
    Disable speculative execution at the given stall points.
  • site.specexec_nonblocking Experimental
    Default: false
    Permitted Tye: boolean
    Experimental non-blocking remote query execution. All query results will be wrapped in a special VoltTable that acts as a placeholder for a remote query whose result has not returned yet. A transaction when it tries to access the real result. Otherwise, it will proceed as normal. This does not require any changes to existing stored procedure code.
  • site.specexec_unsafe_limit Experimental
    Default: -1
    Permitted Tye: int
    Note that site.markov_enable must be set to true.
  • site.specexec_profiling Experimental
    Default: false
    Permitted Tye: boolean
    If enabled, then the SpecExecScheduler will keep track of various internal profile statistics. The profiling data collected can be retrieved using the @Statistics sysproc.
  • site.specexec_profiling_sample Experimental
    Default: 0.05
    Permitted Tye: double
    Sample factor for speculative execution scheduler profiling (0.0 – 1.0). Note that the the site.specexec_profiling parameter must also be enabled.
  • site.specexec_disable_partitions Experimental
    Default: null
    Permitted Tye: string
    Comma-separated list of partition ids to disable speculative execution on. This is only needed for debugging and experiments.


Command Logging Parameters

  • site.commandlog_enable Experimental
    Default: false
    Permitted Tye: boolean
    If enabled, log all transaction requests to disk
  • site.commandlog_dir Experimental
    Default: global.temp_dir/cmdlog
    Permitted Tye: string
    Directory for storage of command logging files
  • site.commandlog_timeout Experimental
    Default: 10
    Permitted Tye: int
    Timeout in milliseconds before group commit buffer flushes, if it does not fill
  • site.commandlog_profiling Experimental
    Default: false
    Permitted Tye: boolean
    If enabled, then the CommandLogWriter will keep track of various internal profile statistics.


Anti-Caching Parameters

  • site.anticache_enable Experimental
    Default: false
    Permitted Tye: boolean
    Enable the anti-cache feature. This requires that the system is compiled with site.anticache_build set to true.
  • site.anticache_warmup_eviction_enable Experimental
    Default: true
    Permitted Tye: boolean
    Enable anti-caching warmup feature. This requires that the system is compiled with both site.anticache_enabled and ${site.anticache_build set to true.
  • site.anticache_warmup_eviction_time Experimental
    Default: 0
    Permitted Tye: int
    Reserved eviction time for anti-caching after warmup of the benchmark. This requires that the system is compiled with site.anticache_warmup_eviction_enable set to true.
  • site.anticache_enable_multilevel Experimental
    Default: false
    Permitted Tye: boolean
    Enable multilevel anti-caching feature. This requires that the system is compiled with both site.anticache_enabled and ${site.anticache_build set to true.
  • site.anticache_build Experimental
    Default: true
    Permitted Tye: boolean
    Build the anti-cache feature when compiling the H-Store source code. You probably always want to leave this flag enabled.
  • site.anticache_reversible_lru Experimental
    Default: true
    Permitted Tye: boolean
    Use a doubly-linked list for the anti-cache’s LRU tracker. This will increase the memory overhead of the anti-cache’s metatadata but it will improve the performance of eviction operations.
  • site.anticache_profiling Experimental
    Default: false
    Permitted Tye: boolean
    Enable the anti-cache profiling.
  • site.anticache_dir Experimental
    Default: global.temp_dir/anticache
    Permitted Tye: string
    The directory to use to store the evicted tuples.
  • site.anticache_levels Experimental
    Default: NVM,true,256K,64G;BERKELEY,false,256K,128G
    Permitted Tye: string
    Configuration options for multilevel anticaching. Up to five levels can be set up. The format is type,blocking,block_size,db_size; The default is ‘NVM,true,256K,64G;BERKELEY,false,256K,128G’.
  • site.anticache_multilevel_dirs Experimental
    Default: global.temp_dir/ac-level1;global.temp_dir/ac-level2;global.temp_dir/ac-level3;global.temp_dir/ac-level4;global.temp_dir/ac-level5
    Permitted Tye: string
    The directories used for multilevel anticaching databases.
  • site.anticache_block_size Experimental
    Default: 262144
    Permitted Tye: long
    The size (in bytes) for the anti-cache’s blocks on disk.WARNING: this seem to be buggy/broken. Please leave the default value of 256KB (262144) unless you know what you’re doing.
  • site.anticache_dbsize Experimental
    Default: 2G
    Permitted Tye: string
    The size of the anticache database.
  • site.anticache_reset Experimental
    Default: true
    Permitted Tye: boolean
    Reset the anti-cache database directory for each partition when the HStoreSite is started.
  • site.anticache_check_interval Experimental
    Default: 30000
    Permitted Tye: int
    How often in milliseconds should the AntiCacheManager check whether the HStoreSite is using too much memory and should start evicting tuples.
  • site.anticache_threshold_mb Experimental
    Default: 200
    Permitted Tye: int
    Memory usage threshold, in MB, at which to start evicting
  • site.anticache_max_evicted_blocks Experimental
    Default: 200000
    Permitted Tye: int
    Maximum number of blocks evicted on this site
  • site.anticache_blocks_per_eviction Experimental
    Default: 200
    Permitted Tye: int
    Maximum number of blocks per eviction
  • site.anticache_eviction_distribution Experimental
    Default: UNEVICTION_RATIO
    Permitted Tye: string
    Permitted Values: [EVEN, PROPORTIONAL, UNEVICTION_RATIO, ACCESS_RATE]
    See Also: org.voltdb.types.AntiCacheEvictionPolicyType
    Policy specifying how to distribute eviction load over partitions and tables.
  • site.anticache_batching
    Default: false
    Permitted Tye: boolean
    Turn on batching for anticaching
  • site.anticache_dbtype Experimental
    Default: BERKELEY
    Permitted Tye: string
    Permitted Values: [NONE, BERKELEY, NVM, ALLOCATORNVM]
    See Also: org.voltdb.types.AntiCacheDBType
    Type of database for the highest level eviction
  • site.anticache_db_blocks Experimental
    Default: false
    Permitted Tye: boolean
    Top level database blocks for evictions
  • site.anticache_block_merge Experimental
    Default: true
    Permitted Tye: boolean
    Merge entire block when unevicting. False merges just a single tuple
  • site.anticache_counter Experimental
    Default: false
    Permitted Tye: boolean
    Enable the anti-cache counted merge-back feature. This requires that the system is compiled with site.anticache_enable set to true and site.anticache_db_blocks set to true.
  • site.anticache_timestamps Experimental
    Default: true
    Permitted Tye: boolean
    Enable the anti-cache timestamps feature. This requires that the system is compiled with site.anticache_enable set to true.
  • site.anticache_timestamps_prime Experimental
    Default: true
    Permitted Tye: boolean
    Enable the anti-cache timestamps use a prime sample strategy instead of radom-tuple sampling.This is compiled with site.anticache_timestamps set to true.


Internal Storage Parameters

  • site.storage_mmap Experimental
    Default: false
    Permitted Tye: boolean
    Use mmap to store database on local filesystem.
  • site.storage_mmap_dir Experimental
    Default: global.temp_dir/mmap
    Permitted Tye: string
    Location of where H-Store will store mmap files for each partition. This is only used if site.storage_mmap is enabled.
  • site.storage_mmap_file_size Experimental
    Default: 2097152
    Permitted Tye: long
    The size (in bytes) for the mmap file objects on NVM device.
  • site.storage_mmap_reset Experimental
    Default: true
    Permitted Tye: boolean
    Reset the mmap directory for each partition when the HStoreSite is started.
  • site.storage_mmap_sync_frequency Experimental
    Default: 100000
    Permitted Tye: long
    Frequency with which changes are synced via msync with memory


ARIES-based Recovery Parameters

  • site.aries Experimental
    Default: false
    Permitted Tye: boolean
    ARIES recovery enabled.
  • site.aries_forward_only Experimental
    Default: true
    Permitted Tye: boolean
    ARIES forward processing only enabled, recovery disabled – for throughput evaluation
  • site.aries_dir Experimental
    Default: global.temp_dir/aries
    Permitted Tye: string
    Location of where H-Store will store ARIES log files for each partition. This is only used if site.aries is enabled.
  • site.aries_reset Experimental
    Default: false
    Permitted Tye: boolean
    Reset the ARIES directory for each partition when the HStoreSite is started (disabled by default).


Snapshot Checkpoints Parameters

  • site.snapshot Experimental
    Default: false
    Permitted Tye: boolean
    Logical recovery using snapshots enabled.
  • site.snapshot_dir Experimental
    Default: global.temp_dir/snapshot
    Permitted Tye: string
    Location of where H-Store will store snapshot files for each partition’s tables. This is only used if site.snapshot is enabled.
  • site.snapshot_reset Experimental
    Default: false
    Permitted Tye: boolean
    Reset the snapshot directory for each partition when the HStoreSite is started (disabled by default).
  • site.snapshot_interval Experimental
    Default: 10000
    Permitted Tye: int
    How often in milliseconds should we take snapshots in HStoreSite


MapReduce Parameters

  • site.mr_map_blocking Experimental
    Default: true
    Permitted Tye: boolean
    If set to true, then the MAP phase of a MapReduceTransaction will be executed as a distributed transaction that blocks the entire cluster. This ensures that the aggregates computed by the MAP phase reads from consistent a consistent state of the database.
  • site.mr_reduce_blocking Experimental
    Default: true
    Permitted Tye: boolean
    The way to execute reduce job, blocking or non-blocking by MapReduceHelperThread


Network Parameters

  • site.network_heartbeats_interval
    Default: 10000
    Permitted Tye: int
    How often in milliseconds the HStoreCoordinator at each HStoreSite should send heartbeat notifications to the other coordinators in the cluster.
  • site.network_startup_wait
    Default: 15000
    Permitted Tye: int
    How long in milliseconds should the HStoreCoordinator wait to establish the initial connections to other nodes in the cluster at start-up. Increasing this number will help with larger cluster deployments.
  • site.network_startup_retries
    Default: 2
    Permitted Tye: int
    If the HStoreCoordinator fails to connect to all of the other nodes in the cluster after site.network_startup_wait has passed, this parameter defines the number of times that it is allowed to attempt to reconnect to them. This helps with some rare network issues with the ProtoRpc framework where the initial network connection attempt hangs or fails, even though both sites are available.
  • site.network_incoming_max_per_partition Deprecated
    Default: 5000
    Permitted Tye: int
    Replaced By: site.network_incoming_limit_txns
    Max size of queued transactions before an HStoreSite will stop accepting new requests from clients and will block the network connections.
  • site.network_incoming_limit_txns
    Default: 8000
    Permitted Tye: int
    Max size of queued transactions before an HStoreSite will stop accepting new requests from clients and will block the network connections. This is per partition.
  • site.network_incoming_limit_bytes
    Default: 67108864
    Permitted Tye: long
    Max number of bytes in the queued transactions before an HStoreSite will stop accepting new requests from clients and will block the network connections.


Transaction Parameters

  • site.txn_client_debug
    Default: false
    Permitted Tye: boolean
    If this parameter is set to true, then the ClientResponse returned by the server will include a special ClientResponseDebug handle that contains additional information about the transaction. Note that enabling this option will break compatibility with VoltDB’s client libraries.
  • site.txn_profiling
    Default: false
    Permitted Tye: boolean
    Enable transaction profiling. This will measure the amount of time a transaction spends in different parts of the system (e.g., waiting in the work queue, planning, executing). The profiling data collected can be retrieved using the @Statistics sysproc.
  • site.txn_profiling_sample
    Default: 0.1
    Permitted Tye: double
    Sample factor for transaction profiling (0.0 – 1.0). This will be used at runtime to determine whether a transaction is executed with the profiling hooks enabled. Note that the the site.txn_profiling parameter must also be enabled.
  • site.txn_profiling_dump
    Default: false
    Permitted Tye: boolean
    If this is set to true, then each HStoreSite will write out a CSV file on its local filesystem that contains a dump of the runtime profiling information for each transaction. Check the site log for the output name of each file. Note that the the site.txn_profiling parameter must also be enabled.
  • site.txn_counters
    Default: true
    Permitted Tye: boolean
    Enable transaction execution mode counting. This will cause the HStoreSite to keep track of various properties about tranasctions, such as the number that were speculatively executed or had to be restarted.
  • site.txn_incoming_delay Experimental
    Default: 5
    Permitted Tye: int
    The amount of time in milliseconds that the TransactionQueueManager will wait before letting a distributed transaction acquire a lock on a partition.
  • site.txn_restart_limit
    Default: 10
    Permitted Tye: int
    The number of times that a distributed transaction is allowed to be restarted (due to things like network delays) before it is outright rejected and the request is returned to the client.
  • site.txn_restart_limit_sysproc
    Default: 10
    Permitted Tye: int
  • site.txn_partition_id_managers Experimental
    Default: false
    Permitted Tye: boolean
    If set to true, then the HStoreSite will use a separate TransactionIdManagerper partition. This can reduce some lock contention for workloads where transactions are restarted a lot. This actually doesn’t work very well, so you probably do not want to bother with this parameter.


Workload Queue Parameters

  • site.queue_profiling
    Default: false
    Permitted Tye: boolean
    Enable profiling in the TransactionQueueManager and PartitionLockQueue in the HStoreSite. The profiling data collected can be retrieved using the @Statistics sysproc.
  • site.queue_threshold_factor
    Default: 1.0
    Permitted Tye: double
    The initial throttling threshold for the PartitionLockQueue.
  • site.queue_autoscale_delta Experimental
    Default: 50
    Permitted Tye: int
  • site.queue_allow_decrease
    Default: true
    Permitted Tye: boolean
  • site.queue_allow_increase
    Default: true
    Permitted Tye: boolean
  • site.queue_min_factor
    Default: 0.5
    Permitted Tye: double
    The initial throttling threshold for the PartitionLockQueue.
  • site.queue_max_factor
    Default: 1.5
    Permitted Tye: double
    The initial throttling threshold for the PartitionLockQueue.
  • site.queue_release_factor
    Default: 0.5
    Permitted Tye: double
    If the HStoreSite is throttling incoming client requests at individual partitions, then that HStoreSite will not accept new requests until the number of queued transactions is less than this percentage in a partition’s lock queue. Note that this only considers the total number of transactions that are in the PartitionLockQueue, not transactions that are waiting to be initialized or have already completed.


Parameter Mappings Parameters

  • site.mappings_path
    Default: null
    Permitted Tye: string


Transaction Prediction Models Parameters

  • site.markov_enable Experimental
    Default: false
    Permitted Tye: boolean
    Predict what transactions will do before they execute using TransactionEstimator’s Markov models.
  • site.markov_force_traversal Experimental
    Default: true
    Permitted Tye: boolean
    Force the MarkovPathEstimator to always choose a transition from an execution state in a Markov model even if there is not a state that matches the prediction. This ensures that the estimated path always reaches either the COMMIT or ABORT terminal states and therefore a valid estimation can be created.
  • site.markov_learning_enable Experimental
    Default: false
    Permitted Tye: boolean
    Allow the MarkovPathEstimator to automatically learn new execution states for transactions if it is unable to find the correct one for the current transaction. The updated models can be retrieved using the @MarkovUpdate system procedure. Note that site.markov_force_traversal must be set to true.
  • site.markov_singlep_updates Experimental
    Default: false
    Permitted Tye: boolean
    If this parameter is set to true, then the PartitionExecutor will use its TransactionEstimator to calculate updated estimates after a single-partition transaction submits a new batch of queries for execution.
  • site.markov_dtxn_updates Experimental
    Default: true
    Permitted Tye: boolean
    If this parameter is set to true, then the PartitionExecutor will use its TransactionEstimator to calculate updated estimates after a distributed transaction submits a new batch of queries for execution.
  • site.markov_mispredict_recompute Experimental
    Default: true
    Permitted Tye: boolean
    Recompute a Markov model’s execution state probabilities every time a transaction is aborted due to a misprediction.
  • site.markov_path Experimental
    Default: null
    Permitted Tye: string
  • site.markov_path_caching Experimental
    Default: true
    Permitted Tye: boolean
    If this is set to true, TransactionEstimator will try to reuse the last successfully estimate path in a MarkovGraph for transactions that use thesame graph.
  • site.markov_path_caching_threshold Experimental
    Default: 1.0
    Permitted Tye: double
    This threshold defines how accurate our cached MarkovPathEstimators have to be in order to keep using them. If (# of accurate txs / total txns) for a paritucular MarkovGraph goes below this threshold, then we will disable the caching
  • site.markov_fast_path Experimental
    Default: true
    Permitted Tye: boolean
    If this is set to true, the MarkovEstimator will attempt to use the initial path estimate to quickly calculate the new path for a running transaction.
  • site.markov_endpoint_caching Experimental
    Default: false
    Permitted Tye: boolean
    This enables the ability for the MarkovEstimator to cache the end points of path segments in a MarkovGraph so that it can just quickly identify the last MarkovVertex for a new batch of queries requested by the transaction.
  • site.markov_batch_caching_min Experimental
    Default: 3
    Permitted Tye: int
    The minimum number of queries that must be in a batch for the TransactionEstimator to cache the path segment in the procedure’s MarkovGraph. Provides a minor speed improvement for large batches with little variability in their execution paths.
  • site.markov_fixed Experimental
    Default: false
    Permitted Tye: boolean
    Use a fixed transaction estimator to predict the initial properties of an incoming transaction request from the client. This is a quick and dirty approximation. Not all benchmarks are supported and it does not generate predictions updates after the transaction starts running
  • site.markov_profiling
    Default: false
    Permitted Tye: boolean
    Enable profiling in the MarkovEstimator. The profiling data collected can be retrieved using the @Statistics sysproc.


Runtime SQL Batch Planner Parameters

  • site.planner_profiling
    Default: false
    Permitted Tye: boolean
    Enable BatchPlanner profiling. This will keep of how long the BatchPlanner spends performing certain operations when generating an execution plan for a batch of queries submitted by a running transaction. The profiling data collected can be retrieved using the @Statistics sysproc.
  • site.planner_caching
    Default: true
    Permitted Tye: boolean
    Enable caching in the BatchPlanner. This will provide a significant speed improvement for single-partitioned queries because the BatchPlanner is able to quickly identify what partitions a batch of queries will access without having to process the request using the PartitionEstimator. This parameter is so great I should probably just hardcode to be always on, but maybe you don’t believe me and want to see how slow things go with out this…
  • site.planner_max_round_size
    Default: 10
    Permitted Tye: int
    The maximum number of execution rounds allowed per batch.
  • site.planner_max_batch_size
    Default: 128
    Permitted Tye: int
    The maximum number of SQLStmts that can be queued per batch in a transaction.
  • site.planner_unique_dependency_ids Experimental
    Default: false
    Permitted Tye: boolean
    Use globally unique Dependency Ids for each unique SQLStmt batch when generating WorkFragments at run time.


Cluster Coordinator Parameters

  • site.coordinator_init_thread
    Default: false
    Permitted Tye: boolean
    If this enabled, HStoreCoordinator will use a separate thread to process incoming initialization requests from other HStoreSites. This is useful when client.txn_hints is disabled.
  • site.coordinator_finish_thread
    Default: false
    Permitted Tye: boolean
    If this enabled, HStoreCoordinator will use a separate thread to process incoming finish requests for restarted transactions from other HStoreSites.
  • site.coordinator_redirect_thread
    Default: false
    Permitted Tye: boolean
    If this enabled, HStoreCoordinator will use a separate thread to process incoming redirect requests from other HStoreSites. This is useful when client.txn_hints is disabled.
  • site.coordinator_sync_time
    Default: true
    Permitted Tye: boolean
    If this enabled, HStoreCoordinator will use an NTP style protocol to find the time difference between sites in the cluster.


Workload Traces Parameters

  • site.trace_txn_output
    Default: false
    Permitted Tye: boolean
    When this property is set to true, all TransactionTrace records will include the stored procedure output result
  • site.trace_query_output
    Default: false
    Permitted Tye: boolean
    When this property is set to true, all QueryTrace records will include the query output result


Site Debug Status Parameters

  • site.status_enable
    Default: false
    Permitted Tye: boolean
    Enable HStoreSite’s Status thread.
  • site.status_interval
    Default: 20000
    Permitted Tye: int
    How often the HStoreSite’s StatusThread will print a status update (in milliseconds).
  • site.status_kill_if_hung
    Default: false
    Permitted Tye: boolean
    Allow the HStoreSiteStatus thread to kill the cluster if the local HStoreSite appears to be hung. The site is considered hung if it has executed at least one transaction and has not completed (either committed or aborted) any new transactions since the last time it took a status snapshot.
  • site.status_check_for_zombies
    Default: false
    Permitted Tye: boolean
    Allow the HStoreSiteStatus thread to check whether there any zombie transactions. This can occur if the transaction has already sent back the ClientResponse, but its internal state has not been cleaned up.
  • site.status_exec_info
    Default: false
    Permitted Tye: boolean
    When this property is set to true, HStoreSite status will include information about each PartitionExecutor, such as the number of transactions currently queued, blocked for execution, or waiting to have their results returned to the client.
  • site.status_thread_info
    Default: false
    Permitted Tye: boolean
    When this property is set to true, HStoreSite status will include a snapshot of running threads


Object Pools Parameters

  • site.pool_scale_factor
    Default: 1.0
    Permitted Tye: double
    The scale factor to apply to the object pool configuration values.
  • site.pool_profiling
    Default: false
    Permitted Tye: boolean
    Whether to track the number of objects created, passivated, and destroyed from the pool. Results are shown in HStoreSiteStatus updates.
  • site.pool_pathestimators_idle
    Default: 100
    Permitted Tye: int
    The max number of MarkovPathEstimators to keep in the pool per partition