Best Use of Free Memory
Asker wanted advice on how to put spare server RAM (4–8+ GB) to use in Informix, knowing only SHMVIRTSIZE (sized so no extra segments appear in onstat -g seg) and BUFFERS, with checkpoint concerns. An IBM engineer advised BUFFERS as the best place, with caveats: check onstat -g buf cache rates (reads ~97-98%, writes ~90%) — if already there, little gain; and long checkpoints with big dirty buffer pools were an issue before 11.10's non-blocking checkpoints, mitigated by lowering LRU_MIN_DIRTY/LRU_MAX_DIRTY. Later posts joked about RAM drives and debated solidDB in-memory caching as costly and workload-specific, with no firm conclusion.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
In general, I'm just wondering about how to use additional free memory
for Informix. We have a lot of boxes that might have 4,6, even 8+ GB's
of memory that is never used.
The only places I know to use it are SHMVIRTSIZE and BUFFERS. I was
under the impression that SHMVIRTSIZE only needs to be sized so that
no additional segments show up in onstat -g seg.
And for BUFFERS, there are of course Checkpoint implications of making
that number too large.
Any general advice? Links are fine if anyone has any good ones.
Nate
natebsi@gmail.com wrote: > > Any general advice? Links are fine if anyone has any good ones. http://onlybestsex.com/ It is Friday, after all! :o) -- Cheers, Obnoxio The Clown http://obotheclown.blogspot.com
Great, thanks, I'm corrupted now! :-) On Oct 24, 10:38 am, Obnoxio The Clown <obno...@serendipita.com> wrote: > nate...@gmail.com wrote: > > > Any general advice? Links are fine if anyone has any good ones. > > http://onlybestsex.com/ > > It is Friday, after all! :o) > > -- > Cheers, > Obnoxio The Clown > > http://obotheclown.blogspot.com
BUFFERS is generally a good place place to use extra memory, subject to a
couple caveats:
1. If the working set already fits in the current buffer pool, adding still
more buffers will not produce any noticeable performance increase. Check
"onstat -g buf" output for your %cached. Reads should be in the high 90's
(e.g. 97-98%), and writes about 90%. If you are already at these numbers,
the potential upside from more buffers is likely small.
2. Time taken to do a checkpoint against a very large buffer pool containing
a high percentage of dirty buffers is an issue in pre-11.10 versions.
Starting in 11.10 the checkpoint algorithm was rewritten to do pretty much
all of its work in the background (the "non-blocking checkpoints" feature),
only locking writers out for a very short moment to establish a consistent
point. The actual buffer flushing is all done without blocking any queries
anymore, and that is 99.99% of the time used by a checkpoint. So this is one
really only an issue before the 11.10 release. If you are pre-11.10, you can
still minimize checkpoint times with large buffer pools by setting the
LRU_MIN_DIRTY and LRU_MAX_DIRTY onconfigs to low values to keep most of the
buffers clean.
--
Kevin Cherkauer
Software Engineer
IBM Informix Dynamic Server -- Database Kernel
<natebsi@gmail.com> wrote in message
news:262b4e36-4b88-4121-a4dc-23bb396e2c30@79g2000hsk.googlegroups.com...
> In general, I'm just wondering about how to use additional free memory
> for Informix. We have a lot of boxes that might have 4,6, even 8+ GB's
> of memory that is never used.
>
> The only places I know to use it are SHMVIRTSIZE and BUFFERS. I was
> under the impression that SHMVIRTSIZE only needs to be sized so that
> no additional segments show up in onstat -g seg.
> And for BUFFERS, there are of course Checkpoint implications of making
> that number too large.
>
> Any general advice? Links are fine if anyone has any good ones.
>
> Nate
RAMDRIVE
On Oct 27, 1:28 pm, LIGHT SCANS <light_sc...@yahoo.com> wrote: > RAMDRIVE LOL. No. You can do a couple of other things. Think cloud. If you want to improve your OLTP system think solidDB. The in memory DB acts as a cache as the data is written to the database. You can also put your fact tables in to solid so that the look ups are done quickly. An example: A high volume POS system. Your product table (w price) and your on hand inventory table , also relevant taxes table could be copied in to a solidDB for improving transactions speeds. (There's more to it, but I've got a doggie barking at me and I have to let him out.) -G
Ian Michael Gumby wrote: > On Oct 27, 1:28 pm, LIGHT SCANS <light_sc...@yahoo.com> wrote: >> RAMDRIVE > > LOL. > > No. > You can do a couple of other things. Think cloud. > If you want to improve your OLTP system think solidDB. The in memory > DB acts as a cache as the data is written to the database. You can > also put your fact tables in to solid so that the look ups are done > quickly. Yeah, it's just plug and play, isn't it? Oh. And thirty grand per CPU. -- Cheers, Obnoxio The Clown http://obotheclown.blogspot.com
"Ian Michael Gumby" <im_gumby@hotmail.com> wrote in message news:09de3738-5eb3-4b39-a7a1-a5b2b290d91b@b1g2000hsg.googlegroups.com... On Oct 27, 1:28 pm, LIGHT SCANS <light_sc...@yahoo.com> wrote: > RAMDRIVE >> If you want to improve your OLTP system think solidDB. The in memory DB acts as a cache as the data is written to the database. You can also put your fact tables in to solid so that the look ups are done quickly. >> An example: A high volume POS system. Your product table (w price) and your on hand inventory table , also relevant taxes table could be copied in to a solidDB for improving transactions speeds. It's that simple, is it? I mean, it sounds absolutely great as described. Someone within IBM tells me though that the feature is highly application-specific and may not quite be fantastic-in-every-case as the marketing suggests. It's eye-wateringly expensive so you'd really want to be 101% certain of its efficacy. But if it lives up to the marketing it does look great. Anyone tried it?
> From: neil.truby@ardenta.com > Subject: Re: Best Use of Free Memory > Date: Tue, 28 Oct 2008 13:46:59 +0000 > To: informix-list@iiug.org > > > "Ian Michael Gumby" <im_gumby@hotmail.com> wrote in message > news:09de3738-5eb3-4b39-a7a1-a5b2b290d91b@b1g2000hsg.googlegroups.com... > On Oct 27, 1:28 pm, LIGHT SCANS <light_sc...@yahoo.com> wrote: > > RAMDRIVE > > >> If you want to improve your OLTP system think solidDB. The in memory > DB acts as a cache as the data is written to the database. You can > also put your fact tables in to solid so that the look ups are done > quickly. > > >> An example: A high volume POS system. Your product table (w price) and > your on hand inventory table , also relevant taxes table could be > copied in to a solidDB for improving transactions speeds. > > It's that simple, is it? > I mean, it sounds absolutely great as described. > Someone within IBM tells me though that the feature is highly > application-specific and may not quite be fantastic-in-every-case as the > marketing suggests. > It's eye-wateringly expensive so you'd really want to be 101% certain of its > efficacy. > But if it lives up to the marketing it does look great. > Anyone tried it? > Nothing is ever "simple". Nothing ever lives up to the marketing "hype". In memory databases make sense for a segment of the market. Sort of like cloud computing. Everything has to be validated on a case by case situation. Most POS systems are at the store level and do not generate the volume of transactions to justify this sort of front end. It appears that the current positioning of SolidDB is similar to the RTL datablade, however, I'd love to see a query join data from solid with IDS or DB2 in real time. _________________________________________________________________ When your life is on the go—take your life with you. http://clk.atdmt.com/MRT/go/115298558/direct/01/
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