Re: LRUS vs. CLEANERS

In article <33219A97.790C0F1B@www.weideneder.de>, Stefan Weideneder <stefan@www.weideneder.de> writes >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 ). > I agree. >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. > Correct. >> 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 Generally you should have one chunk per disk, therefore since number of chunks = number of disks these two values are interchangable. >> --------------------------( Forwarded letter 1 follows )--------------------- > >LRUS = max( 4, NUMCPUVPS ) Correct.>CLEANERS = number of chunks, that you can/want parallel write to > ( not including Mirror Chunks ) > Correct - AIO VPS handle mirroring. >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 ) Correct - remember split reads occur with mirror chunks so include them as well. > ( else, if you are NOT using KAIO, set this value to > CLEANERS + number of read-only disks + Mirror disks ) i.e. number of physical disks since in the best case all disks are active and each corresponding AIO VP will be waiting for the corresponding disk I/O to complete. Note: if you have many disks then you should be using KAIO anyway. > > !!! Never leave NUMAIOVPS blank !!! > Correct. OWS 7.20.UC1 on Solaris 2.5 DID left NUMAIOVPS blank when I installed it (I think some default like 4 was used - can'r emember). >BUFFERS * LRU_MAX_DIRTY * avg( disk speed to write 1 page to disk ) should be >one in OLTP environments. > ??? I don't follow this perhaps you mean BUFFERS * (LRU_MA_DIRTY/100) i.e. max number of dirty pages to write --------------------------- ---------------------------------------- avg number of pages that can be written in parallel to disk should be close to 1 ?? >That's it. > >Bye > >Stefan -- David Williams