IDS 7.31 Solaris8 - Long Checkpoints
A user on IDS 7.31.UD1 (Solaris 8, 2 CPUs, 4GB) saw checkpoints lasting over 60 seconds during heavy DML, and posted his ONCONFIG (BUFFERS 100000, LRUS 8, CLEANERS 8, LRU_MAX/MIN_DIRTY 5/2, NUMAIOVPS 1). Suggestions: lower LRU_MAX/MIN_DIRTY to 2/1, raise LRUS and CLEANERS (Art Kagel suggested ~128 each), and check with 'onstat -g iov' whether KAIO is really in use — with cooked chunks a single AIO VP would be a major cause, so add more. Kate suggested raising CKPTINTVL, which Art opposed as risking a full physical log; another poster's advice to add buffers was also disputed. The OP never reported back, so no resolution is recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Hello,
We are running IDS7.31 UD1 on a Solaris8 server with 2 Sparc64 processors and
4GB RAM.
It is used for interactive and batch processing.
When lots of manipulations on the DB are done, it takes sometimes more than 60
seconds to do his checkpoints.
Some parameters of our config file:
MULTIPROCESSOR 1
NUMCPUVPS 2
SINGLE_CPU_VP 0
NOAGE 1
AFF_SPROC 0
AFF_NPROCS 0
LOCKS 700000
BUFFERS 100000
NUMAIOVPS 1
PHYSBUFF 64
LOGBUFF 64LOGSMAX 600
CLEANERS 8
CKPTINTVL 120
LRUS 8
LRU_MAX_DIRTY 5
LRU_MIN_DIRTY 2
Any idea how to speed up the checkpoints?
Kurt,
Are you having any problems with memory segments? Post your "onstat -g
seg"
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
KURT VAN GOMPEL
Sent: Monday, March 16, 2009 10:26 AM
To: ids@iiug.org
Subject: IDS 7.31 Solaris8 - Long Checkpoints [15147]
Hello,
We are running IDS7.31 UD1 on a Solaris8 server with 2 Sparc64
processors and
4GB RAM.
It is used for interactive and batch processing.
When lots of manipulations on the DB are done, it takes sometimes more
than 60
seconds to do his checkpoints.
Some parameters of our config file:
MULTIPROCESSOR 1
NUMCPUVPS 2
SINGLE_CPU_VP 0
NOAGE 1
AFF_SPROC 0
AFF_NPROCS 0
LOCKS 700000
BUFFERS 100000
NUMAIOVPS 1
PHYSBUFF 64
LOGBUFF 64LOGSMAX 600
CLEANERS 8
CKPTINTVL 120
LRUS 8
LRU_MAX_DIRTY 5
LRU_MIN_DIRTY 2
Any idea how to speed up the checkpoints?
************************************************************************
*******
Forum Note: Use "Reply" to post a response in the discussion forum.
Hello,
Here's the output op onstat -g seg:
Informix Dynamic Server Version 7.31.UD1 -- On-Line -- Up 10:22:10 -- 412752
Kbytes
Segment Summary:
id key addr size ovhd class blkused blkfree
94000 1394493441 a000000 268435456 24820 R* 31026 1742
94001 1394493442 1a000000 153600000 2948 V 9760 8990
94002 1394493443 2327c000 622592 616 M 75 1
Total: - - 422658048 - - 40861 10733
(* segment locked in memory)
More LRUS (suggest 128) more CLEANERS (also 128) and lower LRI_MIN/MAX_DIRTY
values (suggest 2/1 instead of 5/2).
Another option: Upgrade to IDS 11.50 which finally has non-blocking
checkpoints and autonomic checkpoint tuning.
Art
On Mon, Mar 16, 2009 at 11:26 AM, KURT VAN GOMPEL <
kvangompel@caami-hziv.fgov.be> wrote:
> Hello,
>
> We are running IDS7.31 UD1 on a Solaris8 server with 2 Sparc64 processors
> and
> 4GB RAM.
> It is used for interactive and batch processing.
> When lots of manipulations on the DB are done, it takes sometimes more than
> 60
> seconds to do his checkpoints.
> Some parameters of our config file:
> MULTIPROCESSOR 1
> NUMCPUVPS 2
> SINGLE_CPU_VP 0
> NOAGE 1
> AFF_SPROC 0
> AFF_NPROCS 0
> LOCKS 700000
> BUFFERS 100000
> NUMAIOVPS 1
> PHYSBUFF 64
> LOGBUFF 64> LOGSMAX 600
> CLEANERS 8
> CKPTINTVL 120
> LRUS 8
> LRU_MAX_DIRTY 5
> LRU_MIN_DIRTY 2>
> Any idea how to speed up the checkpoints?
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--
Art S. Kagel
Oninit (www.oninit.com)
IIUG Board of Directors (art@iiug.org)
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Oninit, the IIUG, nor any other organization
with which I am associated either explicitly or implicitly. Neither do
those opinions reflect those of other individuals affiliated with any entity
with which I am affiliated nor those of the entities themselves.
--0016364edc32e773e804653e6cf1
Kurt,
It's cool you're not taking more virtual memory segs to get the work
done (only 1 "V" in your onstat -g seg output).
Your engine is only sized to about 413MB, while you said you have 4GB
RAM on the server.
In addition to Art Kagel's suggestion he just saw posted....
Try increasing your buffers... what else is running on the server?...
increasing buffers is the main thing that will increase the size of your
Informix engine... you're on a 7.31 (32bit) engine ... you could max
the Informix engine up to about 3.75GB I think... you don't have to go
for the full max, but at least double it to about 1 GB instead of the
413MB you have now.
Thanks,
Norma Jean Sebastian
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
KURT VAN GOMPEL
Sent: Monday, March 16, 2009 10:36 AM
To: ids@iiug.org
Subject: Re: RE: IDS 7.31 Solaris8 - Long Checkpoints [15149]
Hello,
Here's the output op onstat -g seg:
Informix Dynamic Server Version 7.31.UD1 -- On-Line -- Up 10:22:10 --
412752
Kbytes
Segment Summary:
id key addr size ovhd class blkused blkfree
94000 1394493441 a000000 268435456 24820 R* 31026 1742
94001 1394493442 1a000000 153600000 2948 V 9760 8990
94002 1394493443 2327c000 622592 616 M 75 1
Total: - - 422658048 - - 40861 10733
(* segment locked in memory)
Hello,
We are running IDS7.31 UD1 on a Solaris8 server with 2 Sparc64
processors and 4GB RAM.
It is used for interactive and batch processing.
When lots of manipulations on the DB are done, it takes sometimes more
than 60 seconds to do his checkpoints.
Some parameters of our config file:
MULTIPROCESSOR 1
NUMCPUVPS 2
SINGLE_CPU_VP 0
NOAGE 1
AFF_SPROC 0
AFF_NPROCS 0
LOCKS 700000
BUFFERS 100000
NUMAIOVPS 1
PHYSBUFF 64
LOGBUFF 64LOGSMAX 600
CLEANERS 8
CKPTINTVL 120
LRUS 8
LRU_MAX_DIRTY 5
LRU_MIN_DIRTY 2Any idea how to speed up the checkpoints?
To shorten checkpoints in version 7.31 you should
1) increase the checpoint interval to 500sec (you don't want the interval to
ever force the checkpoint)
2) lower the lru_max_dirty to 2
3) lower the lru_min_dirty to 1
Try this out.
I assume you are using KAIO and that is why the NUMAIOVP is set to 1? Do an
>onstat -g iov to verify this.
Thanks!
Kate Tomchik [ kate@iiug.org ] www.iiug.org
International Informix Users Group Board of Directors
A computer lets you make more mistakes faster than any invention in human
history - with the possible exceptions of handguns and tequila.
Mitch Ratliffe
---------- Original Message -----------
From: "KURT VAN GOMPEL" <kvangompel@caami-hziv.fgov.be>
To: ids@iiug.org
Sent: Mon, 16 Mar 2009 11:26:19 -0400 (EDT)
Subject: IDS 7.31 Solaris8 - Long Checkpoints [15147]
> Hello,
>
> We are running IDS7.31 UD1 on a Solaris8 server with 2 Sparc64
> processors and 4GB RAM. It is used for interactive and batch
> processing. When lots of manipulations on the DB are done, it takes
> sometimes more than 60 seconds to do his checkpoints. Some
> parameters of our config file: MULTIPROCESSOR 1 NUMCPUVPS 2
> SINGLE_CPU_VP 0 NOAGE 1 AFF_SPROC 0 AFF_NPROCS 0 LOCKS 700000
> BUFFERS 100000 NUMAIOVPS 1 PHYSBUFF 64 LOGBUFF 64 LOGSMAX 600
> CLEANERS 8 CKPTINTVL 120 LRUS 8 LRU_MAX_DIRTY 5 LRU_MIN_DIRTY 2
>
> Any idea how to speed up the checkpoints?
>
>
*****************************************************************************
** Forum Note: Use "Reply" to post a response in the discussion forum.
------- End of Original Message -------
No NJ, that would be changing too many things at once. Even Art has too
many. For starters just change what I said, bounce you engine, and see what
your results are.
Changing buffers often causes a retune of the whole environment. I agree he
could be using many more, but lets focus on the current problem first.
Thanks!
Kate Tomchik [ kate@iiug.org ] www.iiug.org
International Informix Users Group Board of Directors
A computer lets you make more mistakes faster than any invention in human
history - with the possible exceptions of handguns and tequila.
Mitch Ratliffe
---------- Original Message -----------
From: "Norma Jean Sebastian" <nsebastian@flinnsci.com>
To: ids@iiug.org
Sent: Mon, 16 Mar 2009 11:56:55 -0400 (EDT)
Subject: RE: RE: IDS 7.31 Solaris8 - Long Checkpoints [15154]
> Kurt,
> It's cool you're not taking more virtual memory segs to get the work
> done (only 1 "V" in your onstat -g seg output).
> Your engine is only sized to about 413MB, while you said you have
> 4GB RAM on the server.
>
> In addition to Art Kagel's suggestion he just saw posted....
> Try increasing your buffers... what else is running on the
> server?... increasing buffers is the main thing that will increase
> the size of your Informix engine... you're on a 7.31 (32bit) engine
> ... you could max the Informix engine up to about 3.75GB I think...
> you don't have to go for the full max, but at least double it to
> about 1 GB instead of the 413MB you have now.
>
> Thanks,
> Norma Jean Sebastian
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf
> Of KURT VAN GOMPEL Sent: Monday, March 16, 2009 10:36 AM To:
> ids@iiug.org Subject: Re: RE: IDS 7.31 Solaris8 - Long Checkpoints
> [15149]
>
> Hello,
>
> Here's the output op onstat -g seg:
>
> Informix Dynamic Server Version 7.31.UD1 -- On-Line -- Up 10:22:10 --
> 412752 Kbytes
>
> Segment Summary:
> id key addr size ovhd class blkused blkfree
> 94000 1394493441 a000000 268435456 24820 R* 31026 1742
> 94001 1394493442 1a000000 153600000 2948 V 9760 8990
> 94002 1394493443 2327c000 622592 616 M 75 1
> Total: - - 422658048 - - 40861 10733
>
> (* segment locked in memory)
>
> Hello,
> We are running IDS7.31 UD1 on a Solaris8 server with 2 Sparc64
> processors and 4GB RAM.
> It is used for interactive and batch processing.
> When lots of manipulations on the DB are done, it takes sometimes
> more than 60 seconds to do his checkpoints. Some parameters of our
> config file: MULTIPROCESSOR 1 NUMCPUVPS 2 SINGLE_CPU_VP 0 NOAGE 1
> AFF_SPROC 0 AFF_NPROCS 0 LOCKS 700000 BUFFERS 100000 NUMAIOVPS 1
> PHYSBUFF 64 LOGBUFF 64 LOGSMAX 600 CLEANERS 8 CKPTINTVL 120 LRUS 8
> LRU_MAX_DIRTY 5 LRU_MIN_DIRTY 2 Any idea how to speed up the
> checkpoints?
>
>
*****************************************************************************
** Forum Note: Use "Reply" to post a response in the discussion forum.
------- End of Original Message -------
I have to disagree with both of your suggestins Kate. Increasing buffers
will only increase the number of dirty buffers at checkpoint time making the
checkpoints even longer. Since the OP is using 7.31 he only has full
integer control of the LRU_MIN/MAX_DIRTY parameters, so 2/1 is as low as he
can go and changing the MIN from 2 to 1 will not help a whole lot if they
are increasing BUFFERS to boot. Now you may be right that the instance is
too small and they could use more buffers to make EVERYTHING run better and
faster, but that's not going to help the checkpoint duration at all.
Your the ideas in your other post I'll address there.
Art
On Mon, Mar 16, 2009 at 12:24 PM, kate <kate@iiug.org> wrote:
> No NJ, that would be changing too many things at once. Even Art has too
> many. For starters just change what I said, bounce you engine, and see what
> your results are.
>
> Changing buffers often causes a retune of the whole environment. I agree he
> could be using many more, but lets focus on the current problem first.
>
> Thanks!
> Kate Tomchik [ kate@iiug.org ] www.iiug.org
> International Informix Users Group Board of Directors
>
> A computer lets you make more mistakes faster than any invention in human
> history - with the possible exceptions of handguns and tequila.
> Mitch Ratliffe
>
> ---------- Original Message -----------
> From: "Norma Jean Sebastian" <nsebastian@flinnsci.com>
> To: ids@iiug.org
> Sent: Mon, 16 Mar 2009 11:56:55 -0400 (EDT)
> Subject: RE: RE: IDS 7.31 Solaris8 - Long Checkpoints [15154]
>
> > Kurt,
> > It's cool you're not taking more virtual memory segs to get the work
> > done (only 1 "V" in your onstat -g seg output).
> > Your engine is only sized to about 413MB, while you said you have
> > 4GB RAM on the server.
> >
> > In addition to Art Kagel's suggestion he just saw posted....
> > Try increasing your buffers... what else is running on the
> > server?... increasing buffers is the main thing that will increase
> > the size of your Informix engine... you're on a 7.31 (32bit) engine
> > ... you could max the Informix engine up to about 3.75GB I think...
> > you don't have to go for the full max, but at least double it to
> > about 1 GB instead of the 413MB you have now.
> >
> > Thanks,
> > Norma Jean Sebastian
> >
> > -----Original Message-----
> > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf
> > Of KURT VAN GOMPEL Sent: Monday, March 16, 2009 10:36 AM To:
> > ids@iiug.org Subject: Re: RE: IDS 7.31 Solaris8 - Long Checkpoints
> > [15149]
> >
> > Hello,
> >
> > Here's the output op onstat -g seg:
> >
> > Informix Dynamic Server Version 7.31.UD1 -- On-Line -- Up 10:22:10 --
> > 412752 Kbytes
> >
> > Segment Summary:
> > id key addr size ovhd class blkused blkfree
> > 94000 1394493441 a000000 268435456 24820 R* 31026 1742
> > 94001 1394493442 1a000000 153600000 2948 V 9760 8990
> > 94002 1394493443 2327c000 622592 616 M 75 1
> > Total: - - 422658048 - - 40861 10733
> >
> > (* segment locked in memory)
> >
> > Hello,
> > We are running IDS7.31 UD1 on a Solaris8 server with 2 Sparc64
> > processors and 4GB RAM.
> > It is used for interactive and batch processing.
> > When lots of manipulations on the DB are done, it takes sometimes
> > more than 60 seconds to do his checkpoints. Some parameters of our
> > config file: MULTIPROCESSOR 1 NUMCPUVPS 2 SINGLE_CPU_VP 0 NOAGE 1
> > AFF_SPROC 0 AFF_NPROCS 0 LOCKS 700000 BUFFERS 100000 NUMAIOVPS 1
> > PHYSBUFF 64 LOGBUFF 64 LOGSMAX 600 CLEANERS 8 CKPTINTVL 120 LRUS 8
> > LRU_MAX_DIRTY 5 LRU_MIN_DIRTY 2 Any idea how to speed up the
> > checkpoints?
> >
> >
>
> *****************************************************************************
> ** Forum Note: Use "Reply" to post a response in the discussion forum.
> ------- End of Original Message -------
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--
Art S. Kagel
Oninit (www.oninit.com)
IIUG Board of Directors (art@iiug.org)
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Oninit, the IIUG, nor any other organization
with which I am associated either explicitly or implicitly. Neither do
those opinions reflect those of other individuals affiliated with any entity
with which I am affiliated nor those of the entities themselves.
--001636427251eb776a04653f08bd
Comments below:
Art
On Mon, Mar 16, 2009 at 12:20 PM, kate <kate@iiug.org> wrote:
> To shorten checkpoints in version 7.31 you should
>
> 1) increase the checpoint interval to 500sec (you don't want the interval
> to
> ever force the checkpoint)
I STRONGLY disagree. You ONLY want your checkpoints triggered by the
CHKPTINTVL not by the physical log reaching 75%! Letting that failsafe
trigger regularly is dangerous. If the checkpoint is slow and the physical
log should fill to 100% before the checkpoint can clear it, the engine is at
risk for data loss if it crashes before the checkpoint completes. Since
many crashes, especially in older buggy versions like 7.31UD1 that the OP is
using, occur during periods of stress, you can't discount the danger.
>
>
> 2) lower the lru_max_dirty to 2
> 3) lower the lru_min_dirty to 1
I agree with this obviously, but, my point of increasing the number of LRUs
and CLEANERS is that if you are going to be flushing more frequently between
checkpoints you have to provide the resources to do that. Spreading the
buffers across more LRU queues will reduce the number of buffers that need
to be flushed at any one time spreading the overhead out more smoothly.
>
>
> Try this out.
>
> I assume you are using KAIO and that is why the NUMAIOVP is set to 1? Do an
> >onstat -g iov to verify this.
DAMN, I missed that. Good catch Kate. If the OP is using COOKED files,
then this may be the one BIGGEST cause for the slow checkpoints! In that
case, with 7.31, they should have at least 2 AIO VPs configured per chunk to
minimize checkpoint duration.
Even if he is not, he should have at least 2 and perhaps as many as 6 AIO
VPs just to handle cooked io to the message and console logs and other
similar IO (sqexplain files, etc.).
Art
>
>
> Thanks!
> Kate Tomchik [ kate@iiug.org ] www.iiug.org
> International Informix Users Group Board of Directors
>
> A computer lets you make more mistakes faster than any invention in human
> history - with the possible exceptions of handguns and tequila.
> Mitch Ratliffe
>
> ---------- Original Message -----------
> From: "KURT VAN GOMPEL" <kvangompel@caami-hziv.fgov.be>
> To: ids@iiug.org
> Sent: Mon, 16 Mar 2009 11:26:19 -0400 (EDT)
> Subject: IDS 7.31 Solaris8 - Long Checkpoints [15147]
>
> > Hello,
> >
> > We are running IDS7.31 UD1 on a Solaris8 server with 2 Sparc64
> > processors and 4GB RAM. It is used for interactive and batch
> > processing. When lots of manipulations on the DB are done, it takes
> > sometimes more than 60 seconds to do his checkpoints. Some
> > parameters of our config file: MULTIPROCESSOR 1 NUMCPUVPS 2
> > SINGLE_CPU_VP 0 NOAGE 1 AFF_SPROC 0 AFF_NPROCS 0 LOCKS 700000
> > BUFFERS 100000 NUMAIOVPS 1 PHYSBUFF 64 LOGBUFF 64 LOGSMAX 600
> > CLEANERS 8 CKPTINTVL 120 LRUS 8 LRU_MAX_DIRTY 5 LRU_MIN_DIRTY 2
> >
> > Any idea how to speed up the checkpoints?
> >
> >
>
> *****************************************************************************
> ** Forum Note: Use "Reply" to post a response in the discussion forum.
> ------- End of Original Message -------
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--
Art S. Kagel
Oninit (www.oninit.com)
IIUG Board of Directors (art@iiug.org)
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Oninit, the IIUG, nor any other organization
with which I am associated either explicitly or implicitly. Neither do
those opinions reflect those of other individuals affiliated with any entity
with which I am affiliated nor those of the entities themselves.
--0016364ee022480d3c04653f23a2
Too many cooks in the kitchen :-)
Thanks!
Kate Tomchik [ kate@iiug.org ] www.iiug.org
International Informix Users Group Board of Directors
A computer lets you make more mistakes faster than any invention in human
history - with the possible exceptions of handguns and tequila.
Mitch Ratliffe
---------- Original Message -----------
From: "Art Kagel" <art.kagel@gmail.com>
To: ids@iiug.org
Sent: Mon, 16 Mar 2009 12:42:42 -0400 (EDT)
Subject: Re: IDS 7.31 Solaris8 - Long Checkpoints [15161]
> Comments below:
>
> Art
>
> On Mon, Mar 16, 2009 at 12:20 PM, kate <kate@iiug.org> wrote:
>
> > To shorten checkpoints in version 7.31 you should
> >
> > 1) increase the checpoint interval to 500sec (you don't want the
interval
> > to
> > ever force the checkpoint)
>
> I STRONGLY disagree. You ONLY want your checkpoints triggered by the
> CHKPTINTVL not by the physical log reaching 75%! Letting that
> failsafe trigger regularly is dangerous. If the checkpoint is slow
> and the physical log should fill to 100% before the checkpoint can
> clear it, the engine is at risk for data loss if it crashes before
> the checkpoint completes. Since many crashes, especially in older
> buggy versions like 7.31UD1 that the OP is using, occur during
> periods of stress, you can't discount the danger.
>
> >
> >
> > 2) lower the lru_max_dirty to 2
> > 3) lower the lru_min_dirty to 1
>
> I agree with this obviously, but, my point of increasing the number
> of LRUs and CLEANERS is that if you are going to be flushing more
> frequently between checkpoints you have to provide the resources to
> do that. Spreading the buffers across more LRU queues will reduce
> the number of buffers that need to be flushed at any one time
> spreading the overhead out more smoothly.
>
> >
> >
> > Try this out.
> >
> > I assume you are using KAIO and that is why the NUMAIOVP is set to 1? Do
an
> > >onstat -g iov to verify this.>
> DAMN, I missed that. Good catch Kate. If the OP is using COOKED
> files, then this may be the one BIGGEST cause for the slow
> checkpoints! In that case, with 7.31, they should have at least 2
> AIO VPs configured per chunk to minimize checkpoint duration.
>
> Even if he is not, he should have at least 2 and perhaps as many as
> 6 AIO VPs just to handle cooked io to the message and console logs
> and other similar IO (sqexplain files, etc.).
>
> Art
>
> >
> >
> > Thanks!
> > Kate Tomchik [ kate@iiug.org ] www.iiug.org
> > International Informix Users Group Board of Directors
> >
> > A computer lets you make more mistakes faster than any invention in
human
> > history - with the possible exceptions of handguns and tequila.
> > Mitch Ratliffe
> >
> > ---------- Original Message -----------
> > From: "KURT VAN GOMPEL" <kvangompel@caami-hziv.fgov.be>
> > To: ids@iiug.org
> > Sent: Mon, 16 Mar 2009 11:26:19 -0400 (EDT)
> > Subject: IDS 7.31 Solaris8 - Long Checkpoints [15147]
> >
> > > Hello,
> > >
> > > We are running IDS7.31 UD1 on a Solaris8 server with 2 Sparc64
> > > processors and 4GB RAM. It is used for interactive and batch
> > > processing. When lots of manipulations on the DB are done, it takes
> > > sometimes more than 60 seconds to do his checkpoints. Some
> > > parameters of our config file: MULTIPROCESSOR 1 NUMCPUVPS 2
> > > SINGLE_CPU_VP 0 NOAGE 1 AFF_SPROC 0 AFF_NPROCS 0 LOCKS 700000
> > > BUFFERS 100000 NUMAIOVPS 1 PHYSBUFF 64 LOGBUFF 64 LOGSMAX 600
> > > CLEANERS 8 CKPTINTVL 120 LRUS 8 LRU_MAX_DIRTY 5 LRU_MIN_DIRTY 2
> > >
> > > Any idea how to speed up the checkpoints?
> > >
> > >
> >
> >
>
*****************************************************************************
> > ** Forum Note: Use "Reply" to post a response in the discussion forum.
> > ------- End of Original Message -------
> >
> >
> >
> >
>
*****************************************************************************
**
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --
> Art S. Kagel
> Oninit (www.oninit.com)
> IIUG Board of Directors (art@iiug.org)
>
> Disclaimer: Please keep in mind that my own opinions are my own
> opinions and do not reflect on my employer, Oninit, the IIUG, nor
> any other organization with which I am associated either explicitly
> or implicitly. Neither do those opinions reflect those of other
> individuals affiliated with any entity with which I am affiliated
> nor those of the entities themselves.
>
> --0016364ee022480d3c04653f23a2
>
>
*****************************************************************************
** Forum Note: Use "Reply" to post a response in the discussion forum.
------- End of Original Message -------
I never said to increase buffers, so we are agreeing. I said that IF YOU
DID you would need to retune everything.
Thanks!
Kate Tomchik [ kate@iiug.org ] www.iiug.org
International Informix Users Group Board of Directors
A computer lets you make more mistakes faster than any invention in human
history - with the possible exceptions of handguns and tequila.
Mitch Ratliffe
---------- Original Message -----------
From: "Art Kagel" <art.kagel@gmail.com>
To: ids@iiug.org
Sent: Mon, 16 Mar 2009 12:35:18 -0400 (EDT)
Subject: Re: RE: IDS 7.31 Solaris8 - Long Checkpoints [15159]
> I have to disagree with both of your suggestins Kate. Increasing
> buffers will only increase the number of dirty buffers at checkpoint
> time making the checkpoints even longer. Since the OP is using 7.31
> he only has full integer control of the LRU_MIN/MAX_DIRTY parameters,
> so 2/1 is as low as he can go and changing the MIN from 2 to 1 will
> not help a whole lot if they are increasing BUFFERS to boot. Now you
> may be right that the instance is too small and they could use more
> buffers to make EVERYTHING run better and faster, but that's not
> going to help the checkpoint duration at all.
>
> Your the ideas in your other post I'll address there.
>
> Art
>
> On Mon, Mar 16, 2009 at 12:24 PM, kate <kate@iiug.org> wrote:
>
> > No NJ, that would be changing too many things at once. Even Art has too
> > many. For starters just change what I said, bounce you engine, and see
what
> > your results are.
> >
> > Changing buffers often causes a retune of the whole environment. I agree
he
> > could be using many more, but lets focus on the current problem first.
> >
> > Thanks!
> > Kate Tomchik [ kate@iiug.org ] www.iiug.org
> > International Informix Users Group Board of Directors
> >
> > A computer lets you make more mistakes faster than any invention in
human
> > history - with the possible exceptions of handguns and tequila.
> > Mitch Ratliffe
> >
> > ---------- Original Message -----------
> > From: "Norma Jean Sebastian" <nsebastian@flinnsci.com>
> > To: ids@iiug.org
> > Sent: Mon, 16 Mar 2009 11:56:55 -0400 (EDT)
> > Subject: RE: RE: IDS 7.31 Solaris8 - Long Checkpoints [15154]
> >
> > > Kurt,
> > > It's cool you're not taking more virtual memory segs to get the work
> > > done (only 1 "V" in your onstat -g seg output).
> > > Your engine is only sized to about 413MB, while you said you have
> > > 4GB RAM on the server.
> > >
> > > In addition to Art Kagel's suggestion he just saw posted....
> > > Try increasing your buffers... what else is running on the
> > > server?... increasing buffers is the main thing that will increase
> > > the size of your Informix engine... you're on a 7.31 (32bit) engine
> > > ... you could max the Informix engine up to about 3.75GB I think...
> > > you don't have to go for the full max, but at least double it to
> > > about 1 GB instead of the 413MB you have now.
> > >
> > > Thanks,
> > > Norma Jean Sebastian
> > >
> > > -----Original Message-----
> > > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf
> > > Of KURT VAN GOMPEL Sent: Monday, March 16, 2009 10:36 AM To:
> > > ids@iiug.org Subject: Re: RE: IDS 7.31 Solaris8 - Long Checkpoints
> > > [15149]
> > >
> > > Hello,
> > >
> > > Here's the output op onstat -g seg:
> > >
> > > Informix Dynamic Server Version 7.31.UD1 -- On-Line -- Up 10:22:10 --
> > > 412752 Kbytes
> > >
> > > Segment Summary:
> > > id key addr size ovhd class blkused blkfree
> > > 94000 1394493441 a000000 268435456 24820 R* 31026 1742
> > > 94001 1394493442 1a000000 153600000 2948 V 9760 8990
> > > 94002 1394493443 2327c000 622592 616 M 75 1
> > > Total: - - 422658048 - - 40861 10733
> > >
> > > (* segment locked in memory)
> > >
> > > Hello,
> > > We are running IDS7.31 UD1 on a Solaris8 server with 2 Sparc64
> > > processors and 4GB RAM.
> > > It is used for interactive and batch processing.
> > > When lots of manipulations on the DB are done, it takes sometimes
> > > more than 60 seconds to do his checkpoints. Some parameters of our
> > > config file: MULTIPROCESSOR 1 NUMCPUVPS 2 SINGLE_CPU_VP 0 NOAGE 1
> > > AFF_SPROC 0 AFF_NPROCS 0 LOCKS 700000 BUFFERS 100000 NUMAIOVPS 1
> > > PHYSBUFF 64 LOGBUFF 64 LOGSMAX 600 CLEANERS 8 CKPTINTVL 120 LRUS 8
> > > LRU_MAX_DIRTY 5 LRU_MIN_DIRTY 2 Any idea how to speed up the
> > > checkpoints?
> > >
> > >
> >
> >
>
*****************************************************************************
> > ** Forum Note: Use "Reply" to post a response in the discussion forum.
> > ------- End of Original Message -------
> >
> >
> >
> >
>
*****************************************************************************
**
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --
> Art S. Kagel
> Oninit (www.oninit.com)
> IIUG Board of Directors (art@iiug.org)
>
> Disclaimer: Please keep in mind that my own opinions are my own
> opinions and do not reflect on my employer, Oninit, the IIUG, nor
> any other organization with which I am associated either explicitly
> or implicitly. Neither do those opinions reflect those of other
> individuals affiliated with any entity with which I am affiliated
> nor those of the entities themselves.
>
> --001636427251eb776a04653f08bd
>
>
*****************************************************************************
** Forum Note: Use "Reply" to post a response in the discussion forum.
------- End of Original Message -------
Sorry, someone did. My apologies.
Art
On Mon, Mar 16, 2009 at 12:47 PM, kate <kate@iiug.org> wrote:
> I never said to increase buffers, so we are agreeing. I said that IF YOU
> DID you would need to retune everything.
>
> Thanks!
> Kate Tomchik [ kate@iiug.org ] www.iiug.org
> International Informix Users Group Board of Directors
>
> A computer lets you make more mistakes faster than any invention in human
> history - with the possible exceptions of handguns and tequila.
> Mitch Ratliffe
>
> ---------- Original Message -----------
> From: "Art Kagel" <art.kagel@gmail.com>
> To: ids@iiug.org
> Sent: Mon, 16 Mar 2009 12:35:18 -0400 (EDT)
> Subject: Re: RE: IDS 7.31 Solaris8 - Long Checkpoints [15159]
>
> > I have to disagree with both of your suggestins Kate. Increasing
> > buffers will only increase the number of dirty buffers at checkpoint
> > time making the checkpoints even longer. Since the OP is using 7.31
> > he only has full integer control of the LRU_MIN/MAX_DIRTY parameters,
> > so 2/1 is as low as he can go and changing the MIN from 2 to 1 will
> > not help a whole lot if they are increasing BUFFERS to boot. Now you
> > may be right that the instance is too small and they could use more
> > buffers to make EVERYTHING run better and faster, but that's not
> > going to help the checkpoint duration at all.
> >
> > Your the ideas in your other post I'll address there.
> >
> > Art
> >
> > On Mon, Mar 16, 2009 at 12:24 PM, kate <kate@iiug.org> wrote:
> >
> > > No NJ, that would be changing too many things at once. Even Art has too
> > > many. For starters just change what I said, bounce you engine, and see
> what
> > > your results are.
> > >
> > > Changing buffers often causes a retune of the whole environment. I
> agree
> he
> > > could be using many more, but lets focus on the current problem first.
> > >
> > > Thanks!
> > > Kate Tomchik [ kate@iiug.org ] www.iiug.org
> > > International Informix Users Group Board of Directors
> > >
> > > A computer lets you make more mistakes faster than any invention in
> human
> > > history - with the possible exceptions of handguns and tequila.
> > > Mitch Ratliffe
> > >
> > > ---------- Original Message -----------
> > > From: "Norma Jean Sebastian" <nsebastian@flinnsci.com>
> > > To: ids@iiug.org
> > > Sent: Mon, 16 Mar 2009 11:56:55 -0400 (EDT)
> > > Subject: RE: RE: IDS 7.31 Solaris8 - Long Checkpoints [15154]
> > >
> > > > Kurt,
> > > > It's cool you're not taking more virtual memory segs to get the work
> > > > done (only 1 "V" in your onstat -g seg output).
> > > > Your engine is only sized to about 413MB, while you said you have
> > > > 4GB RAM on the server.
> > > >
> > > > In addition to Art Kagel's suggestion he just saw posted....
> > > > Try increasing your buffers... what else is running on the
> > > > server?... increasing buffers is the main thing that will increase
> > > > the size of your Informix engine... you're on a 7.31 (32bit) engine
> > > > ... you could max the Informix engine up to about 3.75GB I think...
> > > > you don't have to go for the full max, but at least double it to
> > > > about 1 GB instead of the 413MB you have now.
> > > >
> > > > Thanks,
> > > > Norma Jean Sebastian
> > > >
> > > > -----Original Message-----
> > > > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf
> > > > Of KURT VAN GOMPEL Sent: Monday, March 16, 2009 10:36 AM To:
> > > > ids@iiug.org Subject: Re: RE: IDS 7.31 Solaris8 - Long Checkpoints
> > > > [15149]
> > > >
> > > > Hello,
> > > >
> > > > Here's the output op onstat -g seg:
> > > >
> > > > Informix Dynamic Server Version 7.31.UD1 -- On-Line -- Up 10:22:10 --
> > > > 412752 Kbytes
> > > >
> > > > Segment Summary:
> > > > id key addr size ovhd class blkused blkfree
> > > > 94000 1394493441 a000000 268435456 24820 R* 31026 1742
> > > > 94001 1394493442 1a000000 153600000 2948 V 9760 8990
> > > > 94002 1394493443 2327c000 622592 616 M 75 1
> > > > Total: - - 422658048 - - 40861 10733
> > > >
> > > > (* segment locked in memory)
> > > >
> > > > Hello,
> > > > We are running IDS7.31 UD1 on a Solaris8 server with 2 Sparc64
> > > > processors and 4GB RAM.
> > > > It is used for interactive and batch processing.
> > > > When lots of manipulations on the DB are done, it takes sometimes
> > > > more than 60 seconds to do his checkpoints. Some parameters of our
> > > > config file: MULTIPROCESSOR 1 NUMCPUVPS 2 SINGLE_CPU_VP 0 NOAGE 1
> > > > AFF_SPROC 0 AFF_NPROCS 0 LOCKS 700000 BUFFERS 100000 NUMAIOVPS 1
> > > > PHYSBUFF 64 LOGBUFF 64 LOGSMAX 600 CLEANERS 8 CKPTINTVL 120 LRUS 8
> > > > LRU_MAX_DIRTY 5 LRU_MIN_DIRTY 2 Any idea how to speed up the
> > > > checkpoints?
> > > >
> > > >
> > >
> > >
> >
>
> *****************************************************************************
>
> > > ** Forum Note: Use "Reply" to post a response in the discussion forum.
> > > ------- End of Original Message -------
> > >
> > >
> > >
> > >
> >
>
> *****************************************************************************
> **
> > > Forum Note: Use "Reply" to post a response in the discussion forum.
> > >
> > >
> >
> > --
> > Art S. Kagel
> > Oninit (www.oninit.com)
> > IIUG Board of Directors (art@iiug.org)
> >
> > Disclaimer: Please keep in mind that my own opinions are my own
> > opinions and do not reflect on my employer, Oninit, the IIUG, nor
> > any other organization with which I am associated either explicitly
> > or implicitly. Neither do those opinions reflect those of other
> > individuals affiliated with any entity with which I am affiliated
> > nor those of the entities themselves.
> >
> > --001636427251eb776a04653f08bd
> >
> >
>
> *****************************************************************************
> ** Forum Note: Use "Reply" to post a response in the discussion forum.
> ------- End of Original Message -------
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--
Art S. Kagel
Oninit (www.oninit.com)
IIUG Board of Directors (art@iiug.org)
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Oninit, the IIUG, nor any other organization
with which I am associated either explicitly or implicitly. Neither do
those opinions reflect those of other individuals affiliated with any entity
with which I am affiliated nor those of the entities themselves.
--0016368324ea8b947104653f4bcb
I did.
It is an option, and I most certainly didn't mean to change several
parameters at the same time. I assumed it was common knowledge to tweak
one thing at a time...
Sorry.
NJ
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
Art Kagel
Sent: Monday, March 16, 2009 11:54 AM
To: ids@iiug.org
Subject: Re: RE: IDS 7.31 Solaris8 - Long Checkpoints [15164]
Sorry, someone did. My apologies.
Art
On Mon, Mar 16, 2009 at 12:47 PM, kate <kate@iiug.org> wrote:
> I never said to increase buffers, so we are agreeing. I said that IF
YOU
> DID you would need to retune everything.
>
> Thanks!
> Kate Tomchik [ kate@iiug.org ] www.iiug.org
> International Informix Users Group Board of Directors
>
> A computer lets you make more mistakes faster than any invention in
human
> history - with the possible exceptions of handguns and tequila.
> Mitch Ratliffe
>
> ---------- Original Message -----------
> From: "Art Kagel" <art.kagel@gmail.com>
> To: ids@iiug.org
> Sent: Mon, 16 Mar 2009 12:35:18 -0400 (EDT)
> Subject: Re: RE: IDS 7.31 Solaris8 - Long Checkpoints [15159]
>
> > I have to disagree with both of your suggestins Kate. Increasing
> > buffers will only increase the number of dirty buffers at checkpoint
> > time making the checkpoints even longer. Since the OP is using 7.31
> > he only has full integer control of the LRU_MIN/MAX_DIRTY
parameters,
> > so 2/1 is as low as he can go and changing the MIN from 2 to 1 will
> > not help a whole lot if they are increasing BUFFERS to boot. Now you
> > may be right that the instance is too small and they could use more
> > buffers to make EVERYTHING run better and faster, but that's not
> > going to help the checkpoint duration at all.
> >
> > Your the ideas in your other post I'll address there.
> >
> > Art
> >
> > On Mon, Mar 16, 2009 at 12:24 PM, kate <kate@iiug.org> wrote:
> >
> > > No NJ, that would be changing too many things at once. Even Art
has too
> > > many. For starters just change what I said, bounce you engine, and
see
> what
> > > your results are.
> > >
> > > Changing buffers often causes a retune of the whole environment. I
> agree
> he
> > > could be using many more, but lets focus on the current problem
first.
> > >
> > > Thanks!
> > > Kate Tomchik [ kate@iiug.org ] www.iiug.org
> > > International Informix Users Group Board of Directors
> > >
> > > A computer lets you make more mistakes faster than any invention
in
> human
> > > history - with the possible exceptions of handguns and tequila.
> > > Mitch Ratliffe
> > >
> > > ---------- Original Message -----------
> > > From: "Norma Jean Sebastian" <nsebastian@flinnsci.com>
> > > To: ids@iiug.org
> > > Sent: Mon, 16 Mar 2009 11:56:55 -0400 (EDT)
> > > Subject: RE: RE: IDS 7.31 Solaris8 - Long Checkpoints [15154]
> > >
> > > > Kurt,
> > > > It's cool you're not taking more virtual memory segs to get the
work
> > > > done (only 1 "V" in your onstat -g seg output).
> > > > Your engine is only sized to about 413MB, while you said you
have
> > > > 4GB RAM on the server.
> > > >
> > > > In addition to Art Kagel's suggestion he just saw posted....
> > > > Try increasing your buffers... what else is running on the
> > > > server?... increasing buffers is the main thing that will
increase
> > > > the size of your Informix engine... you're on a 7.31 (32bit)
engine
> > > > ... you could max the Informix engine up to about 3.75GB I
think...
> > > > you don't have to go for the full max, but at least double it to
> > > > about 1 GB instead of the 413MB you have now.
> > > >
> > > > Thanks,
> > > > Norma Jean Sebastian
> > > >
> > > > -----Original Message-----
> > > > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On
Behalf
> > > > Of KURT VAN GOMPEL Sent: Monday, March 16, 2009 10:36 AM To:
> > > > ids@iiug.org Subject: Re: RE: IDS 7.31 Solaris8 - Long
Checkpoints
> > > > [15149]
> > > >
> > > > Hello,
> > > >
> > > > Here's the output op onstat -g seg:
> > > >
> > > > Informix Dynamic Server Version 7.31.UD1 -- On-Line -- Up
10:22:10 --
> > > > 412752 Kbytes
> > > >
> > > > Segment Summary:
> > > > id key addr size ovhd class blkused blkfree
> > > > 94000 1394493441 a000000 268435456 24820 R* 31026 1742
> > > > 94001 1394493442 1a000000 153600000 2948 V 9760 8990
> > > > 94002 1394493443 2327c000 622592 616 M 75 1
> > > > Total: - - 422658048 - - 40861 10733
> > > >
> > > > (* segment locked in memory)
> > > >
> > > > Hello,
> > > > We are running IDS7.31 UD1 on a Solaris8 server with 2 Sparc64
> > > > processors and 4GB RAM.
> > > > It is used for interactive and batch processing.
> > > > When lots of manipulations on the DB are done, it takes
sometimes
> > > > more than 60 seconds to do his checkpoints. Some parameters of
our
> > > > config file: MULTIPROCESSOR 1 NUMCPUVPS 2 SINGLE_CPU_VP 0 NOAGE
1
> > > > AFF_SPROC 0 AFF_NPROCS 0 LOCKS 700000 BUFFERS 100000 NUMAIOVPS 1
> > > > PHYSBUFF 64 LOGBUFF 64 LOGSMAX 600 CLEANERS 8 CKPTINTVL 120 LRUS
8
> > > > LRU_MAX_DIRTY 5 LRU_MIN_DIRTY 2 Any idea how to speed up the
> > > > checkpoints?
> > > >
> > > >
> > >
> > >
> >
>
>
************************************************************************
*****
>
> > > ** Forum Note: Use "Reply" to post a response in the discussion
forum.
> > > ------- End of Original Message -------
> > >
> > >
> > >
> > >
> >
>
>
************************************************************************
*****
> **
> > > Forum Note: Use "Reply" to post a response in the discussion
forum.
> > >
> > >
> >
> > --
> > Art S. Kagel
> > Oninit (www.oninit.com)
> > IIUG Board of Directors (art@iiug.org)
> >
> > Disclaimer: Please keep in mind that my own opinions are my own
> > opinions and do not reflect on my employer, Oninit, the IIUG, nor
> > any other organization with which I am associated either explicitly
> > or implicitly. Neither do those opinions reflect those of other
> > individuals affiliated with any entity with which I am affiliated
> > nor those of the entities themselves.
> >
> > --001636427251eb776a04653f08bd
> >
> >
>
>
************************************************************************
*****
> ** Forum Note: Use "Reply" to post a response in the discussion forum.
> ------- End of Original Message -------
>
>
>
>
************************************************************************
*******
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--
Art S. Kagel
Oninit (www.oninit.com)
IIUG Board of Directors (art@iiug.org)
Disclaimer: Please keep in mind that my own opinions are my own opinions
and
do not reflect on my employer, Oninit, the IIUG, nor any other
organization
with which I am associated either explicitly or implicitly. Neither
I'm brave, but not foolish. In general, I agree, change one thing at a time
and watch what happens. But there are several groups of parameters that are
related and those should generally be modified in lock step for best
results. The groups of parameters below are each dependent for resources on
the ones listed below them and interrelated the other parameter in the
group.
- CKPTINTVL with PHYSFILE
- LRU_MIN_DIRTY with LRU_MAX_DIRTY
- LRUS with CLEANERS
- NUMAIOVPS (or VPCLASS aio in newer engine versions)
Often these four sets of parameters are related. Modifying the earlier
groups without supplying the resources from the later groups can be
detrimental to performance. Longer checkpoint intervals require a larger
physical log. If you do not have one CLEANER for each LRU queue then at LRU
flush time some LRU queues may become 100% dirty causing foreground writes.
Even if they do not reach 100%, if some queues exceed LRU_MAX_DIRTY
frequently then checkpoints will become longer. As Kate pointed out, the
number of AIO VPs is a critical resource in general and depending on the
kind of chunk files used is a major performance limiter when incorrectly
tuned. If two or more LRU queues need to be flushed at the same time at LRU
flush time or dirty pages from multiple chunks have to be flushed at
checkpoint time, but, as in the OP's system, there is only a single AIO VP,
some IO requests will have to wait in queue.
Therefore, I put them all together and tend to tune the less independent
parameters (NUMAIOVPS and LRUS/CLEANERS) when I adjust the more dependent
ones (LRU_MIN/MAX_DIRTY and LRUS/CLEANERS).
Art
On Mon, Mar 16, 2009 at 1:58 PM, Norma Jean Sebastian <
nsebastian@flinnsci.com> wrote:
> I did.
> It is an option, and I most certainly didn't mean to change several
> parameters at the same time. I assumed it was common knowledge to tweak
> one thing at a time...
> Sorry.
> NJ
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Art Kagel
> Sent: Monday, March 16, 2009 11:54 AM
> To: ids@iiug.org
> Subject: Re: RE: IDS 7.31 Solaris8 - Long Checkpoints [15164]
>
> Sorry, someone did. My apologies.
>
> Art
>
> On Mon, Mar 16, 2009 at 12:47 PM, kate <kate@iiug.org> wrote:
>
> > I never said to increase buffers, so we are agreeing. I said that IF
> YOU
> > DID you would need to retune everything.
> >
> > Thanks!
> > Kate Tomchik [ kate@iiug.org ] www.iiug.org
> > International Informix Users Group Board of Directors
> >
> > A computer lets you make more mistakes faster than any invention in
> human
> > history - with the possible exceptions of handguns and tequila.
> > Mitch Ratliffe
> >
> > ---------- Original Message -----------
> > From: "Art Kagel" <art.kagel@gmail.com>
> > To: ids@iiug.org
> > Sent: Mon, 16 Mar 2009 12:35:18 -0400 (EDT)
> > Subject: Re: RE: IDS 7.31 Solaris8 - Long Checkpoints [15159]
> >
> > > I have to disagree with both of your suggestins Kate. Increasing
> > > buffers will only increase the number of dirty buffers at checkpoint
>
> > > time making the checkpoints even longer. Since the OP is using 7.31
> > > he only has full integer control of the LRU_MIN/MAX_DIRTY
> parameters,
> > > so 2/1 is as low as he can go and changing the MIN from 2 to 1 will
> > > not help a whole lot if they are increasing BUFFERS to boot. Now you
>
> > > may be right that the instance is too small and they could use more
> > > buffers to make EVERYTHING run better and faster, but that's not
> > > going to help the checkpoint duration at all.
> > >
> > > Your the ideas in your other post I'll address there.
> > >
> > > Art
> > >
> > > On Mon, Mar 16, 2009 at 12:24 PM, kate <kate@iiug.org> wrote:
> > >
> > > > No NJ, that would be changing too many things at once. Even Art
> has too
> > > > many. For starters just change what I said, bounce you engine, and
> see
> > what
> > > > your results are.
> > > >
> > > > Changing buffers often causes a retune of the whole environment. I
>
> > agree
> > he
> > > > could be using many more, but lets focus on the current problem
> first.
> > > >
> > > > Thanks!
> > > > Kate Tomchik [ kate@iiug.org ] www.iiug.org
> > > > International Informix Users Group Board of Directors
> > > >
> > > > A computer lets you make more mistakes faster than any invention
> in
> > human
> > > > history - with the possible exceptions of handguns and tequila.
> > > > Mitch Ratliffe
> > > >
> > > > ---------- Original Message -----------
> > > > From: "Norma Jean Sebastian" <nsebastian@flinnsci.com>
> > > > To: ids@iiug.org
> > > > Sent: Mon, 16 Mar 2009 11:56:55 -0400 (EDT)
> > > > Subject: RE: RE: IDS 7.31 Solaris8 - Long Checkpoints [15154]
> > > >
> > > > > Kurt,
> > > > > It's cool you're not taking more virtual memory segs to get the
> work
> > > > > done (only 1 "V" in your onstat -g seg output).
> > > > > Your engine is only sized to about 413MB, while you said you
> have
> > > > > 4GB RAM on the server.
> > > > >
> > > > > In addition to Art Kagel's suggestion he just saw posted....
> > > > > Try increasing your buffers... what else is running on the
> > > > > server?... increasing buffers is the main thing that will
> increase
> > > > > the size of your Informix engine... you're on a 7.31 (32bit)
> engine
> > > > > ... you could max the Informix engine up to about 3.75GB I
> think...
> > > > > you don't have to go for the full max, but at least double it to
>
> > > > > about 1 GB instead of the 413MB you have now.
> > > > >
> > > > > Thanks,
> > > > > Norma Jean Sebastian
> > > > >
> > > > > -----Original Message-----
> > > > > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On
> Behalf
> > > > > Of KURT VAN GOMPEL Sent: Monday, March 16, 2009 10:36 AM To:
> > > > > ids@iiug.org Subject: Re: RE: IDS 7.31 Solaris8 - Long
> Checkpoints
> > > > > [15149]
> > > > >
> > > > > Hello,
> > > > >
> > > > > Here's the output op onstat -g seg:
> > > > >
> > > > > Informix Dynamic Server Version 7.31.UD1 -- On-Line -- Up
> 10:22:10 --
> > > > > 412752 Kbytes
> > > > >
> > > > > Segment Summary:
> > > > > id key addr size ovhd class blkused blkfree
> > > > > 94000 1394493441 a000000 268435456 24820 R* 31026 1742
> > > > > 94001 1394493442 1a000000 153600000 2948 V 9760 8990
> > > > > 94002 1394493443 2327c000 622592 616 M 75 1
> > > > > Total: - - 422658048 - - 40861 10733
> > > > >
> > > > > (* segment locked in memory)
> > > > >
> > > > > Hello,
> > > > > We are running IDS7.31 UD1 on a Solaris8 server with 2 Sparc64
> > > > > processors and 4GB RAM.
> > > > > It is used for interactive and batch processing.
> > > > > When lots of manipulations on the DB are done, it takes
> sometimes
> > > > > more than 60 seconds to do his checkpoints. Some parameters of
> our
> > > > > config file: MULTIPROCESSOR 1 NUMCPUVPS 2 SINGLE_CPU_VP 0 NOAGE
> 1
> > > > > AFF_SPROC 0 AFF_NPROCS 0 LOCKS 700000 BUFFERS 100000 NUMAIOVPS 1
>
> > > > > PHYSBUFF 6
Hello, I changed LRUS and CLEANERS to 128, LRU_MAX_DIRTY to 2 and LRU_MIN_DIRTY to 1 on a Solaris8 testserver with 2 processors and 2GB RAM. The chackpoints are shorter but the IDS server is much slower then before: a load of about 85000 records takes 25 minutes now, 7 minutes before the changes. Kurt.
KURT VAN GOMPEL wrote:
> Hello,
> I changed LRUS and CLEANERS to 128, LRU_MAX_DIRTY to 2 and LRU_MIN_DIRTY to 1
> on a Solaris8 testserver with 2 processors and 2GB RAM.
> The chackpoints are shorter but the IDS server is much slower then before: a
> load of about 85000 records takes 25 minutes now, 7 minutes before the
> changes.
>
> Kurt.
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
Sure, a load is not the scenario for LRU_MIN/MAX_DIRTY to set to values
as low as 1/2
Anyway, I don't think your checkpoint issues are really dependent on
LRU_MIN_DIRTY and LRU_MAX_DIRTY.
You wrote your original ONCONFIG was :
BUFFERS 100000
LRU_MIN_DIRTY 2
LRU_MIN_DIRTY 5
So that's at most 5000 BUFFERS (5%) (i.e. some 10 MB for a 2K page
system) to clean at checkpoint time. If that amount takes 60secs or more
there is going on something else - nothing to be solved by a change of
LRU_MIN_DIRTY or LRU_MIN_DIRTY.
Have a look at what the engine is doing while in checkpoint , create a
small script that captures the most important onstat commands (-g ath,
-b, -u, -g stk all, -g wmx ) in a loop and maybe look at your WAIT
STATISTICS !
HTH
Tilman
--
- --
Public Key-ID : 0xED06A44A
Key fingerprint = E62C 4A34 87EB 6048 D5A3 AD18 D612 F7A6 ED06 A44A
URL: http://pgpkeys.pca.dfn.de/pks/lookup?search=0xED06A44A
How many chunks do you have? Are they COOKED (block device or filesystem
files) or RAW (character devices)? How many CPU VPs are configured? How
many BUFFERS? What is the output from the following commands:
onstat -p
onstat -P
onstat -F
onstat -R
onstat -l
onstat -g iov
onstat -g iof
onstat -g glo
Art
On Mon, Mar 16, 2009 at 3:38 PM, KURT VAN GOMPEL <
kvangompel@caami-hziv.fgov.be> wrote:
> Hello,
> I changed LRUS and CLEANERS to 128, LRU_MAX_DIRTY to 2 and LRU_MIN_DIRTY to
> 1
> on a Solaris8 testserver with 2 processors and 2GB RAM.
> The chackpoints are shorter but the IDS server is much slower then before:
> a
> load of about 85000 records takes 25 minutes now, 7 minutes before the
> changes.
>
> Kurt.
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--
Art S. Kagel
Oninit (www.oninit.com)
IIUG Board of Directors (art@iiug.org)
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Oninit, the IIUG, nor any other organization
with which I am associated either explicitly or implicitly. Neither do
those opinions reflect those of other individuals affiliated with any entity
with which I am affiliated nor those of the entities themselves.
--00163646d7d6a8d2910465445bdd
Hello,
Thanks for the many responses.
Hereby the information some of you asked:
- chunks are on filesystem (50 chunks on server PRD, 10 on sever TST)
- BUFFERS is set to 100000
- NUMCPUVPS is 2
Output of onstat on testserver while in checkpoint (47 secs):
onstat -p
Informix Dynamic Server Version 7.31.UD1 -- On-Line (CKPT REQ) -- Up 00:53:20
-- 412752 Kbytes
Blocked:CKPT
Profile
dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
22619 35939 3961511 99.43 59737 132210 1068478 94.41
isamtot open start read write rewrite delete commit rollbk
773583 182 187225 208215 75606 62917 82443 6092 0
gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs
0 0 0 0 0 0 0
ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes
0 0 0 11.99 5.98 6 21
bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans
2236 0 2372084 0 0 4 3527 11
ixda-RA idx-RA da-RA RA-pgsused lchwaits
11818 0 3244 15062 13
------------------------------------------------------------
onstat -P
Informix Dynamic Server Version 7.31.UD1 -- On-Line (CKPT REQ) -- Up 00:53:20
-- 412752 Kbytes
Blocked:CKPT
partnum total btree data other resident dirty
0 79028 8289 1457 69282 0 0
1048578 2 1 1 0 0 0
1048579 4 2 2 0 0 0
1048622 5 2 3 0 0 0
1048623 4 2 2 0 0 0
1048625 2 1 1 0 0 0
1048626 1 1 0 0 0 0
1048628 2 1 1 0 0 0
1048632 1 1 0 0 0 0
1048635 1 1 0 0 0 0
1048641 1 1 0 0 0 0
1048642 1 1 0 0 0 0
1048643 1 1 0 0 0 0
1048646 1 1 0 0 0 0
1048650 3 3 0 0 0 0
1048659 1 0 1 0 0 0
1048662 1 0 1 0 0 0
2097154 5 2 3 0 0 0
2097155 9 4 5 0 0 0
2097156 3 1 2 0 0 0
2097157 2 1 1 0 0 0
2097158 2 1 1 0 0 0
2097160 2 1 1 0 0 0
2097164 3 1 2 0 0 0
2097165 1 1 0 0 0 0
2097167 1 1 0 0 0 0
2097168 2 1 1 0 0 0
2097173 1 1 0 0 0 0
2097174 1 1 0 0 0 0
2097175 1 1 0 0 0 0
2097177 1 1 0 0 0 0
2097178 1 1 0 0 0 0
2097181 6 4 2 0 0 0
2097182 3 3 0 0 0 0
2097189 20093 1136 13791 5166 0 110
7340034 804 563 241 0 0 0
Totals: 100000 10033 15519 74448 0 110
Percentages:
Data 15.52
Btree 10.03
Other 74.45
------------------------------------------------------------
onstat -F
Informix Dynamic Server Version 7.31.UD1 -- On-Line (CKPT REQ) -- Up 00:53:20
-- 412752 Kbytes
Blocked:CKPT
Fg Writes LRU Writes Chunk Writes
0 44607 12763
address flusher state data
1a050514 0 C 2 = 0X2
1a050a10 1 I 0 = 0X0
1a050f0c 2 I 0 = 0X0
1a051408 3 I 0 = 0X0
1a051904 4 I 0 = 0X0
1a051e00 5 I 0 = 0X0
1a0522fc 6 I 0 = 0X0
1a0527f8 7 I 0 = 0X0
states: Exit Idle Chunk Lru
------------------------------------------------------------
onstat -R
Informix Dynamic Server Version 7.31.UD1 -- On-Line (CKPT REQ) -- Up 00:53:20
-- 412752 Kbytes
Blocked:CKPT
8 buffer LRU queue pairs priority levels
# f/m pair total % of length LOW MED_LOW MED_HIGH HIGH
0 f 12500 99.8% 12480 9668 2788 24 0
1 m 0.2% 20 0 19 1 0
2 f 12500 99.9% 12488 9673 2802 12 1
3 m 0.1% 12 0 12 0 0
4 f 12501 99.9% 12491 9664 2812 14 1
5 m 0.1% 10 0 10 0 0
6 f 12500 99.9% 12489 9677 2794 16 2
7 m 0.1% 11 0 11 0 0
8 f 12500 100.0% 12499 9672 2813 13 1
9 m 0.0% 1 0 1 0 0
10 f 12500 99.8% 12480 9673 2790 15 2
11 m 0.2% 20 0 19 1 0
12 f 12499 99.9% 12490 9662 2812 14 2
13 m 0.1% 9 0 8 1 0
14 F 12500 99.9% 12489 9678 2802 9 0
15 m 0.1% 11 0 11 0 0
94 dirty, 100000 queued, 100000 total, 131072 hash buckets, 2048 buffer size
start clean at 5% (of pair total) dirty, or 625 buffs dirty, stop at 2%
0 priority downgrades, 0 priority upgrades
------------------------------------------------------------
onstat -l
Informix Dynamic Server Version 7.31.UD1 -- On-Line (CKPT REQ) -- Up 00:53:20
-- 412752 Kbytes
Blocked:CKPT
Physical Logging
Buffer bufused bufsize numpages numwrits pages/io
P-2 0 32 31771 996 31.90
phybegin physize phypos phyused %used
600035 200000 71471 12204 6.10
Logical Logging
Buffer bufused bufsize numrecs numpages numwrits recs/pages pages/io
L-2 0 32 879331 42042 1324 20.9 31.8
Subsystem numrecs Log Space used
OLDRSAM 879331 84510500
address number flags uniqid begin size used %used
c3d4978 1 U------ 1 100233 750 750 100.00
c3d4994 2 U------ 2 100521 750 750 100.00
c3d49b0 3 U------ 3 10080f 750 750 100.00
c3d49cc 4 U------ 4 100afd 750 750 100.00
c3d49e8 5 U------ 5 100deb 750 223 29.73
c3d4a04 6 U------ 6 1010d9 750 750 100.00
c3d4a20 7 U------ 7 800035 10000 10000 100.00
c3d4a3c 8 U------ 8 802745 10000 10000 100.00
c3d4a58 9 U------ 9 804e55 10000 10000 100.00
c3d4a74 10 U------ 10 807565 10000 10000 100.00
c3d4a90 11 U------ 11 809c75 10000 10000 100.00
c3d4aac 12 U------ 12 80c385 10000 10000 100.00
c3d4ac8 13 U------ 13 80ea95 10000 10000 100.00
c3d4ae4 14 U------ 14 8111a5 10000 10000 100.00
c3d4b00 15 U------ 15 8138b5 10000 10000 100.00
c3d4b1c 16 U------ 16 815fc5 10000 10000 100.00
c3d4b38 17 U------ 17 8186d5 10000 10000 100.00
c3d4b54 18 U------ 18 81ade5 10000 10000 100.00
c3d4b70 19 U-----L 19 81d4f5 10000 10000 100.00
c3d4b8c 20 U------ 20 81fc05 10000 10000 100.00
c3d4ba8 21 U---C-- 21 822315 10000 1792 17.92
c3d4bc4 22 F------ 0 824a25 10000 0 0.00
c3d4be0 23 F------ 0 827135 10000 0 0.00
c3d4bfc 24 F------ 0 829845 10000 0 0.00
c3d4c18 25 F------ 0 82bf55 10000 0 0.00
c3d4c34 26 F------ 0 82e665 10000 0 0.00
------------------------------------------------------------
onstat -g iov
Informix Dynamic Server Version 7.31.UD1 -- On-Line (CKPT REQ) -- Up 00:53:20
-- 412752 Kbytes
Blocked:CKPT
AIO I/O vps:
class/vp s io/s totalops dskread dskwrite dskcopy wakeups io/wup errors
msc 0 i 0.0 6 0 0 0 7 0.9 0
aio 0 s 18.9 60332 10763 49541 0 838 72.0 0
pio 0 i 0.3 996 0 996 0 997 1.0 0
lio 0 i 0.4 1324 0 1324 0 1325 1.0 0
------------------------------------------------------------
onstat -g iof
Informix Dynamic Server Version 7.31.UD1 -- On-Line (CKPT REQ) -- Up 00:53:20
-- 412752 Kbytes
Blocked:CKPT
AIO global files:
gfd pathname totalops dskread dskwrite io/s
3 rootdbs 105 71 34 0.0
4 datadbs_ch01 56770 8280 48490 17.7
5 blobdbs 397 397 0 0.1
6 senddbs 3 3 0 0.0
7 receivedbs 3 3 0 0.0
8 physlogdbs 999 3 996 0.3
9 tempdbs 1824 808 1016 0.6
10 logsdbs 1327 3 1324 0.4
11 blobdbs_1p_ch01 198 198 0 0.1
12 blobdbs_1p_ch02 989 989 0 0.3
------------------------------------------------------------
onstat -g glo
Informix Dynamic Server Version 7.31.UD1 -- On-Line (CKPT REQ) -- Up 00:53:20
-- 412752 Kbytes
Blocked:CKPT
MT global info:
sessions threads vps lngspins
1 22 9 0
sched calls thread switches yield 0 yield n yield forever
total: 12426045 51894 12374075 10590 17003
per sec: 12 0 12 0 0
Virtual processor summary:
class vps usercpu syscpu total
cpu 2 11.78 0.50 12.28
aio 1 0.20 4.09 4.29
tli 1 0.00 0.05 0.05
shm 1 0.00 0.00 0.00
lio 1 0.00 0.79 0.79
pio 1 0.01 0.55 0.56
adm 1 0.00 0.00 0.00
msc 1 0.00 0.00 0.00@@NL
You said that you are still having issues. Your NUMAIOVPS should be at a
miniumum of 2 if you are using KAIO, and 8 if not. After you set it, you
should run an
>onstat -g iovand let me see the results. That will indicate if it needs to be even
higher.
Thanks!
Kate Tomchik [ kate@iiug.org ] www.iiug.org
International Informix Users Group Board of Directors
A computer lets you make more mistakes faster than any invention in human
history - with the possible exceptions of handguns and tequila.
Mitch Ratliffe
---------- Original Message -----------
From: "KURT VAN GOMPEL" <kvangompel@caami-hziv.fgov.be>
To: ids@iiug.org
Sent: Mon, 16 Mar 2009 11:26:19 -0400 (EDT)
Subject: IDS 7.31 Solaris8 - Long Checkpoints [15147]
> Hello,
>
> We are running IDS7.31 UD1 on a Solaris8 server with 2 Sparc64
> processors and 4GB RAM. It is used for interactive and batch
> processing. When lots of manipulations on the DB are done, it takes
> sometimes more than 60 seconds to do his checkpoints. Some
> parameters of our config file: MULTIPROCESSOR 1 NUMCPUVPS 2
> SINGLE_CPU_VP 0 NOAGE 1 AFF_SPROC 0 AFF_NPROCS 0 LOCKS 700000
> BUFFERS 100000 NUMAIOVPS 1 PHYSBUFF 64 LOGBUFF 64 LOGSMAX 600
> CLEANERS 8 CKPTINTVL 120 LRUS 8 LRU_MAX_DIRTY 5 LRU_MIN_DIRTY 2
>
> Any idea how to speed up the checkpoints?
>
>
*****************************************************************************
** Forum Note: Use "Reply" to post a response in the discussion forum.
------- End of Original Message -------
Here's the telling bit, Kate nailed it. You onstat -g iov says:
AIO I/O vps:
class/vp s io/s totalops dskread dskwrite dskcopy wakeups io/wup errors
msc 0 i 0.0 6 0 0 0 7 0.9 0
aio 0 s 18.9 60332 10763 49541 0 838 72.0 0
^^^
72.0 IO/WUP for this one lonely AIO VP means that 98.6% of your server's IO
requests are queued up waiting for service when the server is busy.
If you have 50 filesystem (ie COOKED) chunks, then (at least under 7.31
which cannot use DIRECT IO) you need between 75 and 100 AIO VPs in order to
properly service IO requests against this server without delays. By
improving the parameter settings I suggested you did improve the checkpoint
duration which was goal #1. However, we knowingly shifted much of the
checkpoint IO so that it happens slowly over time instead of all at once
during a checkpoint. Now, with not enough AIO VPs to service all those
requests, other IO bound requests like your big data load will suffer.
Solution, increase NUMAIOVPS to 100 and adjust from there. If after running
some normal processing and some peak processing onstat -g iov shows some
number of these aio vps with io/wup = 0.0 then you can reduce NUMAIOVPS by
that number. If, however, all of the AIO VPs show io/wup of 1.0 or greater,
then you still need to add more. If one or more show io/wup less than 1.0
and only a few are over 1.0 then you are cruising!
Art
On Tue, Mar 17, 2009 at 5:29 AM, KURT VAN GOMPEL <
kvangompel@caami-hziv.fgov.be> wrote:
> Hello,
>
> Thanks for the many responses.
> Hereby the information some of you asked:
> - chunks are on filesystem (50 chunks on server PRD, 10 on sever TST)
> - BUFFERS is set to 100000
> - NUMCPUVPS is 2
>
> Output of onstat on testserver while in checkpoint (47 secs):
>
> onstat -p>
> Informix Dynamic Server Version 7.31.UD1 -- On-Line (CKPT REQ) -- Up
> 00:53:20
> -- 412752 Kbytes
> Blocked:CKPT
>
> Profile
> dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
> 22619 35939 3961511 99.43 59737 132210 1068478 94.41
>
> isamtot open start read write rewrite delete commit rollbk
> 773583 182 187225 208215 75606 62917 82443 6092 0
>
> gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs
> 0 0 0 0 0 0 0
>
> ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes
> 0 0 0 11.99 5.98 6 21
>
> bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans
> 2236 0 2372084 0 0 4 3527 11
>
> ixda-RA idx-RA da-RA RA-pgsused lchwaits
> 11818 0 3244 15062 13
>
> ------------------------------------------------------------
> onstat -P>
> Informix Dynamic Server Version 7.31.UD1 -- On-Line (CKPT REQ) -- Up
> 00:53:20
> -- 412752 Kbytes
> Blocked:CKPT
> partnum total btree data other resident dirty
> 0 79028 8289 1457 69282 0 0
> 1048578 2 1 1 0 0 0
> 1048579 4 2 2 0 0 0
> 1048622 5 2 3 0 0 0
> 1048623 4 2 2 0 0 0
> 1048625 2 1 1 0 0 0
> 1048626 1 1 0 0 0 0
> 1048628 2 1 1 0 0 0
> 1048632 1 1 0 0 0 0
> 1048635 1 1 0 0 0 0
> 1048641 1 1 0 0 0 0
> 1048642 1 1 0 0 0 0
> 1048643 1 1 0 0 0 0
> 1048646 1 1 0 0 0 0
> 1048650 3 3 0 0 0 0
> 1048659 1 0 1 0 0 0
> 1048662 1 0 1 0 0 0
> 2097154 5 2 3 0 0 0
> 2097155 9 4 5 0 0 0
> 2097156 3 1 2 0 0 0
> 2097157 2 1 1 0 0 0
> 2097158 2 1 1 0 0 0
> 2097160 2 1 1 0 0 0
> 2097164 3 1 2 0 0 0
> 2097165 1 1 0 0 0 0
> 2097167 1 1 0 0 0 0
> 2097168 2 1 1 0 0 0
> 2097173 1 1 0 0 0 0
> 2097174 1 1 0 0 0 0
> 2097175 1 1 0 0 0 0
> 2097177 1 1 0 0 0 0
> 2097178 1 1 0 0 0 0
> 2097181 6 4 2 0 0 0
> 2097182 3 3 0 0 0 0
> 2097189 20093 1136 13791 5166 0 110
> 7340034 804 563 241 0 0 0
>
> Totals: 100000 10033 15519 74448 0 110
>
> Percentages:
> Data 15.52
> Btree 10.03
> Other 74.45
>
> ------------------------------------------------------------
> onstat -F>
> Informix Dynamic Server Version 7.31.UD1 -- On-Line (CKPT REQ) -- Up
> 00:53:20
> -- 412752 Kbytes
> Blocked:CKPT
>
> Fg Writes LRU Writes Chunk Writes
> 0 44607 12763
>
> address flusher state data
> 1a050514 0 C 2 = 0X2
> 1a050a10 1 I 0 = 0X0
> 1a050f0c 2 I 0 = 0X0
> 1a051408 3 I 0 = 0X0
> 1a051904 4 I 0 = 0X0
> 1a051e00 5 I 0 = 0X0
> 1a0522fc 6 I 0 = 0X0
> 1a0527f8 7 I 0 = 0X0
>
> states: Exit Idle Chunk Lru
>
> ------------------------------------------------------------
> onstat -R>
> Informix Dynamic Server Version 7.31.UD1 -- On-Line (CKPT REQ) -- Up
> 00:53:20
> -- 412752 Kbytes
> Blocked:CKPT
>
> 8 buffer LRU queue pairs priority levels
> # f/m pair total % of length LOW MED_LOW MED_HIGH HIGH
> 0 f 12500 99.8% 12480 9668 2788 24 0
> 1 m 0.2% 20 0 19 1 0
> 2 f 12500 99.9% 12488 9673 2802 12 1
> 3 m 0.1% 12 0 12 0 0
> 4 f 12501 99.9% 12491 9664 2812 14 1
> 5 m 0.1% 10 0 10 0 0
> 6 f 12500 99.9% 12489 9677 2794 16 2
> 7 m 0.1% 11 0 11 0 0
> 8 f 12500 100.0% 12499 9672 2813 13 1
> 9 m 0.0% 1 0 1 0 0
> 10 f 12500 99.8% 12480 9673 2790 15 2
> 11 m 0.2% 20 0 19 1 0
> 12 f 12499 99.9% 12490 9662 2812 14 2
> 13 m 0.1% 9 0 8 1 0
> 14 F 12500 99.9% 12489 9678 2802 9 0
> 15 m 0.1% 11 0 11 0 0
> 94 dirty, 100000 queued, 100000 total, 131072 hash buckets, 2048 buffer
> size
> start clean at 5% (of pair total) dirty, or 625 buffs dirty, stop at 2%
> 0 priority downgrades, 0 priority upgrades
> ------------------------------------------------------------
> onstat -l>
> Informix Dynamic Server Version 7.31.UD1 -- On-Line (CKPT REQ) -- Up
> 00:53:20
> -- 412752 Kbytes
> Blocked:CKPT
>
> Physical Logging
> Buffer bufused bufsize numpages numwrits pages/io
> P-2 0 32 31771 996 31.90
>
> phybegin physize phypos phyused %used
>
> 600035 200000 71471 12204 6.10
>
> Logical Logging
> Buffer bufused bufsize numrecs numpages numwrits recs/pages pages/io
> L-2 0 32 879331 42042 1324 20.9 31.8
>
> Subsystem numrecs Log Space used
>
> OLDRSAM 879331 84510500
>
> address number flags uniqid begin size used %used
> c3d4978 1 U------ 1 100233 750 750 100.00
> c3d4994 2 U------ 2 100521 750 750 100.00
> c3d49b0 3 U------ 3 10080f 750 750 100.00
> c3d49cc 4 U------ 4 100afd 750 750 100.00
> c3d49e8 5 U------ 5 100deb 750 223 29.73
> c3d4a04 6 U------ 6 1010d9 750 750 100.00
> c3d4a20 7 U------ 7 800035 10000 10000 100.00
> c3d4a3c 8 U------ 8 802745 10000 10000 100.00
> c3d4a58 9 U------ 9 804e55 10000 10000 100.00
> c3d4a74 10 U------ 10 807565 10000 10000 100.00
> c3d4a90 11 U------ 11 809c75 10000 10000 100.00
> c3d4aac 12 U------ 12 80c385 10000 10000 100.00
> c3d4ac8 13 U------ 13 80ea95 10000 10000 100.00
> c3d4ae4 14 U------ 14 8111a5 10000 10000 100.00
> c3d4b00 15 U------ 15 8138b5 10000 10000 100.00
> c3d4b1c 16 U------ 16 815fc5 10000 10000 100.00
> c3d4b38 17 U------ 17 8186d5 10000 10000 100.00
> c3d4b54 18 U------ 18 81ade5 10000 10000 100.00
> c3d4b70 19 U-----L 19 81d4f5 10000 10000 100.00
> c3d4b8c 20 U------ 20 81fc05 10000 10000 100.00
> c3d4ba8 21 U---C-- 21 822315 10000 1792 17.92
> c3d4bc4 22 F------ 0 824a25 10000 0 0.00
> c3d4
Hello,
Sorry for the long delay!
I understand I have to add aio vps to resolve the problem.
I read that IDS starts kaio vps if possible: OS must support it, raw devices.
We have some Windows NT4 servers with IDS 7.31 TC6 on it and chunks on cooked
devices; there I see kio vps and kaio threads too.
Informix Dynamic Server Version 7.31.TC6 -- On-Line -- Up 10:54:24 -- 172608
Kbytes
AIO I/O vps:
class/vp s io/s totalops dskread dskwrite dskcopy wakeups io/wup errors
kio 0 i 0.0 0 0 0 0 0 0.0 0
kio 1 i 1.1 44510 34298 10212 0 44538035 0.0 0
msc 0 i 0.0 842 0 0 0 254 3.3 0
aio 0 i 0.0 419 27 300 0 45 9.3 0
pio 0 i 0.0 0 0 0 0 1 0.0 0
lio 0 i 0.0 0 0 0 0 1 0.0 0
C:\\\\INFORMIX\\\\bin>onstat -g ath
Informix Dynamic Server Version 7.31.TC6 -- On-Line -- Up 10:55:41 -- 172608
Kbytes
Threads:
tid tcb rstcb prty status vp-class name
2 f48cf48 0 2 sleeping forever 3lio lio vp 0
3 f48d1e0 0 2 sleeping forever 4pio pio vp 0
4 f48d478 0 2 sleeping forever 5aio aio vp 0
5 f48d710 0 2 sleeping forever 6msc msc vp 0
6 f51c138 f3aa018 4 sleeping secs: 1 1cpu main_loop()
7 f51cc30 0 2 running 7soc soctcppoll
8 f51d4a0 0 2 running 8soc soctcpio
9 f51dcc0 0 3 sleeping forever 1cpu soctcplst
10 f48db38 f3aa500 2 sleeping forever 1cpu flush_sub(0)
11 f48dda8 f3aa9e8 2 sleeping forever 1cpu flush_sub(1)
12 f4ac138 0 4 sleeping forever 5aio kaio
13 f4ac710 0 4 sleeping forever 1cpu kaio
Could you explain that?
WIndows is a special case.
Art
Art S. Kagel
Oninit (www.oninit.com)
IIUG Board of Directors (art@iiug.org)
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Oninit, the IIUG, nor any other organization
with which I am associated either explicitly or implicitly. 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 Tue, Mar 24, 2009 at 9:33 AM, KURT VAN GOMPEL <
kvangompel@caami-hziv.fgov.be> wrote:
> Hello,
>
> Sorry for the long delay!
> I understand I have to add aio vps to resolve the problem.
> I read that IDS starts kaio vps if possible: OS must support it, raw
> devices.
> We have some Windows NT4 servers with IDS 7.31 TC6 on it and chunks on
> cooked
> devices; there I see kio vps and kaio threads too.
>
> Informix Dynamic Server Version 7.31.TC6 -- On-Line -- Up 10:54:24 --
> 172608
> Kbytes
>
> AIO I/O vps:
> class/vp s io/s totalops dskread dskwrite dskcopy wakeups io/wup errors
> kio 0 i 0.0 0 0 0 0 0 0.0 0
> kio 1 i 1.1 44510 34298 10212 0 44538035 0.0 0
> msc 0 i 0.0 842 0 0 0 254 3.3 0
> aio 0 i 0.0 419 27 300 0 45 9.3 0
> pio 0 i 0.0 0 0 0 0 1 0.0 0
> lio 0 i 0.0 0 0 0 0 1 0.0 0
>
> C:\\\\INFORMIX\\\\bin>onstat -g ath
>
> Informix Dynamic Server Version 7.31.TC6 -- On-Line -- Up 10:55:41 --
> 172608
> Kbytes
>
> Threads:
> tid tcb rstcb prty status vp-class name
> 2 f48cf48 0 2 sleeping forever 3lio lio vp 0
> 3 f48d1e0 0 2 sleeping forever 4pio pio vp 0
> 4 f48d478 0 2 sleeping forever 5aio aio vp 0
> 5 f48d710 0 2 sleeping forever 6msc msc vp 0
> 6 f51c138 f3aa018 4 sleeping secs: 1 1cpu main_loop()
> 7 f51cc30 0 2 running 7soc soctcppoll
> 8 f51d4a0 0 2 running 8soc soctcpio
> 9 f51dcc0 0 3 sleeping forever 1cpu soctcplst
> 10 f48db38 f3aa500 2 sleeping forever 1cpu flush_sub(0)
>
> 11 f48dda8 f3aa9e8 2 sleeping forever 1cpu flush_sub(1)
>
> 12 f4ac138 0 4 sleeping forever 5aio kaio
> 13 f4ac710 0 4 sleeping forever 1cpu kaio
>
> Could you explain that?
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--001636af022eba0acf0465de4878
IDS v10.00 starting with one of the later maintenance releases (xC8???) also
supports KAIO for COOKED chunks on OSes that support DIRECT_IO assuming it
is enabled in the OS and in the ONCONFIG file. IDS 7.xx does not support
DIRECT_IO.
Art
Art S. Kagel
Oninit (www.oninit.com)
IIUG Board of Directors (art@iiug.org)
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Oninit, the IIUG, nor any other organization
with which I am associated either explicitly or implicitly. 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 Tue, Mar 24, 2009 at 9:33 AM, KURT VAN GOMPEL <
kvangompel@caami-hziv.fgov.be> wrote:
> Hello,
>
> Sorry for the long delay!
> I understand I have to add aio vps to resolve the problem.
> I read that IDS starts kaio vps if possible: OS must support it, raw
> devices.
> We have some Windows NT4 servers with IDS 7.31 TC6 on it and chunks on
> cooked
> devices; there I see kio vps and kaio threads too.
>
> Informix Dynamic Server Version 7.31.TC6 -- On-Line -- Up 10:54:24 --
> 172608
> Kbytes
>
> AIO I/O vps:
> class/vp s io/s totalops dskread dskwrite dskcopy wakeups io/wup errors
> kio 0 i 0.0 0 0 0 0 0 0.0 0
> kio 1 i 1.1 44510 34298 10212 0 44538035 0.0 0
> msc 0 i 0.0 842 0 0 0 254 3.3 0
> aio 0 i 0.0 419 27 300 0 45 9.3 0
> pio 0 i 0.0 0 0 0 0 1 0.0 0
> lio 0 i 0.0 0 0 0 0 1 0.0 0
>
> C:\\\\INFORMIX\\\\bin>onstat -g ath
>
> Informix Dynamic Server Version 7.31.TC6 -- On-Line -- Up 10:55:41 --
> 172608
> Kbytes
>
> Threads:
> tid tcb rstcb prty status vp-class name
> 2 f48cf48 0 2 sleeping forever 3lio lio vp 0
> 3 f48d1e0 0 2 sleeping forever 4pio pio vp 0
> 4 f48d478 0 2 sleeping forever 5aio aio vp 0
> 5 f48d710 0 2 sleeping forever 6msc msc vp 0
> 6 f51c138 f3aa018 4 sleeping secs: 1 1cpu main_loop()
> 7 f51cc30 0 2 running 7soc soctcppoll
> 8 f51d4a0 0 2 running 8soc soctcpio
> 9 f51dcc0 0 3 sleeping forever 1cpu soctcplst
> 10 f48db38 f3aa500 2 sleeping forever 1cpu flush_sub(0)
>
> 11 f48dda8 f3aa9e8 2 sleeping forever 1cpu flush_sub(1)
>
> 12 f4ac138 0 4 sleeping forever 5aio kaio
> 13 f4ac710 0 4 sleeping forever 1cpu kaio
>
> Could you explain that?
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--0016368e24ce1124160465de4f47
On Windows, both raw disks and NTFS use kernel asynchronous I/O (KAIO). The
Windows file system manager adds additional overhead to disk I/O, so using raw
disks provides slight performance advantages. Because NTFS files are a more
standard method of storing data, you should use NTFS files instead of raw
disks. Consider using raw disks if your database server requires a large
amount of disk access.
--- On Tue, 3/24/09, Art Kagel <art.kagel@gmail.com> wrote:
> From: Art Kagel <art.kagel@gmail.com>
> Subject: Re: RE: IDS 7.31 Solaris8 - Long Checkpoints [15320]
> To: ids@iiug.org
> Date: Tuesday, March 24, 2009, 9:34 AM
> WIndows is a special case.
>
> Art
>
> Art S. Kagel
> Oninit (www.oninit.com)
> IIUG Board of Directors (art@iiug.org)
>
> Disclaimer: Please keep in mind that my own opinions are my
> own opinions and
> do not reflect on my employer, Oninit, the IIUG, nor any
> other organization
> with which I am associated either explicitly or implicitly.
> 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 Tue, Mar 24, 2009 at 9:33 AM, KURT VAN GOMPEL <
> kvangompel@caami-hziv.fgov.be>
> wrote:
>
> > Hello,
> >
> > Sorry for the long delay!
> > I understand I have to add aio vps to resolve the
> problem.
> > I read that IDS starts kaio vps if possible: OS must
> support it, raw
> > devices.
> > We have some Windows NT4 servers with IDS 7.31 TC6 on
> it and chunks on
> > cooked
> > devices; there I see kio vps and kaio threads too.
> >
> > Informix Dynamic Server Version 7.31.TC6 -- On-Line --
> Up 10:54:24 --
> > 172608
> > Kbytes
> >
> > AIO I/O vps:
> > class/vp s io/s totalops dskread dskwrite dskcopy
> wakeups io/wup errors
> > kio 0 i 0.0 0 0 0 0 0 0.0 0
> > kio 1 i 1.1 44510 34298 10212 0 44538035 0.0 0
> > msc 0 i 0.0 842 0 0 0 254 3.3 0
> > aio 0 i 0.0 419 27 300 0 45 9.3 0
> > pio 0 i 0.0 0 0 0 0 1 0.0 0
> > lio 0 i 0.0 0 0 0 0 1 0.0 0
> >
> > C:\\\\INFORMIX\\\\bin>onstat -g ath
> >
> > Informix Dynamic Server Version 7.31.TC6 -- On-Line --
> Up 10:55:41 --
> > 172608
> > Kbytes
> >
> > Threads:
> > tid tcb rstcb prty status vp-class name
> > 2 f48cf48 0 2 sleeping forever 3lio lio vp 0
> > 3 f48d1e0 0 2 sleeping forever 4pio pio vp 0
> > 4 f48d478 0 2 sleeping forever 5aio aio vp 0
> > 5 f48d710 0 2 sleeping forever 6msc msc vp 0
> > 6 f51c138 f3aa018 4 sleeping secs: 1 1cpu main_loop()
>
> > 7 f51cc30 0 2 running 7soc soctcppoll
> > 8 f51d4a0 0 2 running 8soc soctcpio
> > 9 f51dcc0 0 3 sleeping forever 1cpu soctcplst
> > 10 f48db38 f3aa500 2 sleeping forever 1cpu
> flush_sub(0)
> >
> > 11 f48dda8 f3aa9e8 2 sleeping forever 1cpu
> flush_sub(1)
> >
> > 12 f4ac138 0 4 sleeping forever 5aio kaio
> > 13 f4ac710 0 4 sleeping forever 1cpu kaio
> >
> > Could you explain that?
> >
> >
> >
> >
>
*******************************************************************************
>
> > Forum Note: Use "Reply" to post a response in the
> discussion forum.
> >
> >
>
> --001636af022eba0acf0465de4878
>
>
>
*******************************************************************************
>
> Forum Note: Use "Reply" to post a response in the
> discussion forum.
>
>
Related threads
- Posting from the Informix-list
- Migrating from IDS 9.40.UC6 to 11.50.UC3
- Ip for a network session
- questions onstat -g