Thomas Hurst wrote:
* Kris Kennaway ([EMAIL PROTECTED]) wrote:
I don't understand your test procedure, can you elaborate?
The spikes from last night are from:
(/sbin/dump -$level -LuaC128 -f - $fs | /usr/bin/tee ${target} |
/sbin/sha1 > ${target}.sha1)
Followed by:
nice -n 19 /home/freaky/
* Kris Kennaway ([EMAIL PROTECTED]) wrote:
> I don't understand your test procedure, can you elaborate?
The spikes from last night are from:
(/sbin/dump -$level -LuaC128 -f - $fs | /usr/bin/tee ${target} |
/sbin/sha1 > ${target}.sha1)
Followed by:
nice -n 19 /home/freaky/bin/par2 c -t+ -r5 -m2
Thomas Hurst wrote:
* Thomas Hurst ([EMAIL PROTECTED]) wrote:
* Kris Kennaway ([EMAIL PROTECTED]) wrote:
Excellent. I've been seeing this behavior for a long time, mostly on
backup runs (RAID-1 amr SATA -> 1 disk Marvell ata). It's pretty odd
seeing a system with 8G of memory, 60% of which
* Thomas Hurst ([EMAIL PROTECTED]) wrote:
> * Kris Kennaway ([EMAIL PROTECTED]) wrote:
>
> >> Excellent. I've been seeing this behavior for a long time, mostly on
> >> backup runs (RAID-1 amr SATA -> 1 disk Marvell ata). It's pretty odd
> >> seeing a system with 8G of memory, 60% of which is ju
On Sat, Jan 12, 2008 at 12:05:38AM -0500, John Baldwin wrote:
On Friday 11 January 2008 10:31:47 pm Peter Jeremy wrote:
> On Fri, Jan 11, 2008 at 06:44:20PM +0100, Kris Kennaway wrote:
> >Ian West wrote:
> >> dd if=/dev/zero bs=32768 of=junkfile count=10 seems to do it quite
> >> rel
* Kris Kennaway ([EMAIL PROTECTED]) wrote:
>> Excellent. I've been seeing this behavior for a long time, mostly on
>> backup runs (RAID-1 amr SATA -> 1 disk Marvell ata). It's pretty odd
>> seeing a system with 8G of memory, 60% of which is just cache, swap
>> out half a dozen things for no appa
Thomas Hurst wrote:
* John Baldwin ([EMAIL PROTECTED]) wrote:
We have noticed an issue at work but only on faster controllers (e.g.
certain mfi(4) drive configurations) when doing I/O to a single file
like the dd command mentioned causes the buffer cache to fill up. The
problem being that we c
* John Baldwin ([EMAIL PROTECTED]) wrote:
> We have noticed an issue at work but only on faster controllers (e.g.
> certain mfi(4) drive configurations) when doing I/O to a single file
> like the dd command mentioned causes the buffer cache to fill up. The
> problem being that we can't lock the v
On Friday 11 January 2008 10:31:47 pm Peter Jeremy wrote:
> On Fri, Jan 11, 2008 at 06:44:20PM +0100, Kris Kennaway wrote:
> >Ian West wrote:
> >> dd if=/dev/zero bs=32768 of=junkfile count=10 seems to do it quite
> >> reliably on all the boxes I have tested ?
> >
> >I am unable to reproduce th
On Fri, Jan 11, 2008 at 06:44:20PM +0100, Kris Kennaway wrote:
>Ian West wrote:
>> dd if=/dev/zero bs=32768 of=junkfile count=10 seems to do it quite
>> reliably on all the boxes I have tested ?
>
>I am unable to reproduce this on 7.0.
I can't reproduce it on 6.3-PRERELEASE/amd64 with 1GB RAM.
Ian West wrote:
Hello, I have noticed while benchmarking a system with a fair bit of ram
(3G usable of 4G installed) that when using a very large file (3G
upwards) in a simple benchmark it will cause the system to swap, even
though the actual process does not show in top to be using a lot of
memo
11 matches
Mail list logo
