[Beowulf] LSI Megaraid stalls system on very high IO?

[John Hearns]

Mark, you are of course correct.
Flush often and flush early!

As an aside, working with desktop systems with larger amounts of memory I
would adjust the 'swappiness' tunable
and also the min_free_kbytes.
Min_free_kbytes in Linux  is by default set very low for modern high memory
systems.
I had systems with 128Gbytes of RAM which would lock up in a similar
fashion as you describe. Setting higher min_free_kbytes helped with the
'system paging itself into the deck' type of behaviour.
See:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/s-memory-tunables.html






On 2 August 2014 16:14, Mark Hahn <hahn at mcmaster.ca> wrote:

> This system might have a decent amount of memory - but are the sysctl
>> tunings for the dirty buffer sizes set small or something?
>>
>
> actually, my experience is the opposite: if sysctls permit large
> accumulation of dirty buffers, a system with big memory and slow
> write speeds will feel unpleasantly choppy.  basically, I think you should
> set vm.dirty_ratio less than the amount your storage system can commit to
> disk in O(few seconds).  that's the synchronous form of writeback - I also
> like to make the async form more active as well.
> (lower vm.dirty_background_ratio and vm.dirty_writeback_centisecs=100).
>
> of course, this is only relevant to big-memory-slow-disk machines.
> (but consider a hypothetical 1TB box with a single disk and default
> settings: if it dirties 100G, the sync writeback will kick in and saturate
> the disk for up to 10 minutes...)
>
> regards, mark hahn.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.beowulf.org/pipermail/beowulf/attachments/20140804/4fdf93e6/attachment.html>