Threading Options
You are looking at an older version of the documentation. The latest version is found here.
Transport
| Option | Default value | Description |
|---|---|---|
max-socket-threads | 0 | Maximum number of threads dedicated to the initial request processing. Zero indicates to use the system default of max available processors. All access to the Data Virtuality Server (JDBC and ODBC) is controlled by the transport element in the configuration. Socket threads are configured for each transport. They handle NIO non-blocking IO operations and directly service any operation that can run without blocking. For longer-running operations, the socket threads queue with work the query engine |
Changing the Settings
To change the default settings, modify the %dvDir%/standalone/configuration/dvserver-standalone.xml file, namely, the section described by the XML tag <subsystem xmlns="urn:jboss:domain:teiid:1.1">. Usually, there are no entries for these settings:
XML
<subsystem xmlns="urn:jboss:domain:teiid:1.1">
...
<transport name="jdbc" socket-binding="dv-jdbc">
...
</transport>
<transport name="jdbc-ssl" socket-binding="dv-jdbc-ssl">
...
</transport>
<transport name="odbc" socket-binding="dv-odbc" protocol="pg">
...
</transport>
<transport name="odbc-ssl" socket-binding="dv-odbc-ssl" protocol="pg">
...
</transport>
...
</subsystem>You can add the settings to be changed as properties to the desired transport types. Here is an example:
XML
<subsystem xmlns="urn:jboss:domain:teiid:1.1">
...
<transport name="jdbc" socket-binding="dv-jdbc" max-socket-threads="4">
...
</transport>
<transport name="jdbc-ssl" socket-binding="dv-jdbc-ssl" max-socket-threads="4">
...
</transport>
<transport name="odbc" socket-binding="dv-odbc" protocol="pg" max-socket-threads="4">
...
</transport>
<transport name="odbc-ssl" socket-binding="dv-odbc-ssl" protocol="pg" max-socket-threads="4">
...
</transport>
...
</subsystem>Query Engine
| Option | Default value | Description |
|---|---|---|
max-threads | 64 | The query engine has several settings determining its thread utilization. The max-threads option sets the total number of threads available in the process pool for query engine work (processing plans, transaction control operations, processing source queries, etc.). Consider increasing the maximum threads on systems with a large number of available processors and/or when It is common to issue non-transactional queries that result in a large number of concurrent source requests |
max-active-plans | 20 | Should always be smaller than max-threads. Use the formula (max-threads / max_active_plans) * 2 to calculate the number of max-threads available to be used for processing each user query. Increasing max-active-plans should be considered for workloads with a high number of long-running queries and/or systems with many available processors. If memory issues arise from increasing max-threads and max-active-plans, consider decreasing processor-batch-size to limit the base number of memory rows consumed by each plan |
thread-count-for-source-concurrency | 0 | Should always be smaller than max-threads. Sets the number of concurrently executing source queries per user request. 0 indicates to use the default calculated value based on the formula 2 * (max-threads / max-active-plans). Setting this option to 1 forces serial execution of all source queries by the processing thread. Any number greater than 1 limits the maximum number of concurrently executing source requests accordingly. This means that each user request would be allowed six concurrently executing source queries. Adjust the value if you have queries that generate more concurrent long-running source queries |
time-slice-in-milliseconds | 2000 | Provides course scheduling of long-running processor plans. Plans whose execution exceeds the indicated time slice will be re-queued for additional processing to allow for other plans to be initiated. The time slice is from the perspective of the engine processing thread. This value is not honoured exactly as the plan may not be at a re-startable point when the time slice expires. This is not a replacement for the thread scheduling performed by Java and the operating system, instead, it just ensures that the Data Virtuality Server allows other work to be started if the current set of active plans includes long-running queries |
Changing the Settings
To change the default settings, modify the %dvDir%/standalone/configuration/dvserver-standalone.xml file, namely, the section described by the XML tag <subsystem xmlns="urn:jboss:domain:teiid:1.1">. Usually, there are no entries for these settings:
XML
<subsystem xmlns="urn:jboss:domain:teiid:1.1">
<buffer-service memory-buffer-off-heap="true" max-storage-object-size="134217728"/>
...
</subsystem>You can append the settings to be changed after the buffer-service tag. Here is an example:
XML
<subsystem xmlns="urn:jboss:domain:teiid:1.1">
<async-thread-pool>teiid-async</async-thread-pool>
<buffer-service memory-buffer-off-heap="true" max-storage-object-size="134217728"/>
<max-threads>128</max-threads>
<max-active-plans>40</max-active-plans>
<thread-count-for-source-concurrency>4</thread-count-for-source-concurrency>
<time-slice-in-millseconds>4000</time-slice-in-millseconds>
...
</subsystem>Threads for Job Execution
| Option | Default value | Description |
|---|---|---|
threadCount | 15 | Number of threads available for concurrent execution of jobs. If you increase this setting, remember to adjust max-threads and max-active-plans as well |
To change the default value of this option, go to the %dvDir%/standalone/configuration/dvserver-standalone.xml file and edit the following line:
XML
<server xmlns="urn:jboss:domain:12.0">
[..]
<profile>
[..]
<subsystem xmlns="urn:jboss:domain:teiid:1.1">
[..]
<quartz>
<property name="org.quartz.threadPool.threadCount" value="15"/>
<property name="org.quartz.jobStore.class" value="com.datavirtuality.dv.core.scheduler.DVJobStore"/>
<property name="com.datavirtuality.quartz.DVJobStore.misfireThreshold" value="3600000"/>
</quartz>