Informix settings under high load.

Posted in 1998

Albert wisse — Tue, 10 Feb 1998 12:24:19 +0100 — source: Informix-list mailing list archive (1991-1998)

--------------31783B76F484EF57A146E3A5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I want to share my experience with Informix under high load and if anybody has other experience then let me now. The objective of the tests I did was to get the server/informix so that it won't trash under (very) high load. The server is a SUN UltraSparc Enterprise server with: - Eight 167 Mhz UltraSparc CPU's, six CPU's used by informix. - 1.5 GB Internal memory. - SSA disk subsystem with eight 2 GB drives used by Informix. - OS Solaris 2.5.1. Informix setup: only raw devices are used for the table spaces and the physical, logical log, system (rootdbs), application tables and indexes have there own drive. The amount of buffers is set so that cache hit ratio is around 99%. When the server is overloaded, due a high number of concurrent transactions then performance drops by a factor of four/six. The server is bounded by CPU or/and I/0. In case of overload of the server, this not common practice but if it happens then system must be stable it shouldn't crash. What I seen and have changed compared to a normal/intial Informix setup. - I got often "long transaction aborted" so I increased the logical log size to eight times the amount under normal load then the problem vanished. - My checkpoint time increased such that I saw that the Informix was dead for the client for a while and that increased the stress on the server. I lowered the LRU_MAX_DIRTY and LRU_MIN_DIRTY to 15 an 10 and set CKPTINTVL to 60. This lowered the checkpoint time. It is posible to lower them even more because the disks can cope with the (extra) load. - During the heavy load I got the Informix message that it waits for a check point why I don't no yet . I did extra's checkpoints to circumvent this problem. - I got the message that I was out of locks so I increased the number of locks by four. - I saw bufwaits, I have read in another news message of Art S. Kagel that you have to increase the number of LRUS to avoid them but what is the impact of many LRUS's say 64 LRUS instead of 8 LRUS. Is there a guide line when to increase the number of LRUS to get ride of bufwaits.With which other parameter do I to compare bufwaits to find a ratio that indicates to increase the LRUS's. For the rest it looks good: the cache hit ratio is good, I have no Fore Ground Writes and the load of the disks are balanced well. To do's: - Reducing the checkpoint impact. - Mirror all the dbspaces and then test the behavior again. Regards, Albert Wisse --------------31783B76F484EF57A146E3A5 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <HTML> I want to share my experience with Informix under high load and if anybody has other experience then let me now. The objective of the tests I did was to get the server/informix so that it won't trash under (very) high load. The server is a SUN UltraSparc Enterprise server with: - Eight  167 Mhz UltraSparc CPU's, six CPU's used by informix. - 1.5 GB Internal memory. - SSA disk subsystem with eight 2 GB drives used by Informix. - OS Solaris 2.5.1. Informix setup: only raw devices  are used for the table spaces and the physical, logical log, system (rootdbs), application tables and indexes have there own drive. The amount of buffers is set so that cache hit ratio is around 99%. When the server is overloaded, due a high number of concurrent transactions  then  performance drops by a factor of four/six. The server is bounded by CPU or/and I/0. In case of overload of the server, this not common practice but if it happens  then system must be stable it shouldn't crash. What I seen and have changed compared to a normal/intial  Informix setup. - I got often "long transaction aborted" so I  increased the logical log size to eight times the amount under normal load then the problem vanished. - My checkpoint time increased such that I saw that the Informix was dead for the client for a while and that increased the stress on the server. I lowered the LRU_MAX_DIRTY and LRU_MIN_DIRTY to 15 an 10 and set CKPTINTVL to 60.  This lowered the checkpoint time. It is posible to lower them even more because the disks can cope with the (extra) load. - During the heavy load I got the Informix message that it waits for a check point why I don't no yet . I did extra's checkpoints to circumvent this problem. - I got the message that I was out of locks so I increased the number of locks by four. - I saw bufwaits, I have  read in another news message of Art S. Kagel that you have to increase the number of LRUS to avoid them but what is the impact of many LRUS's say 64 LRUS instead of 8 LRUS. Is there a guide line when to increase the number of LRUS to get ride of bufwaits.With which other parameter do I  to compare bufwaits to find a ratio that indicates to increase the LRUS's. For the rest it looks good: the cache hit ratio is good, I have no Fore Ground Writes and the load of the  disks are balanced well.   To do's: - Reducing the checkpoint impact. - Mirror all the dbspaces and then test the behavior again.   Regards, Albert Wisse              </HTML> --------------31783B76F484EF57A146E3A5--