LRUS vs. CLEANERS
KENDRICKS.CHERYL@heb.com wrote:
>
> The number of Cleaner's does not only depend on the number of disk but also
> the the number of LRU Queues (LRU). You should then set you Cleaner value to
> the number of Disk that are updated during a checkpoint only if LRUS is not
> set to a higher value, otherwise use the same value that you have for LRU.
Please, tell me why it is better to have more cleaner processes than disks.
The default configuration for LRUS is 8 in all versions; for versions 6.x and
7.x Informix recommends 4 LRUS for up to 4 CPU-vp's. If you would have more than
4 CPU-vp's, a lower number of LRUS might cause a LRU-contention. Therefore you
should set the number of LRUS to the number of CPU-vp's, if you are using more
than 4 CPU-vp's.
A higher value for LRUS in version 5.x is also understandable because the
sqlturbo processes want to access the LRU-queues and temporary place an internal
lock on these queues. ( This is done by the sqlexec-threads inside the CPU-vp's
as well ).
Using version 5.x we talk about cleaner processes, in version 6.x and higher
we talk about cleaner threads that will communicate with either the AIO-vp's
or the kaio-threads. Anyway, most important is the number of open channels to
one and only one device. Unless your device consists of more than one disk
( like RAID systems or disk-arrays ) the best setting must be one I/O channel
per device.
If you would try to read or write to one disk with more than one process
( a single process can access only one disk at a time, unless it is using
the asynchronous kernel I/O ), this will take longer than with one process.
Once again, try to read 20MB from one disk using one process. Then try to
read 20MB from one disk with two processes, each process should read 10MB.
I'm quite sure that it will take at least 6 to 12 times longer if you would read
the data with two processes. This is true unless you are using a disk-array.
The reason is the disk positioning. UNIX will split the data that must be
read or written into several data blocks. Therefore this will cause disk
positioning and I believe that this is the most time consuming factor.
> But you should not add your chunks in successive order if the chunks will be
> spread across more then one disk. Due to Cleaner Performance reasons. For
> example:
>
> Let's say you will be creating 4 chunks that will be using two different disk.
> Then it is best to create chunks 1 and 3 on the same disk and 2 and 4 on the
> other. This only applies if the CLEANERS are still accessing the disk as they
> do in Online 5.X (which is in a round robin fashion). This also applies to
> how you should create your Logs.
That's right, but it's because you should avoid disk-positioning. The first
cleaner will clean the first chunk, the second one the second chunk. If both
chunks would be on the same disk this would cause the same disk-positioning
if you would install two cleaner processes.
When the first cleaner finishes it will look for the next chunk to clean.
> So essentially the number of chunks is not what you consider but the number of
> DISK and the VALUE of LRU.
>
> C.L. Kendricks
> vnibs2@heb.com
> --------------------------( Forwarded letter 1 follows )---------------------
LRUS = max( 4, NUMCPUVPS )CLEANERS = number of chunks, that you can/want parallel write to
( not including Mirror Chunks )
NUMAIOVPS = ( if you are using KAIO set this value to the number of
chunks ( only cooked files ), that you can parallel
read from/write to ) - including Mirror Chunks )
( else, if you are NOT using KAIO, set this value to
CLEANERS + number of read-only disks + Mirror disks )
!!! Never leave NUMAIOVPS blank !!!
BUFFERS * LRU_MAX_DIRTY * avg( disk speed to write 1 page to disk ) should be
one in OLTP environments.
That's it.
Bye
Stefan