Shared Memory Size vs Physical Memory Size

Can somebody please explain the pros and cons of increasing either the initial virtual memory segment or adding a further segment via "onmode - a" on a machine that is Informix Dynamic Server dedicated. Our calculated shared memory size, as can be seen below, is only some 50% of our actual physical memory. Any pointers/hints would, as ever, be much appreciated. We have two instances running (LIVE and TEST) - see outout from onstat below. Our Informix application connects via shared memory. ICL Teamserver M754i SCO Openserver 5.0.4 (finally Y2K compliant ! as at yesterday !!) Informix Dynamic Server 7.30.UC2 640Mb RAM LIVE onstat yields 258048 Kbytes TEST onstat yields 90112 Kbytes As can be seen, the sum of the above is somewhat less than 640Mb. Regards Glyn Balmer -- If it always works, why don't parachutists pull the emergency 'chute first? Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't.

Glynnie wrote in message <7kb1o2$kru$1@nnrp1.deja.com>... >Can somebody please explain the pros and cons of increasing either the >initial virtual memory segment or adding a further segment via "onmode - >a" on a machine that is Informix Dynamic Server dedicated. The rule of thumb is that fewer, larger shared memory segments are better. There is less overhead for the engine to keep track of individual memory segments, so if you have one large initial segment vs. a smaller initial with several additional segments this is less work for OnLine. This is limited though, by the kernel parameters. If the max seg size is 4MB and you specify an Informix intial segment size of 8MB, when you do an ipcs -m you will see two segments at the Unix OS level instead of the one you were expecting to get. Make sure the OS supports the largest segment size you want to declare, or as close to it as possible. You mentioned the fact that your application connects through shared memory, so at least some part of your application processes must reside on the same physical server as IDS. This would indicate that the box isn't totally dedicated as an OnLine database server only, so be careful of dedicating too much memory to the server, thereby starving your applicatons of much needed RAM. This will be a balancing act between the OS, your apps and the DB server. Is your applicaton OLTP or data warehousing (i.e. lots of PDQ queries)? If it is OLTP, then the area of concentration should be the buffer pool / LRU queues in resident memory, not necessairly the pools in the virtual segments. If you execute lots of PDQ queries, then giving OnLine megabytes of virtual memory for sort pools and such would be the correct approach to improving query performance (this is also really helpful for index builds as well). Keaton