Informix page cleaners (w/ a SAN)
We have read some tuning recommendations that seem to indicate that for IDS 10: If you have fewer than 20 disks you should use 1 cleaner/disk With 20 - 100 disks you should set 1 cleaner for every other disk. (We are currently set to 128) We run on HPUX 11 (PA-RISC) connected to an older HP Fiber SAN exposed to us as 90 to 100 LUNS (which are used as raw chunks for the dbspaces). Could anyone give a recommendation on how, if at all, the above recommendation would fit into an environment like ours? Thanks -JM James Maes | Software Architect | Main: 314.997.1854 ext. 3422 | Materialogic Your Supply Chains Strongest Link | www.materialogic.com CONFIDENTIALITY NOTICE: This email message and all attachments are intended solely for the use of the addressee and may contain privileged and confidential information. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately at 1-800-333-7144 or the e-mail address above and destroy the original message. Thank You.
Hi James, please tell us a bit more about your SAN config. Those 90 to 100 LUNs exposed to your server, how are they carved out of physical SAN disks? How many physical disks are there in the SAN itself? In which way are the LUNs spread across them? Regards Davorin
2 Disk groups of 10 disks each. 30 of the Luns from the first disk group, 60ish from the second James Maes | Software Architect | Main: 314.997.1854 ext. 3422 | Materialogic Your Supply Chains Strongest Link | www.materialogic.com CONFIDENTIALITY NOTICE: This email message and all attachments are intended solely for the use of the addressee and may contain privileged and confidential information. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately at 1-800-333-7144 or the e-mail address above and destroy the original message. Thank You. -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of DAVORIN KREMENJAS Sent: Thursday, April 16, 2009 6:24 AM To: ids@iiug.org Subject: Re: Informix page cleaners (w/ a SAN) [15539] Hi James, please tell us a bit more about your SAN config. Those 90 to 100 LUNs exposed to your server, how are they carved out of physical SAN disks? How many physical disks are there in the SAN itself? In which way are the LUNs spread across them? Regards Davorin **************************************************************************** *** Forum Note: Use "Reply" to post a response in the discussion forum.
James, are you experiencing any issues, long checkpoints maybe? You have 90ish chunks and 128 CLEANERS. During checkpoint each cleaner gets assigned to one chunk (in the order of chunk creation) so you're on the safe side there, the extra cleaners should just idle. Regards Davorin
There are other competing recommendations also. You should have at least as many CLEANERS and LRUS (or the total of all lru parameters in all of the BUFFERPOOL settings). Another is one per physical disk (with SANS and other large arrays that one has gotten mostly deprecated.) The bottom line is that you need enough CLEANER threads running to efficiently flush all dirty buffers without affecting production be blocking code from entering critical sections during checkpoints for too long. At checkpoint time that means one cleaner per chunk as checkpoint writes are assigned to cleaners by chunk. This is the one that allows only half that number if there are lots of chunks and especially if they all reside on one or a few physical structures to minimize the possibility that you will be limited by the bandwidth of the strucuture or its channels. At LRU flush time (LRU_MIN/MAX_DIRTY) you need at least one CLEANER per LRU queue because dirty pages are assigned to cleaners by LRU queue. Again, on a moderately busy system with only a few structures you can get away with half that number for the same reasons and also because on average only half of the LRU queues will reach LRU_MAX_DIRTY at any given time. However, if the system is typically busy enough to cause all of the LRU queues to reach the LRU_MAX_DIRTY threshold at the same time, then you will need more CLEANERS. 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 Wed, Apr 15, 2009 at 3:28 PM, James Maes <jmaes@materialogic.com> wrote: > We have read some tuning recommendations that seem to indicate that for IDS > 10: > > If you have fewer than 20 disks you should use 1 cleaner/disk > With 20 - 100 disks you should set 1 cleaner for every other disk. > > (We are currently set to 128) > > We run on HPUX 11 (PA-RISC) connected to an older HP Fiber SAN exposed to > us > as 90 to 100 LUNS (which are used as raw chunks for the dbspaces). > > Could anyone give a recommendation on how, if at all, the above > recommendation would fit into an environment like ours? > > Thanks > -JM > > James Maes | Software Architect | Main: 314.997.1854 ext. 3422 | > Materialogic Your Supply Chains Strongest Link | www.materialogic.com > CONFIDENTIALITY NOTICE: This email message and all attachments are intended > solely for the use of the addressee and may contain privileged and > confidential information. If you are not the intended recipient, you are > hereby notified that any dissemination, distribution, copying, or other use > of this message or its attachments is strictly prohibited. If you have > received this message in error, please notify the sender immediately at > 1-800-333-7144 or the e-mail address above and destroy the original > message. > Thank You. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --0016e642d64a4caf3c0467c10dc7