Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Aug 2009 23:03:00 -0400
From:      grarpamp <grarpamp@gmail.com>
To:        freebsd-performance@freebsd.org
Subject:   RELENG_7 heavy disk = system crawls
Message-ID:  <d2e731a10908102003w37eff49axc43c4facd3a45cc4@mail.gmail.com>

next in thread | raw e-mail | index | archive | help
> nice only affects userland

Well, you can set {id,rt}prio and nice on kernel processes. Then
look at top to see the nice column change. Have no idea what effect
it has nor what the non '-' chars on those procs in that column
mean.

> Do you *need* geli+zfs?

Encryption = required.
ZFS... well I like the checksum all the way back to the uberblock
feature, raidz2, ditto blocks, compression and the admin model.
geom offers encryption, single block checksum authority and raid1/3.

> hardware crypto accellerators

The soekris ones work and are cheap. I thougt I saw posts that show
openssl -speed on today's fast cpu's being faster than the accel
cards. Disk crypto is symmetric, not initial pki session setup.

And with ~40MB/s of encryption, while building world no less, cpu
may not be the issue. So long as I'm not hitting those geli+zfs
disks, things are smooth. I want to try the system with geli+ufs2
sometime.

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128 cbc      36555.26k    38074.95k    38999.93k    39258.38k    39176.80k

> throw lots of cpu (e.g. phenom2 x4) at it

That would only help it get done busying out the system sooner, not
balance things out while actively under load. Which as a file server,
it always is.

Well, ok, it will help after the system is able to do spindle ->
geli -> fs -> process at the max sustained read/write speed of the
spindles. Which is about 56MiB/sec reading in this case. Which is
over 10x faster than I'm getting now. Which means I'd need maybe
10 x 1.8GHz worth of cpu before I have any free cycles to devote
to the user interface :)

Maybe I'm just clueless this month and the list is too busy to beat
me about the head with it.

> The nForce pata controller doesn't list an irq, seems odd?
> device 6.0 on pci0

This one doesn't either:
atapci1: <Intel ICH4 UDMA100 controller> port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 31.1 on
pci0

boot -v and it appears in the irq routing stuff around that line.
Then vmstat -i and systat -vmstat 1 also give some clues when device
is dd'd. Onboard PATA is always irq14/15 as I've seen.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d2e731a10908102003w37eff49axc43c4facd3a45cc4>