|
|
|
The FairCom Server’s data and index cache configuration options support specifying a scaling factor used when interpreting cache memory sizes. The supported scaling factors are:
Example
DAT_MEMORY 100 MB
The following configuration keywords support scaling factors along with their limits.
Keyword |
Limit |
 BUFR_MEMORY <bytes> Specifies the size of memory blocks the FairCom Server uses in conjunction with data and index cache buffers. To minimize interaction with the underlying system memory manager, the FairCom Server manages its own blocks of memory out of which the buffer pages are allocated. The FairCom Server acquires one large block of memory and allocates smaller pieces as needed. If you are attempting to limit memory use by reducing IDX_MEMORY and/or DAT_MEMORY, set BUFR_MEMORY to about one eighth of the smaller of IDX_MEMORY and DAT_MEMORY. DAT_MEMORY <bytes> The memory allocated to the data cache, specified in bytes. Within the memory constraints of the hardware, there is no effective limit. Default: 100 MB Note: Prior to V11, the default value for both the standard FairCom DB Server and the FairCom DB SQL Server was 600 * PAGE_SIZE. Assuming a default page size of 8192, the default DAT_MEMORY would be 4915200. PAGE_SIZE <bytes> The number of bytes per buffer page (maximum 65536 bytes). Only the following values are accepted (all other values generate an error):
To encourage compatibility across different FairCom DB environments, we suggest not modifying the PAGE_SIZE. However, if performance is of concern, this value may be modified to suit the characteristics of the operating system. Generally, this is a matter to discuss with the application programmer. Default: 32768 in V12 and later (before V12, the default was 8192) Warning: Changing the PAGE_SIZE is a maintenance task that should be done carefully and with a full reliable backup. Practice on a copy of your data and server folder until you are confident with the results. For procedures, see Adjusting PAGE_SIZE in the FairCom Installation Guide. Note: A file created with a larger PAGE_SIZE cannot be opened by a server with a smaller PAGE_SIZE.
See Also
IDX_MEMORY <bytes> The memory allocated to the index cache, specified in bytes. Within the memory constraints of the hardware, there is no effective limit. High-speed buffer search routines ensure quick access to the entire cache. Default: 100 MB Note: Prior to V11, the default value for both the standard FairCom DB Server and the FairCom DB SQL Server was 600 * PAGE_SIZE. Assuming a default page size of 8192, the default DAT_MEMORY would be 4915200. See Also
Default: 64000 See Also
|
1 GB |
|
CHECKPOINT_INTERVAL <interval in bytes or MB> This keyword can speed up recovery at the expense of performance during updates. The interval between checkpoints is measured in bytes of log entries. It is ordinarily about one-third (1/3) the size of one of the active log files (L000....FCS). Reducing the interval speeds automatic recovery at the expense of performance during updates. The entry is interpreted as bytes if greater than 100 or as megabytes if less than 100. For example, CHECKPOINT_INTERVAL 2 sets an approximate 2MB interval, while CHECKPOINT_INTERVAL 150000 causes checkpoints about every 150,000 bytes of log file. Default: 10 MB See Also |
1 GB |
|
CTSTATUS_SIZE <file_size | negative_file_size | 0> CTSTATUS_SIZE controls the size of the FairCom DB Server status file. The argument to CTSTATUS_SIZE is the approximate maximum size in bytes for CTSTATUS.FCS. When this limit is reached, CTSTATUS.FCS is renamed to T0000001.FCS and a new status file is created. The T#.FCS file numbers increase each time the limit is reached, similar to the transaction log files, i.e., the next time the maximum size is reached, CTSTATUS.FCS is renamed to T0000002.FCS. To limit the number of archived status logs, set a negative value for CTSTATUS_SIZE. Only T0000001.FCS will be kept, being replaced each time CTSTATUS.FCS is archived. A value of 0, the default, allows the file to expand to a size limited by the operating system and storage availability. Default: -32000000 |
2 GB-1 |
2^32-1 cache pages on 64-bit systems and 4 GB-1 on 32-bit systems (although we allow up to 4 GB-1, the O/S might impose a lower limit; it will appear as c-tree error 10 when starting FairCom Server) |
|
|
DISK_FULL_LIMIT <bytes available> FairCom DB Servers for Unix and Windows support the DISK_FULL_LIMIT keyword, which activates a disk space threshold mechanism to detect when a disk volume is getting full. The DISK_FULL_LIMIT configuration keyword takes as its argument the number of bytes that must remain available on a disk volume after a file has been extended. If the update operation fails, a message is written in CTSTATUS.FCS naming the file involved. FairCom DB Servers that do not support this feature ignore the DISK_FULL_LIMIT keyword. Note: When the disk is full, the FairCom DB files cannot be extended. The FairCom DB operations that attempt to add or update data in a file and require the files to be extended will fail with specific errors. This diagnostic keyword is used to put supplemental information in the status file and alert the user. Default: No disk full check See Also
|
4 GB-1 for platforms without native 64-bit integer support; otherwise 2^63-1 |
|
DISK_FULL_VOLUME /path Allows volume-specific disk full checks. DISK_FULL_VOLUME takes as its argument a concatenated volume name and limit. A path separator must occur between the volume name and the threshold limit, which may be zero. In Unix this is in the form /name/<limit>. The following example places a disk full threshold of one million bytes on the volume /home: DISK_FULL_VOLUME /home/1000000 For Windows, the form of the argument is <DRIVE>:\<limit>. The following example places a 1MB threshold on drive E: DISK_FULL_VOLUME e:\1048576 Note: When the disk is full the FairCom DB files cannot be extended. The c-tree operations that attempt to add or update data in a file and require the files to be extended will fail with specific errors. This diagnostic keyword is used to put supplemental information in the status file and alert the user. Default: Off See Also
|
4 GB-1 for platforms without native 64-bit integer support; otherwise 2^63-1 |
|
GUEST_MEMORY <bytes> If greater than zero, this is the memory usage limit in bytes for a user without a User ID (i.e., a GUEST user). Default: 0 |
2 GB-1 |
2^32-1 cache pages on 64-bit systems and 4 GB-1 on 32-bit systems (although we allow up to 4 GB-1, the O/S might impose a lower limit; it will appear as c-tree error 10 when starting FairCom Server) |
|
|
LIST_MEMORY <bytes> Indicates the size of the memory blocks that are allocated by FairCom Server for internal in-memory data structures. It does not represent the actual memory size of a specific table and/or structure. To conserve memory, this keyword can be set to a low value, such as 4096. In situations with large amounts of available memory, the value can be increased beyond the default up to the maximum limit. This can improve performance at the expense of increased memory usage. The vast majority of our customers never set this value to more than 1MB, which is a good compromise between memory usage and performance gains. Maximum: 10MB Default: 16384 |
1 MB |
LMT_MEMORY |
|
|
LOG_PAGE_SIZE <bytes> The FairCom Server uses a transaction log buffer to manage log write requests and this is comprised of a number of page size blocks. The LOG_PAGE_SIZE configuration key word is used to change the page size, and ideally, the log page size should match the optimal size for the disk I/O subsystem. The maximum setting is 32K. Default The default is 8K. See Also
|
32 KB |
|
LOG_SPACE <Megabytes> This is the number of megabytes of disk space allocated to storing active transaction logs, starting with a minimum of 2. The FairCom Server maintains up to 4 active log files, which consume, in the aggregate, up to LOG_SPACE megabytes of disk space. Log files are numbered consecutively starting with 1. The log file names are in the form L0000001.FCS. For a server with existing transaction logs, If LOG_SPACE is changed and LOG_TEMPLATE is non-zero, the existing log templates will be the wrong size and should be removed. The log template (L0000000.FCT) is only created when the Log # 1 is created, so the transaction log reset procedure should be followed. V12 Notes The maximum allowed value for the LOG_SPACE keyword has been increased from 1GB to 4GB-1. This controls the initial size of transaction logs (of 4 logs specifically), so each log can now grow to just under 1GB. Each individual log can now grow up to 4GB if needed, although 3GB is expected to be the largest size, which will be a 1GB normal log size, plus a potential 2GB variable-length record in a transaction. Reducing the number of logs results in less log file churning with high velocity applications leading to faster consistent transaction throughput. A change in logic allows us to avoid performing a long series of synchronous writes to the transaction log when we start the server in an empty transaction log directory. This change significantly speeds up server startup on Linux when the file system has write barriers enabled. Note: When write barriers are disabled on Linux, synchronous writes are much faster than with write barriers enabled, so FairCom highly recommends running with write barriers off and a battery backed power supply on the machine in production systems for best performance. With this performance improvement, we have been able to increase LOG_SPACE to 1 GB and we have COMPATIBILITY LOG_WRITETHRU on by default. The defaults in the Server Configuration File (ctsrvr.cfg) have been modified to optimize performance on modern systems.
LOG_SPACE 1 GB
PAGE_SIZE 32768 Warning: Changing the PAGE_SIZE is a maintenance task that should be done carefully and with a full reliable backup. Practice on a copy of your data and server folder until you are confident with the results. For procedures, see Adjusting PAGE_SIZE in the FairCom Installation Guide. Note: A file created with a larger PAGE_SIZE cannot be opened by a server with a smaller PAGE_SIZE.
Default: 1 GB (prior to V12: 120 MB) |
1 GB |
|
MAX_USER_LOGS <# of logs> An optional limit for how many active transaction logs a transaction spans before it is aborted or abandoned. The default, ZERO, disables the check for long transactions. When specified, MAX_USER_LOGS takes as its argument the maximum number of logs a transaction may span. If a transaction exceeds the limit, an attempt is made to abort the transaction. If the transaction cannot be aborted (consider the case where an abort would cause the server to fail), the transaction is abandoned. This means the client thread will lose its connection to the server, and the application may receive errors ARQS_ERR (127) or ARSP_ERR (128). There is no guarantee that a transaction will not span more logs than the specified maximum, however, the transaction will end within a reasonable number of logs. If the transaction is aborted, then the next call by the client will return error MLAB_ERR (821) to indicate the operation was not completed and the pending transaction has been aborted. (See the end note for a special case of this error condition.) A message of the following form will be made in CTSTATUS.FCS: Sun Dec 03 08:53:21 2006 - User# 00011 Transaction aborted at ct_mul_abandon1 for user# 9: 821 If the transaction is abandoned (that is, no explicit abort written in the log), then the client will be disconnected from the server. CTSTATUS.FCS entries such as the following reflect logs growing from a transaction that is pending, then the detection of the long transaction, then the eventual abandonment: Sun Dec 03 09:53:42 2006 - User# 00012 The number of active log files increased to: 5 Sun Dec 03 09:53:42 2006 - User# 00012 Transaction (started in log 1) still pending. User# 11 |GUEST|| Sun Dec 03 09:53:55 2006 - User# 00012 The number of active log files increased to: 6 Sun Dec 03 09:53:55 2006 - User# 00012 Abandoned Transaction Sun Dec 03 09:54:10 2006 - User# 00012 The number of active log files increased to: 7 Sun Dec 03 09:54:10 2006 - User# 00012 Abandoned Transaction2 Sun Dec 03 09:54:10 2006 - User# 00012 Abandoned transaction kill request posted against user #11 |GUEST|| Sun Dec 03 09:54:10 2006 - User# 00011 ctntio: send error - O11 bytes=0 pErr=127 |GUEST||: 168 Sun Dec 03 09:54:25 2006 - User# 00012 The number of active log files decreased to: 4 The number of logs continued to grow, and then shrink, as reflected in the above excerpt because in addition to a transaction sleeping on a blocked lock, another unrelated application was continuing to add records to its files and corresponding entries in the transaction logs. Note: In some rare situations error TRAB_COD (-823) can be returned instead of MLAB_ERR. This indicates the requested operation was completed before the abort actually took place. Usually, this is the same condition as an MLAB_ERR, as the transaction is aborted. In practice, the TRAB_COD should be rare. Default: 0 |
|
|
The FairCom Server supports creating memory files using a server configuration keyword. This feature allows developers to create memory files using their existing application code, provided that the file is created using an Xtd8 create function such as CreateIFileXtd8(). To create a memory file using the server configuration keyword, specify one or more entries of the form: MEMORY_FILE <file name>#<max size> where the file name may include wildcard characters (see FairCom DB Standard Wildcards) and the maximum size is optional. If no maximum size is specified, then 4GB is used. If a file is being created and matches one of the MEMORY_FILE file name entries, then it will be created as a memory file unless it is a superfile host, superfile member, mirrored, segmented or partitioned file. To cause all possible files to be created as memory files, add the following configuration entry: MEMORY_FILE * The MEMORY_FILE keyword is useful to quickly test how a file or set of files will behave as memory files. |
2^63 - 1 bytes on 64-bit systems and 4 GB - 1 on 32-bit systems |
|
MEMORY_MONITOR <Bytes | NO> Sends a message to the console whenever allocated memory exceeds the next memory threshold. The parameter specifies a size in bytes. For example, MEMORY_MONITOR 500000 sends a message every time memory consumption exceeds the next 500,000 byte range of memory. The message is also sent when memory usage decreases for each absolute memory block. This keyword should be used primarily for debugging, as there is some additional overhead for this feature. Default: NO |
|
|
MEMORY_TRACK <allocation threshold value> Sends debug output to the console every time the net memory allocation count changes by a multiple of the threshold value. The count is the number of memory allocation requests. See also DIAGNOSTICS TRACK_LOGON. DIAGNOSTICS TRACK_LOGON The DIAGNOSTICS TRACK_LOGON option provides a net count of memory allocation requests. This count is system wide, not just the particular process logging off or logging on and requires very little overhead. See also MEMORY_TRACK. Default: OFF Default: 0 (indicates do not track) |
|
64 KB |
|
|
The FairCom Server optionally maintains a list of data files and the number of bytes of data cache to be primed at file open. When priming cache, the server reads the specified number of bytes for the given data file into data cache when physically opening the data file. Data files are added to the priming list with configuration entries of the form: PRIME_CACHE <data file name>#<bytes primed> For example, the following keyword instructs the server to read the first 100,000 bytes of data records from customer.dat into the data cache at file open: PRIME_CACHE customer.dat#100000 A dedicated thread performs cache priming, permitting the file open call to return without waiting for the priming to be accomplished. Use PRIME_CACHE with the SPECIAL_CACHE_FILE keyword to load dedicated cache pages at file open. A <data file name> or <index file name> can be a wildcard specification using a ‘?’ for a single character and a ‘*’ for zero or more characters. See FairCom DB Standard Wildcards. Default: No priming See Also PRIME_INDEX (PRIME_INDEX, Prime Index) |
2^63 - 1 bytes on 64-bit systems and 4 GB - 1 on 32-bit systems |
|
PRIME_CACHE_BY_KEY <data_file_name>#<data_record_bytes_to_prime>#<index_number> The PRIME_CACHE configuration option supports priming the data cache with the specified number of bytes of data from the specified data file, in physical order from the start of the data file. PRIME_CACHE_BY_KEY supports priming the data cache in forward AND reverse order by index.
Example PRIME_CACHE_BY_KEY mark.dat#100000000#-1 Primes up to 100,000,000 bytes from mark.dat reading by the first index in reverse key order. See Also |
2^63 - 1 bytes on 64-bit systems and 4 GB - 1 on 32-bit systems |
2^63 - 1 bytes on 64-bit systems and 4 GB - 1 on 32-bit systems |
|
QUERY_MEMORY |
|
|
SORT_MEMORY <bytes> Specifies the size of sort buffers used by the FairCom Server. To conserve memory, set this value to 8192 or 4096. If large amounts of memory are available, the value can be increased significantly beyond the default. This value must be less than the maximum segment size in segmented architectures. The SORT_MEMORY keyword specifies the memory size in bytes and can use the MB and GB keywords (unlike MAX_K_TO_USE). The maximum SORT_MEMORY value is:
As the SORT_MEMORY option is more intuitive, its use is recommended over MAX_K_TO_USE. (MAX_K_TO_USE remains available for backward compatibility). If both SORT_MEMORY and MAX_K_TO_USE are specified in ctsrvr.cfg, only the one that is specified last in the configuration file takes effect. Default: 100 MB See Also
|
4 TB - 1 for 64-bit FairCom DB; |
|
SPECIAL_CACHE_FILE <datafilename>#<bytes to cache> Note: This keyword was removed in V11 and later (notice this impacts c-treeRTG V2.0 and later). We are in the process of reintroducing this support into V12 (c-treeRTG V3.0). This keyword is still accepted by the parsing engine, and the Server engine will start, however the support is inactive so there are no benefits to adding this keyword at this time. Dedicates a specified amount of cache memory to a particular Extended data file. This allows the Server Administrator to specify files that are critical to maintain in cache memory at the expense of the “least-recently-used” (LRU) approach, where a new cache page replaces the LRU existing page. For example, the following keywords specify 100,000 bytes of dedicated cache for customer.dat and 400,000 bytes for data\inventory.dat: SPECIAL_CACHE_FILE customer.dat#100000 SPECIAL_CACHE_FILE data\inventory.dat#400000 The <datafilename> can be a wildcard specification using a ‘?’ for a single character and a ‘*’ for zero or more characters. See FairCom DB Standard Wildcards.
DATA_LRU_LISTS <number of lists> Note: The LRU algorithm is no longer used for the data cache. To reduce mutex contention, the cache control model permits the configuration keywords DATA_LRU_LISTS and INDEX_LRU_LISTS to specify how many LRU lists are maintained for data cache pages and index cache pages, respectively. INDEX_LRU_LISTS <number of lists> To reduce mutex contention, the new cache control model permits the configuration keywords DATA_LRU_LISTS and INDEX_LRU_LISTS to specify how many LRU lists are maintained for data cache pages and index cache pages, respectively. On Windows, Solaris, and AIX, the default is based on the number of available CPUs on the system and the CPU limit specified in the license file. Otherwise, INDEX_LRU_LISTS defaults to 4. See Also On Windows, Solaris, and AIX, the default is based on the number of available CPUs on the system and the CPU limit specified in the license file. Otherwise, DATA_LRU_LISTS defaults to 4. See Also Default: None See Also |
2^32-1 cache pages on 64-bit systems and 4 GB-1 on 32-bit systems |
TOT_MEMORY (deprecated) TOT_MEMORY <bytes> This keyword has been Deprecated. If greater than zero, the total number of bytes the system will attempt to allocate for all uses (including index and data caches specified by the IDX_MEMORY and DAT_MEMORY keywords). If the system usage exceeds this level, attempts will be made to reduce discretionary allocations. If zero, no memory limit is imposed. The TOT_MEMORY option will cause an operation to fail with an insufficient memory error such as TSHD_ERR (72) or QMEM_ERR (92) when the memory limit is reached. If this limit is exceeded, it may cause a user to flush preimage memory, but it will cause a TSHD_ERR (72) if the system limit is exceeded during preimage operations. Memory management attempts to permit the server to survive exceeding the optional TOT_MEMORY limit. Although every effort is made to avoid this situation, it is possible that using this option could cause FairCom Server to terminate if it needs memory in a critical situation and cannot get memory, even if memory is available on the system. For these reasons, the use of this option can be risky. Default: 0 See Also |
Note: TOT_MEMORY is a deprecated keyword. FairCom does not recommend setting a total memory limit. |
|
USR_MEMORY If greater than zero, this is the system default limit of memory (in bytes) available to each user. Zero means no user system default limit is imposed. The Administrator overrides this setting for a particular user by assigning a different value to the user or to the user’s primary Group. Default: 0 See Also
|
2 GB-1 |
The following keyword was not changed to support specifying a scaling factor:
XTDKSEG_SRC_SIZE
Note: An operating system might impose a lower limit on the amount of memory available to a process than the configuration option limits that the FairCom Server supports
Last modified: 4/19/2021 3:58:06 PM
