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 <[email protected]> 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. >
_______________________________________________ Beowulf mailing list, [email protected] sponsored by Penguin Computing To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
