LRU Queues - more or less
Jim asked whether, with few dirty buffers, it helps to cut LRU queues (128) or page cleaners (20), and how to balance uneven cleaner load. Art Kagel noted onstat -F showed 0 LRU writes and millions of chunk writes, meaning all flushing happens at checkpoints (lru_min_dirty 50% is never reached), so LRU queue count is irrelevant; at checkpoint cleaners are assigned per chunk (corrected from dbspace by Khaled Bentebal), and with ~10 one-chunk dbspaces only ~10 cleaners work. Adding a second chunk to a dbspace would let more cleaners work, but Art warned new extents go to the smallest fitting free space, so a new chunk stays mostly unused until the old one fills. No config change was reported as tested.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
These are two theoretical questions (based on a current situation)
1) Is it better to use fewer larger LRU queues or many small queues if there
are a small number of dirty buffers?
2) Is it better to use fewer cleaners and keep them active or is there a way
to balance cleaner load?
situation:
config:
IDS 11.70FC3 - Red Hat Linux VM/ ESX server
128 LRUs / 20 Cleaners / LOGBUFF 128k / PHYSBUF 128 k / CKPTINTVL 300 /
MIN MAX 50% 60%
usage:
max dirty buffers at checkpoint: 45000 (10% LRU usage)
onstat -F ==> 1-6 @2300 chunk, @430k wakeups, @430k idle
7-10 @1300 chunk, @430k wakeups, @430k idle
11-20 @0 chunk, @430k wakeups, @430k idle
(appox of course, but general idea shown)
1) since LRUs are very low and cleaners not being fully used, would it improve
performance to reduce LRUs to 28, giving flushers fewer LRUs to scan?
(assuming right now there is no need for flushing between checkpoints,
therefore no need to utilize MIN/MAX adjustments to reduce workload on
checkpoints)
2) is there any way to balance the load on the cleaners? If we were able to
make the other 10 cleaners do active work, would there be an increase in
performance/ throughput? If neither, is there benefit to reducing number of
cleaners (reduce spin waits)?
thanks in advance for the help.
--Jim
It looks like all of your cleaning is being performed at checkpoint time
since lru_min_dirty is 50% and you say they LRUs never get more than 10%
dirty. That means that LRU flushing is irrelevant. What does onstat -F
show - any LRU Flush activity versus Chunk Write activity?
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on my employer, Advanced DataTools, the IIUG, nor any
other organization with which I am associated either explicitly,
implicitly, or by inference. Neither do those opinions reflect those of
other individuals affiliated with any entity with which I am affiliated nor
those of the entities themselves.
On Wed, Jul 18, 2012 at 5:10 PM, JAMES ROTANTE
<jamesrotante@sprintmail.com>wrote:
> These are two theoretical questions (based on a current situation)
>
> 1) Is it better to use fewer larger LRU queues or many small queues if
> there
> are a small number of dirty buffers?
>
> 2) Is it better to use fewer cleaners and keep them active or is there a
> way
> to balance cleaner load?
>
> situation:
>
> config:
>
> IDS 11.70FC3 - Red Hat Linux VM/ ESX server
> 128 LRUs / 20 Cleaners / LOGBUFF 128k / PHYSBUF 128 k / CKPTINTVL 300 /
> MIN MAX 50% 60%
> usage:
> max dirty buffers at checkpoint: 45000 (10% LRU usage)
> onstat -F ==> 1-6 @2300 chunk, @430k wakeups, @430k idle>
> 7-10 @1300 chunk, @430k wakeups, @430k idle
>
> 11-20 @0 chunk, @430k wakeups, @430k idle
> (appox of course, but general idea shown)
>
> 1) since LRUs are very low and cleaners not being fully used, would it
> improve
> performance to reduce LRUs to 28, giving flushers fewer LRUs to scan?
>
> (assuming right now there is no need for flushing between checkpoints,
> therefore no need to utilize MIN/MAX adjustments to reduce workload on
> checkpoints)
>
> 2) is there any way to balance the load on the cleaners? If we were able to
> make the other 10 cleaners do active work, would there be an increase in
> performance/ throughput? If neither, is there benefit to reducing number of
> cleaners (reduce spin waits)?
>
> thanks in advance for the help.
>
> --Jim
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--14dae9340445545b3f04c522201c
onstat -F shows 0 LRU Writes
onstat -F shows
0 LRU Writes
8314165 Chunk Writes
Exactly, you are running 100% checkpoint or chunk writes so the number of
LRU queues is not relevant to flush times. At checkpoint time IDS flushes
by assigning one cleaner thread to each dbspace until it runs out of
cleaner threads. The remaining dbspaces wait for the ones already being
flushed to complete.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on my employer, Advanced DataTools, the IIUG, nor any
other organization with which I am associated either explicitly,
implicitly, or by inference. Neither do those opinions reflect those of
other individuals affiliated with any entity with which I am affiliated nor
those of the entities themselves.
On Thu, Jul 19, 2012 at 1:48 PM, JAMES ROTANTE
<jamesrotante@sprintmail.com>wrote:
> onstat -F shows 0 LRU Writes>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--14dae9340cada1d26504c53272a4
Art,
Isn't the page cleaner assigned to a chunk rather than a dbspace at
checkpoint time ?
Cordialement, Regards,
Khaled Bentebal
Directeur Général - ConsultiX
Président UGIF - User Group Informix France
IIUG - Board of Directors
Tél: 33 (0) 1 39 12 18 00
Fax: 33 (0) 1 39 12 18 18
Mobile: 33 (0) 6 07 78 41 97
Email: khaled.bentebal@consult-ix.fr
Site Web: www.consult-ix.fr
Le 19/07/12 19:52, Art Kagel a écrit :
> Exactly, you are running 100% checkpoint or chunk writes so the number of
> LRU queues is not relevant to flush times. At checkpoint time IDS flushes
> by assigning one cleaner thread to each dbspace until it runs out of
> cleaner threads. The remaining dbspaces wait for the ones already being
> flushed to complete.
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.com)
> Blog: http://informix-myview.blogspot.com/
>
> Disclaimer: Please keep in mind that my own opinions are my own opinions
> and do not reflect on my employer, Advanced DataTools, the IIUG, nor any
> other organization with which I am associated either explicitly,
> implicitly, or by inference. Neither do those opinions reflect those of
> other individuals affiliated with any entity with which I am affiliated nor
> those of the entities themselves.
>
> On Thu, Jul 19, 2012 at 1:48 PM, JAMES ROTANTE
> <jamesrotante@sprintmail.com>wrote:
>
>> onstat -F shows 0 LRU Writes>>
>>
>>
>>
>
*******************************************************************************
>> Forum Note: Use "Reply" to post a response in the discussion forum.
>>
>>
> --14dae9340cada1d26504c53272a4
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
Yes, you are correct. Cleaners are assigned to chunks at checkpoint time.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on my employer, Advanced DataTools, the IIUG, nor any
other organization with which I am associated either explicitly,
implicitly, or by inference. Neither do those opinions reflect those of
other individuals affiliated with any entity with which I am affiliated nor
those of the entities themselves.
On Thu, Jul 19, 2012 at 3:12 PM, Khaled Bentebal <
khaled.bentebal@consult-ix.fr> wrote:
> Art,
>
> Isn't the page cleaner assigned to a chunk rather than a dbspace at
> checkpoint time ?
>
> Cordialement, Regards,
>
> Khaled Bentebal
> Directeur Général - ConsultiX
> Président UGIF - User Group Informix France
> IIUG - Board of Directors
> Tél: 33 (0) 1 39 12 18 00
> Fax: 33 (0) 1 39 12 18 18
> Mobile: 33 (0) 6 07 78 41 97
> Email: khaled.bentebal@consult-ix.fr
> Site Web: www.consult-ix.fr
>
> Le 19/07/12 19:52, Art Kagel a écrit :
> > Exactly, you are running 100% checkpoint or chunk writes so the number of
> > LRU queues is not relevant to flush times. At checkpoint time IDS flushes
> > by assigning one cleaner thread to each dbspace until it runs out of
> > cleaner threads. The remaining dbspaces wait for the ones already being
> > flushed to complete.
> >
> > Art
> >
> > Art S. Kagel
> > Advanced DataTools (www.advancedatatools.com)
> > Blog: http://informix-myview.blogspot.com/
> >
> > Disclaimer: Please keep in mind that my own opinions are my own opinions
> > and do not reflect on my employer, Advanced DataTools, the IIUG, nor any
> > other organization with which I am associated either explicitly,
> > implicitly, or by inference. Neither do those opinions reflect those of
> > other individuals affiliated with any entity with which I am affiliated
> nor
> > those of the entities themselves.
> >
> > On Thu, Jul 19, 2012 at 1:48 PM, JAMES ROTANTE
> > <jamesrotante@sprintmail.com>wrote:
> >
> >> onstat -F shows 0 LRU Writes> >>
> >>
> >>
> >>
> >
>
>
*******************************************************************************
> >> Forum Note: Use "Reply" to post a response in the discussion forum.
> >>
> >>
> > --14dae9340cada1d26504c53272a4
> >
> >
> >
>
>
*******************************************************************************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--14dae9340525d71b4804c5339c90
which makes sense because setup is roughly one chunk/ dbspace (and there are 10 dbspaces) so followup thought... normally, fragmentation strategies would intelligently fragment data over multiple dbspaces (chunks) to create parallel i/o capabilities commesurate with data usage. assuming creating fragmentation strategies was too large a project to assume at this time.. if a second chunk was added to a dbspace, would informix automatically make use of the second chunk path and utilize the additional flushers, by creating any new extents in the second chunk space, even if there was still available space in the original chunk?
Yes, cleaners would clean the additional chunks. No, space is allocated by finding the smallest block of free space in the dbspace that is at least as large as the required extent. So, as long as the new extent will fit in the older chunks the new one will go mostly unused. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Thu, Jul 19, 2012 at 4:53 PM, JAMES ROTANTE <jamesrotante@sprintmail.com>wrote: > which makes sense because setup is roughly one chunk/ dbspace (and there > are > 10 dbspaces) > > so followup thought... > > normally, fragmentation strategies would intelligently fragment data over > multiple dbspaces (chunks) to create parallel i/o capabilities commesurate > with data usage. > > assuming creating fragmentation strategies was too large a project to > assume > at this time.. > > if a second chunk was added to a dbspace, would informix automatically make > use of the second chunk path and utilize the additional flushers, by > creating > any new extents in the second chunk space, even if there was still > available > space in the original chunk? > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --bcaec5186a16e91b1204c53531b2
got it. thanks Art