Re: Multiple storeio types?

On Friday 09 November 2001 08.58, Joe Cooper wrote:

> > Should work.. the aufs store should also work. The amount of aufs threads
> > can be tuned to fit your needs.
>
> Per cache_dir?

There is only a total amount in the way async-io is designed.

By default this total amount is based on the number of cache directories you
have, but you can tune this to whatever you want at compile time.

I also have a patch somewhere allowing tuning via the cache_dir lines..

But using async-io or diskd for a RAM disk is pure waste of resources. "ufs"
is the correct model there.

> Yep, I have my reasons. ;-) Because Squid wants to write everything to
> disk, and with only two IDE disks to write to, I can't afford those
> write ops. I'm trying to push 150 reqs/sec+ out of two 7200 RPM IDE
> disks...which just does not work when Squid is writing every object (we
> max at about 110--no matter what the bdflush/elvtune parameters are).
> So I'm 'filtering' the smaller objects into a RAM disk...because they're
> so small and the block size is 1024, we can cram a couple hundred
> thousand objects into a 512MB RAM disk...about half the number of
> objects that go into the real disks at 7.5GB each. Works surprisingly
> well, and with 2GB of RAM costing under $200, it's a performance bargain
> (two more IDE disks would cost the same, but gain less throughput).

So what you actually want is to tune the policy to stuff small objects onto
the ramdisk, and larger objects onto the drives. No need to adjust priorities
for this, only size selections.

Note that this problem is exacly why a cache store should be log or chunk
based, not file based. By collecting objects into larger linear chunks you
make writing dependent on the bandwidth only, not number of obejcts.

> The weird behavior I refer to is that it insists on getting very swappy
> when Squid gets over ~450MB in process size, even though there is a
> /ton/ of memory available for playing with. As soon as it has to start
> swapping parts of Squid back in, performance drops, and eventually
> everything slows to a crawl. I don't know why Linux would swap out
> parts of a big process while there is plenty of memory available, but
> for whatever reason the same size RAM disk doesn't cause this swap
> thrashing to occur. Maybe this is a phenomenon similar to what was seen
> on Irix, with memory thrashing leading to no memory blocks large enough
> to allocate. I don't know. Will look deeper into it after the cacheoff.

Probably true. You have to compete with writes, and if there are portions of
Squid that is not touched more often than the any pages written then those
will be swapped out.. with a large index such things are extremely likely.

> Oh, yeah, the other benefit to the ram disk vs. big cache_mem/big
> minimum obj size is that on shutdown the RAM disk can be flushed to a
> real disk so that we don't lose those objects (could even be done
> periodically minus the swap.state, to avoid complete lossage on an
> improper shutdown or crash). Squid's memory objects can't be flushed in
> any controlled manner.

True.

> Maybe if I feel smart one day, I'll try to
> integrate that functionality on the assumption that the Linux kernel
> will be fixed eventually. I'm guessing Squid is probably more efficient
> without the fake disk overhead of the RAM disk. ;-)

Without first fixing the "hot object cache" to actually act like a cache
using a ram disk is most likely more efficient.

Regards
Henrik
Received on Fri Nov 09 2001 - 06:19:40 MST