Re: mdconfig unable to allocate memory
From: Chris BeHanna (chris_at_behanna.org)
Date: 02/28/04
- Previous message: sebastian ssmoller: "buildworld failure"
- In reply to: Chris Elsworth: "Re: mdconfig unable to allocate memory"
- Next in thread: Bruce Evans: "Re: mdconfig unable to allocate memory"
- Reply: Bruce Evans: "Re: mdconfig unable to allocate memory"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: freebsd-current@freebsd.org Date: Sat, 28 Feb 2004 03:53:16 -0500
On Friday 27 February 2004 09:17, Chris Elsworth wrote:
> On Fri, Feb 27, 2004 at 02:08:48PM +0000, Colin Percival wrote:
> > At 13:58 27/02/2004, Chris Elsworth wrote:
> > >So, in short, is there any rule of thumb to follow when tweaking these
> > >settings?
> >
> > Yes, several:
> > 1. Don't do it.
> > 2. Pray.
> > 3. Don't do it.
> > 4. If you absolutely must do it, make sure you have a serial console
> > connected.
> > 5. Don't do it.
>
> Right, got it :) Having the machine crash is no problem. It's sat in
> my lounge, so I can tweak and reboot and restore from kernel.generic
> to my hearts content. This seems to be a problem that's been gone over
> and over and over again, but never with any clear answer according to
> Google. Given a FreeBSD machine with 4GB in it, be it 4 or 5, how can
> one ensure that all the memory is being used for suitable file caching
> if it's running MySQL? I was aiming at raising vfs.maxbufspace to be
> 2GB or so. Since that was just resuling in kernel panics pretty much
> whatever I tried, I was giving mdconfig a go.
There may be *some* tuning to do, but honestly, this is what the
buffer cache was designed to do, *automatically*. Data that have been
fetched from disk is kept on one of several LRU lists, which are in
turn cross-linked into chains hanging from the buffer hash table for
quick lookup. Once your working set is cached, the only things that
can cause it to be flushed are:
1) The periodic (every 30 seconds by default) syncing out of dirty
buffers (buffers that you have changed since reading them in)
to storage (this does not cause the buffer to be thrown away,
but it does allow it to be marked "clean"), and
2) Memory pressure from other applications.
Chapter 6 in _The Design and Implementation of the 4.4 BSD
Operating System_ (available from most well-stocked major booksellers,
and maybe also in a well-stocked library) explains how file systems
and the buffer cache interact in a quite accessible manner. Before
you go making changes that you think you need, I strongly recommend
that you read this chapter.
> > > It's a bit worrying that an out of the box 5.2.1 managed to
> > >crash at all.
> >
> > The fact that running out of kernel address space can cause
> > problems is quite well documented.
>
> Well, yes, but why would "vinum start" on a clean boot before any
> tweaking (this is an out of the box 5.2.1-R) cause that? Surely the
> kernel address space is sufficiently large just by self-tuning on a
> machine with 4GB, for a vinum start to succeed?
Vinum is somewhat broken in 5.2.1. This is being worked.
> > Why do you want to have a GB malloc-backed disk anyway?
>
> This machine is for MySQL, and there's a wild un-backed-up claim on
> a mysql list that moving MySQL indexes into a ramdisk (they're all
> trashable data and easily recreateable) can give a fourfold
> performance increase. So I wanted to try it. In order to get them all
> in there, though, I'm going to need at least 2GB.
>
> I think I'm just missing the point of having a swap backed memory
> disk, really; I assumed that it would immediately start dumping
> anything I put in it, into swap, causing disk access. Does it only put
> stuff into swap once it runs out of address space?
A swap-backed file system will attempt to use the buffer cache to
contain its data. That data only gets written to disk if you have
sufficient memory pressure to cause your system to begin swapping.
I have 1GB of RAM in my workstation. I had a wild hair when I
installed it, and made a 700MB swap-backed scratch area, and did a
buildworld to see how fast it would be. The system survived just
fine. I would think that you should be able to make a 2GB swap-backed
file system with 4GB of RAM without a problem, but there may be some
autoscaled tunables that don't scale that high correctly.
At any rate, as with most databases, it's quite likely that you
will have "hot spots" in yours, in which case, it's not that big of a
crime if *all* of your indexes can't be fit into memory, so long as
the ones that are most used are in memory. If 2GB won't fit (this
does not mean that you can't make a swap-backed file system of size
2GB, it just means that you might not fit the whole thing into memory
at the same time--the portion that won't fit will be sitting in your
swap partition on your disk), FreeBSD will automatically keep the
most-recently-used data in memory, swapping the least-recently-used
data if and only if memory pressure forces it to do so. You can
minimize the cost of cache misses for your swap-backed file system by
striping your swap space across two or more disks (effectively, RAID-0
for your swap. My understanding is that FreeBSD will do that
automatically, given swap areas of equal size on each physical
device).
--
Chris BeHanna
Software Engineer (Remove "bogus" before responding.)
chris@bogus.behanna.org
Turning coffee into software since 1990.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
- Previous message: sebastian ssmoller: "buildworld failure"
- In reply to: Chris Elsworth: "Re: mdconfig unable to allocate memory"
- Next in thread: Bruce Evans: "Re: mdconfig unable to allocate memory"
- Reply: Bruce Evans: "Re: mdconfig unable to allocate memory"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
