Dear All,
Been a while since I worked on this and I thought I'd send out an update. I
found out I had two related issues. Seemingly random hangs that seem to have
their root in disk I/O and the other is that network connections are not being
served quickly enough because of this.
For the
On 5/29/2012 12:26 PM, Kees Jan Koster wrote:
I seem to have a problem where really heavy disk I/O is drowning my machine.
Assuming you're using the default scheduler (SCHED_ULE), try switching
to the 4BSD scheduler in your kernel config file and see if that helps.
Doug
--
This
On Tue, May 29, 2012 at 12:26 PM, Kees Jan Koster kjkos...@gmail.com wrote:
I seem to have a problem where really heavy disk I/O is drowning my machine.
I see hangs in the shell where I am logged on using ssh. Network connections
get dropped for no apparent reason and some HTTP requests are
On Tue, May 29, 2012 at 12:34 PM, Freddie Cash fjwc...@gmail.com wrote:
On Tue, May 29, 2012 at 12:26 PM, Kees Jan Koster kjkos...@gmail.com wrote:
I seem to have a problem where really heavy disk I/O is drowning my machine.
I see hangs in the shell where I am logged on using ssh. Network
On Tue, May 29, 2012 at 09:26:32PM +0200, Kees Jan Koster wrote:
Dear All,
I seem to have a problem where really heavy disk I/O is drowning my machine.
I see hangs in the shell where I am logged on using ssh. Network connections
get dropped for no apparent reason and some HTTP requests are
Dear Freddie,
You may want to play around with gshed, the GEOM Scheduler.
Matt Dillon did a bunch of tests comparing FreeBSD+UFS to
DragonflyBSD+HAMMER and found that FreeBSD starves read threads in
order to satisfy write threads (or the other way around?). But,
adding gsched into the mix
Dear Doug,
I seem to have a problem where really heavy disk I/O is drowning my machine.
Assuming you're using the default scheduler (SCHED_ULE), try switching
to the 4BSD scheduler in your kernel config file and see if that helps.
I will, thanks for the suggestion.
--
Kees Jan
Dear Gary,
# camcontrol devlist
WDC WD740ADFD-00NLR1 20.07P20at scbus1 target 0 lun 0 (pass0,ada0)
WDC WD740GD-00FLC0 33.08F33 at scbus2 target 0 lun 0 (pass1,ada1)
WDC WD740GD-00FLC0 33.08F33 at scbus3 target 0 lun 0 (pass2,ada2)
OCZ SUMMIT VBM1801Q at scbus4
Dear Freddie,
You may want to play around with gshed, the GEOM Scheduler.
Matt Dillon did a bunch of tests comparing FreeBSD+UFS to
DragonflyBSD+HAMMER and found that FreeBSD starves read threads in
order to satisfy write threads (or the other way around?). But,
adding gsched into the mix
On Tue, May 29, 2012 at 2:12 PM, Kees Jan Koster kjkos...@gmail.com wrote:
You may want to play around with gshed, the GEOM Scheduler.
Matt Dillon did a bunch of tests comparing FreeBSD+UFS to
DragonflyBSD+HAMMER and found that FreeBSD starves read threads in
order to satisfy write threads
Dear Freddie,
Granted, I haven't played with gsched yet (most of our high-I/O
systems are ZFS), so there may be a way to use it across-GEOMs.
From my previous experiments ZFS suffers the same fate when there is heavy
write activity. Reads just don't get served in time.
How do you deal with
On Tue, May 29, 2012 at 2:30 PM, Kees Jan Koster kjkos...@gmail.com wrote:
Dear Freddie,
Granted, I haven't played with gsched yet (most of our high-I/O
systems are ZFS), so there may be a way to use it across-GEOMs.
From my previous experiments ZFS suffers the same fate when there is heavy
On Tue, May 29, 2012 at 10:59:58PM +0200, Kees Jan Koster wrote:
Dear Gary,
# camcontrol devlist
WDC WD740ADFD-00NLR1 20.07P20at scbus1 target 0 lun 0 (pass0,ada0)
WDC WD740GD-00FLC0 33.08F33 at scbus2 target 0 lun 0 (pass1,ada1)
WDC WD740GD-00FLC0 33.08F33 at scbus3
13 matches
Mail list logo
