Re: No swap.state safe?

Yeah, I thought of that too...But more disk activity seems to make that
less than ideal, especially since for now we're not using it when Squid
comes back to life. I'll give it a try to see if it has a notable impact.

Hmmm...So if I have two ramdisks I can't put their respective
swap.states onto different disks? No big deal. I'm going to switch to
tmpfs for the second run anyway, which will (I think) allow me to only
use one ramdisk and still get 768MB of space--the standard RAM disk
seems to max at 512MB so I'm trying out two 384s.

For those that might be interested, I just completed a prelim Polymix-4
at 135 reqs/sec. So our first run will be at least that fast. Though,
that load wasn't even pushing the box very hard. I'm going to increase
it to 145 and do about 8 hours run before rushing it out to the Saturday
drop off in the hopes that Alex will let it slide on having a full
length run (actually I have to confess that the first run was also
shortened some because I was panicked over the crash last night and was
afraid I'd wake this morning to a crashed machine and no time to finish
another run before having to ship). I expect 150 is the limit of this
box with this workload...though the 1GHz processor I install before I
start the official tests might push it a little bit higher (but not
much--the disks get hit heavily by the time we're at 150).

Since Polymix-4 is new to me, I was quite impressed with how realistic
the workload has gotten (and overwhelmed by how difficult the benches
are to set up--I used to be able to set up a complete environment in
about 15 minutes, this one took me about 18 hours--the reasons may
become apparent as I describe the workload). First, the network
topology has changed. pm-4 enforces a routed network to eliminate arp
entries on the cache(s) and the bench machines. I banged my head on the
shell script that sets this up for about an hour before giving up and
doing it manually (the shell script works on FreeBSD, but didn't
actually lead to a working routed configuration...it didn't run at all
under Linux). The workload also uses DNS for the first time. Pretty
cool. And this part was extremely easy to configure. The script worked
perfectly the first time (on FreeBSD, I wasn't brave enough to try it on
Linux, as BIND scares me enough already). I banged into the routed
network issue again when I finally got around to running the benchmark,
as the polygraph processes enforced talking to the DNS server via it's
own IPs, and the FreeBSD machine where the DNS server was living still
didn't seem to want to play entirely nice (chalk it up to my ignorance
of FreeBSD). Anyway, it's pretty cool all around. More object types,
pretty realistic traffic patterns. It actually looks a lot like our
caches in the field look under load (and it's not nearly as much a disk
benchmark as Datacomm-1 and Polymix-1|2 were--that's probably a good
thing for us, and a bad thing for any proprietary vendors who might have
optimized a 'fast-path' that would never be hit in the real world (like
no DNS lookups, limited protocol support, etc.).

Henrik Nordstrom wrote:

> Or move them to a bigger place.. see the cache_swap_log directive.
>
> Regards
> Henrik
>
>
> Joe Cooper wrote:
>
>>I haven't tried it yet, and I'm in the middle of the Polymix-4 run so
>>can't test it, but while digging through the logs to see the "reasons
>>we've crashed today", I realized a problem with the ramdisk--swap.state
>>grows faster than I normally rotate (quite a lot faster during a fill)
>>leading it to overrun the disk and crash Squid. The good news is that
>>every crash over the past week has a good explanation, and it was never
>>due to Squid bugs, unless you count fragility in the face of full disks
>>a bug.
>>
>>Is it safe to route it to /dev/null or even hack Squid to disable it
>>entirely? As far as I know it's only used on restarts to speed the
>>building of the in-memory cache state...so can I kill it or should I
>>just remove it hourly and squid -k rotate?
>>
>>Thanks!
>>--
>>Joe Cooper <joe@swelltech.com>
>>http://www.swelltech.com
>>Web Caching Appliances and Support
>>
>
>

-- 
Joe Cooper <joe@swelltech.com>
http://www.swelltech.com
Web Caching Appliances and Support