Does 5.0.6 support more than 450000 NBUF?
Jeff Poulin
buffer (about 1.5GB). We own two versions of OpenServer (5.0.4 & 5.0.5),
but both limit the number of NBUFs to 450000. We'd seriously consider 5.0.6
if it supported a larger disk buffer, but I can't find any info on whether
or not it does. Does anyone know?
Bela Lubkin
The buffer cache continues to be limited to 450MB.
>Bela<
Jeff Poulin
Okay, thanks Bela.
-- Jeff Poulin
Tom Parsons
What kind of justification do you have for wanting such horrendously
large buffer cache?
Use sar to look at your buffer stats (sar -b)
Are your read (%rcache) and write (%wcache) percentages that low?
If they are in the high 90's, you aren't going to get much benefit
from a large cache and the excess overhead will likely result in slowing
the system.
--
==========================================================================
Tom Parsons t...@tegan.com
==========================================================================
Mike Brown
I agree with Tom, there is a sweet spot for tuning the disk cache buffer size.
However, if you have a database app that is almost all lookups and can be fit
inside of available ram, then a large disk buffer helps. IE, moving a parts
lookup database to its own machine, disabling all extra services, and running
a large buffer makes a quick machine.
In the real world, with read/write and a database > available ram, tune for
at least 85% rcache, and break out the champagne if you hit 94%.
The wcache number needs a bit more explanation, check man. Simplified, all
writes hit cache, sometimes the same "file" is written many times. If that
value in cache has not been written to disk yet, then it gets overwritten
in cache, and contributes to the %wcache number. You could have 0% wcache
stats and have no problem with performance.
I have found that Unixware on a SMP machine does optimize memory usage better
than openserver, and OpenUNIX8 overall is very quick on large databases.
What is your app?
Mike
--
Michael Brown
The Kingsway Group
Bill Vermillion
Bela - it would seem to me that such a large disk buffer could be
problematic, could it not.
I know in the past JeffL had discussions about this. It would seem
to me that it could take much longer to flush when it was needed.
Any comments on that? Have things changed?
Bill
John DuBois
>Bela - it would seem to me that such a large disk buffer could be
>problematic, could it not.
>
>I know in the past JeffL had discussions about this. It would seem
>to me that it could take much longer to flush when it was needed.
>
>Any comments on that? Have things changed?
I use a 450M buffer cache on a busy system without problems. Gets me
70%rcache/65%wcache. I set BDFLUSHR to 5 and NAUTOUP to 5, to reduce the
flushing issue.
John
--
John DuBois spc...@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/
Simon Hobson
(in message <2002011118...@tegan.com>):
> Jeff Poulin enscribed:
>> I have a machine with 2GB of RAM and would like have a very large disk
>> buffer (about 1.5GB). We own two versions of OpenServer (5.0.4 & 5.0.5),
>> but both limit the number of NBUFs to 450000. We'd seriously consider
>> 5.0.6
>> if it supported a larger disk buffer, but I can't find any info on whether
>> or not it does. Does anyone know?
> What kind of justification do you have for wanting such horrendously
> large buffer cache?
He's not the only one. If the OS supported it I'd have a machine with AT
LEAST 8G, preferably 12G of disk buffers. At times we can get our system to
90%+ WIO (I think I've seen 99% !) when the crap reporting tool that certain
people (in this case the IT manager) insist on using runs certain reports and
does sequential searches through files of over 1G (the total data size is
something like 8-10G).
I'd take the hit that we'd occasionally get from flushing such a large buffer
to keep all the live data in RAM (most of the time). In any case, I don't
think we'd actually have much data to flush as there is a lot of read, but
little write, activity and I'd still keep the BDFLUSHR and NAUTOUP values
fairly low.
Considering the cost of RAM these days, 450M is a piffling figure to limit
buffers to !
Simon
Matt Schalit
Does that mean 5 sec or so between flushing and writing
to the disk the data that's in the buffer? So potentially
you risk 5 sec. of data? Curious.
Thanks,
Matt
John DuBois
Matt Schalit <msch...@pacbell.net> wrote:
>On 12 Jan 2002 12:17:29 GMT, spc...@deeptht.armory.com (John DuBois) wrote:
>>I use a 450M buffer cache on a busy system without problems. Gets me
>>70%rcache/65%wcache. I set BDFLUSHR to 5 and NAUTOUP to 5, to reduce the
>>flushing issue.
>
>to the disk the data that's in the buffer? So potentially
>you risk 5 sec. of data? Curious.
Yes, but that isn't why I have them set low. If it were just a matter of
safety, I'd have them set to 30s (this system has been rock solid since I
upgraded from 5.0.0 to 5.0.6a). I have them set low to reduce the tendency
for a large amount of buffered write data to build up and hog disk bandwidth
when it comes time to flush.
And yes, I too wish I could have >450M of buffers. I have 1GB of memory in
this system; I'd throw another 3GB (~free) in it and use it all for buffers if
I could. Unfortunately the kernel memory layout would require some non-trivial
rearrangement to allow that.
Matt Schalit
>In article <3c40ac29...@64.164.98.7>,
>Matt Schalit <msch...@pacbell.net> wrote:
>>On 12 Jan 2002 12:17:29 GMT, spc...@deeptht.armory.com (John DuBois) wrote:
>>>I use a 450M buffer cache on a busy system without problems. Gets me
>>>70%rcache/65%wcache. I set BDFLUSHR to 5 and NAUTOUP to 5, to reduce the
>>>flushing issue.
>>
>>Does that mean 5 sec or so between flushing and writing
>>to the disk the data that's in the buffer? So potentially
>>you risk 5 sec. of data? Curious.
>
>Yes, but that isn't why I have them set low.
(chuckle) I thought they were kinda high :-o
I think Uw7 has them set for 1 sec by default.
Thanks for the reply,
Matt
Bela Lubkin
If you configured the full 450MB buffer cache and then ran a program
which wrote a full 450MB of data very quickly, yes, you'd see a
performance hit. All 450MB would sit in cache for a while, then it
would all want to be written to disk at once.
Well, not sure that's a performance hit. Suppose there was no write
cache. Then you'd be asking the system to write 450MB all at once.
That would take however long it took your disk system to cart 450MB of
junk out to the disk. Now interpose the buffer cache: so now, you fill
450MB of buffers with data, it sits for a while, _then_ it all wants to
go out to disk at once. Which again takes however long it takes to
physically send that much data out.
You can mitigate this sort of thing a little bit by fooling with the
BDFLUSHR and NAUTOUP parameters, but nothing will protect you from what
I'm describing. That is, if you tell the disk to write a huge amount
of data, it is eventually going to be the case that your disk will be
busy for as much time as it takes to write that much data. That's sort
of a tautology, but apparently it comes as a surprise to some people.
>Bela<
Bill Vermillion
Bela Lubkin <be...@caldera.com> wrote:
>Bill Vermillion wrote:
>
>> Bela Lubkin <be...@caldera.com> wrote:
>> >Jeff Poulin wrote:
>> >> I have a machine with 2GB of RAM and would like have a very large
>> >> disk buffer (about 1.5GB). We own two versions of OpenServer
>> >> (5.0.4 & 5.0.5), but both limit the number of NBUFs to 450000.
>> >> We'd seriously consider 5.0.6 if it supported a larger disk
>> >> buffer, but I can't find any info on whether or not it does. Does
>> >> anyone know?
>>
>> >The buffer cache continues to be limited to 450MB.
>> Bela - it would seem to me that such a large disk buffer could be
>> problematic, could it not.
>> I know in the past JeffL had discussions about this. It would seem
>> to me that it could take much longer to flush when it was needed.
>> Any comments on that? Have things changed?
>If you configured the full 450MB buffer cache and then ran a program
>which wrote a full 450MB of data very quickly, yes, you'd see a
>performance hit. All 450MB would sit in cache for a while, then it
>would all want to be written to disk at once.
If I understand this correctly then only when you have a program
that writes a huge amount at once if you have 450MB cache will that
occur. That would appear that the buffer cache is being flushed
rapidly enough in normal operation so the cache never gets to the
point of needing to be flushed all at one time.
I remember when the disk flushing was a many second interval and
you could see little pauses on a heavily loaded system about every
10 to 15 seconds.
>Well, not sure that's a performance hit. Suppose there was no write
>cache. Then you'd be asking the system to write 450MB all at once.
>That would take however long it took your disk system to cart 450MB of
>junk out to the disk. Now interpose the buffer cache: so now, you fill
>450MB of buffers with data, it sits for a while, _then_ it all wants to
>go out to disk at once. Which again takes however long it takes to
>physically send that much data out.
It would seem that unless you totally fill the buffer it would make
some sense to write a bit as you go along so that bits/pieces are
being flushed to the disk an a regular basis. With the ever
growing cache on the HD's anymore [I think I've seen 8MB as
internal buffer and it could be more now] I can see data passing
through a lot of caches before it gets to a final destination.
>You can mitigate this sort of thing a little bit by fooling with the
>BDFLUSHR and NAUTOUP parameters, but nothing will protect you from what
>I'm describing. That is, if you tell the disk to write a huge amount
>of data, it is eventually going to be the case that your disk will be
>busy for as much time as it takes to write that much data. That's sort
>of a tautology, but apparently it comes as a surprise to some people.
Thanks for the clarifications. The original poster seemed to have an
application that was a bit out of the ordinary. I would think that
for many users 450MB cache might be considered overkill.
Bill
--
Bill Vermillion - bv @ wjv . com