SCIENTIFIC-LINUX-USERS Archives

July 2014

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Patrick J. LoPresti" <[log in to unmask]>
Reply To:
Patrick J. LoPresti
Date:
Tue, 1 Jul 2014 13:19:10 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (24 lines)
On Tue, Jul 1, 2014 at 11:29 AM, Andras Horvath <[log in to unmask]> wrote:
>
> I restarted copying again, and in a minute the CPU hung again with 100% I/O wait. The "iotop" output shows absolutely nothing, as if there was no load on the disks at all. Interrupt and context switch is around 20-50, so almost nothing (dstat output). Disk operation is zero. Load is at 5.01. The rsync processes that I'm using for the copy cannot be killed or force killed.

How much RAM does your system have? What does "/sbin/sysctl -a | grep
vm.dirty" say?

On machines with lots of RAM, I have seen disk subsystems act a bit
squirrelly when Linux decides to buffer (say) a few gigabytes of
writes. The traditional "vm.dirty_background_ratio" and
"vm.dirty_ratio" settings are a percentage of RAM, which gives
ludicrous behavior on modern big-memory boxes.

Something like this is more sane:

  sysctl -w vm.dirty_background_bytes=67108864
  sysctl -w vm.dirty_background_bytes=134217728

This is not terribly likely to help, but it is worth a shot. If the
problem really is the disk spinning down, at least this will be more
likely to keep it busy...

 - Pat

ATOM RSS1 RSS2