DownloadTranslators/performance
From GlusterDocumentation
All of the performance translators work when loaded on both the client side and server side.
This information is out of date
and does not contain information related to the current version of Gluster
Documentation Home
Translator performance/readahead
read-ahead pre-fetches a sequence of blocks in advance based on its predictions. When your application is busy crunching the data it has read, GlusterFS can pre-read the next batch of data and keep it ready to make consecutive reads faster. Additionally, the translator also behaves as a read-aggregator, that is, smaller I/O read operations are combined into fewer larger read operations internally to reduce network and disk load.
volume readahead type performance/read-ahead option page-count 4 # 2 is default option option force-atime-update off # default is off subvolumes <x> end-volume
- page-size
- page-count
- force-atime-update
The page size in which read-ahead breaks up read requests from the server. The default value is 128KB.
The maximum number of blocks to pre-fetch. This maximum value is reached only when the read pattern is sequential.
Keep the atime of the file up to date. The default is off (equivalent to mount -o noatime).
NOTE: This translator is best utilized with IB-verbs transport or with 10GbE interface. With FastEthernet and the GbE interface, without read-ahead, you can achieve link-max throughput.
This information is out of date
and does not contain information related to the current version of Gluster
Documentation Home
Translator performance/writebehind
In general, write operations are slower than read. The write-behind translator improves write performance significantly over read by using "aggregated background write" technique. That is, multiple smaller write operations are aggregated into fewer larger write operations and written in background (non-blocking). Write-behind on the client aggregates small writes into larger ones reducing network packet counts. On the server side, it helps if the writes are coming in very small chunks by reducing the diskhead seek() time.
volume writebehind type performance/write-behind option cache-size 3MB # default is equal to aggregate-size option flush-behind on # default is 'off' subvolumes <x> end-volume
- cache-size (or window-size)
This option determines the total size of write buffer used with one file descriptor. It is also known as cache-size.
- flush-behind
This option is also given for increasing the performance of handling lots of small files. With this option the close()/flush() can be pushed to the back-ground, allowing the client to process the next request. It's off by default.
- enable-O_SYNC
This option causes write-behind to be turned off for filehandles opened for synchronous writing with the O_SYNC flag. This allows you to benefit from write-behind for non-critical files without breaking applications such as DBMSs that rely on synchronous writes.
Translator performance/io-threads
IO-threads add asynchronous (background) file system operations. By loading this translator, you can utilize the server idle blocked time to handle new incoming requests. CPU, memory, and the network are not utilized when the server is blocked on read or write calls while doing direct memory access on disk. This translator makes the best use of all the resources under load and improves concurrent I/O performance.
volume iothreads type performance/io-threads option thread-count 8 # default is 16 subvolumes <x> end-volume
thread-count
Number of threads to keep in the thread pool.
Translator performance/io-cache
The IO-Cache translator is useful on both the client and server sides of a connection.
If this translator is loaded on the client side, it may help reduce the load on both the network and the server when the client is accessing files just for reading (and the files are not edited on the server between reads). This would, For example, greatly improve the compilation of a kernel where header files are accessed over and over.
If this translator is loaded on the server side, it will allow the server to keep data that is being accessed from multiple clients simultaneously fresh in its cache.
A sample IO-Cache config:
volume io-cache type performance/io-cache option cache-size 64MB # default is 32MB option priority *.h:3,*.html:2,*:1 # default is '*:0' option cache-timeout 2 # default is 1 second subvolumes <x> end-volume
- priority
Values must comprise of comma-separated <pattern>:<prio> tuples, where <pattern>s are like *.mpg format and <prio> is an integer.|| Assigns priority to filenames with specific patterns so that when a page needs to be ejected out of the cache, the page of a file whose priority is the lowest will be ejected earlier.
- cache-timeout (force-revalidate-timeout)
If the cached page for a file is greater than 'cache-timeout' seconds old, io-cache translator forces a re-validation of the page. However the cached page is verified against the mtime whenever possible and cache is refreshed. Default is 1 second.
- cache-size
Size of the IO cache. Specifies how much of read data can be cached. Default is 64MB.
