The BufferManager is responsible for tracking both memory and disk usage by Teiid. Configuring the BufferManager properly is one of the most important parts of ensuring high performance. See the <jboss-install>/server/<profile>/deploy/teiid/teiid-jboss-beans.xml file for all BufferManager settings.

The Teiid engine uses batching to reduce the number of memory rows processed at a given time. The batch sizes may be adjusted to larger values if few clients will be accessing the Teiid server simultaneously.

The maxReserveBatchColumns setting determines the total number of batches (with a max of processorBatchSize rows) multiplied by their column width that can be held in memory directly by the BufferManager. This number does not include persistent batches held by soft (such as index pages) or weak references. When your installation can dedicate more memory to Teiid, consider increasing this value in proportion to the number of gigabytes you wish Teiid to use - e.g. 2GB on a 32 bit VM would double the value to 32768. For 64 bit VMs you should use a value of approximately 11000 per GB. The BufferManager automatically triggers the use of a canonical value cache when more than 25% of the reserve is in use. This can dramatically cut the memory usage in situations where similar value sets are being read through Teiid, but does introduce a lookup cost. If you are processing large (100s of MBs) of highly unique datasets through Teiid, you should consider disabling value caching since it will not significantly reduce memory consumption.

Each intermediate result buffer, temporary LOB, and temporary table is stored in its own set of buffer files, where an individual file is limited to maxFileSize megabytes. Consider increasing the storage space available to all such files maxBufferSpace if your installation makes use of internal materialization, makes heavy use of SQL/XML, or processes large row counts.

Socket threads are configured for each transport. They handle NIO non-blocking IO operations as well as directly servicing any operation that can run without blocking.

For longer running operations, the socket threads queue with work the query engine. The query engine has two settings that determine its thread utilization. maxThreads sets the total number of threads available for query engine work (processing plans, transaction control operations, processing source queries, etc.). You should consider increasing the maximum threads on systems with a large number of available processors and/or when it's common to issue non-transactional queries with that issue a large number of concurrent source requests. maxActivePlans, which should always be smaller than maxThreads, sets the number of the maxThreads that should be used for user query processing. Increasing the maxActivePlans should be considered for workloads with a high number of long running queries and/or systems with a large number of available processors. If memory issues arise from increasing the max threads and the max active plans, then consider decreasing the processor/connector batch sizes to limit the base number of memory rows consumed by each plan.

Caching can be tuned for cached result (including user query results and procedure results) and prepared plans (including user and stored procedure plans). Even though it is possible to disable or otherwise severely constrain these caches, this would probably never be done in practice as it would lead to poor performance.

Cache statistics can be obtained through the Admin Console or Adminshell. The statistics can be used to help tune cache parameters and ensure a hit ratio.

Plans are currently fully held in memory and may have a significant memory footprint. When making extensive use of prepared statements and/or virtual procedures, the size of the plan cache may be increased proportionally to number of GB intended for use by Teiid.

While the result cache parameters control the cache result entries (max number, eviction, etc.), the result batches themselves are accessed through the BufferManager. If the size of the result cache is increased, you may need to tune the BufferManager configuration to ensure there is enough buffer space.

Teiid separates the configuration of its socket transports for JDBC, ODBC, and Admin access. Typical installations will not need to adjust the default thread and buffer size settings. At this time, ODBC queries are executed synchronously from the socket thread. Simultaneous long-running queries may exhaust the available threads. Consider increasing the default max threads (15) for ODBC if you expect a higher concurrent load of long-running queries.

LOBs and XML documents are streamed from the Teiid Server to the Teiid JDBC API.   Normally, these values are not materialized in the server memory - avoiding potential out-of-memory issues. When using style sheets, or XQuery, whole XML documents must be materialized on the server. Even when using the XMLQuery or XMLTable functions and document projection is applied, memory issues may occur for large documents.

LOBs are broken into pieces when being created and streamed.  The maximum size of each piece when fetched by the client can be configured with the "lobChunkSizeInKB" property in the <jboss-install>/server/<profile>/deploy/teiid/teiid-jboss-beans.xml file. The default value is 100 KB. When dealing with extremely large LOBs, you may consider increasing this value to decrease the amount of round-trips to stream the result. Setting the value too high may cause the server or client to have memory issues.

Source LOB values are typically accessed by reference, rather than having the value copied to a temporary location. Thus care must be taken to ensure that source LOBs are returned in a memory-safe manner.

When using Teiid in a development environment, you may consider setting the maxSourceRows property in the <jboss-install>/server/<profile>/deploy/teiid/teiid-jboss-beans.xml file to reasonably small level value (e.g. 10000) to prevent large amounts of data from being pulled from sources. Leaving the exceptionOnMaxSourceRows set to true will alert the developer through an exception that an attempt was made to retrieve more than the specified number of rows.