Stan Hoeppner wrote: > Bob Proulx wrote: > > Talking about tuning the Raspbery Pi folks set vm.swappiness=1 which I > > disagree with. I suggest using the Linux upstream default of > > vm.swappiness=60 or even higher. Proponents of disabling program swap > > by setting it low say that they never want to swap. I have the > > opposite viewpoint. The point is to use the existing ram most > > effectively. If that means using ram for file system buffer cache > > instead of parts of programs that aren't ever accessed again then > > swapping out unused program space is better than hogging ram with it. > > The OP will be using a browser. Browser cache writes, index updates, > etc, will be far in excess of swap writes. If he uses Thunderbird > (IceDove) with GLODA and offline caching enabled, that will produce even > more writes. > > Worrying about swap write flash wear is a non issue given the write load > generated by these other desktop apps. I agree completely. Often people optimize the wrong things. And optimizing without measuring the effects before and after can often lead to the wrong tuning. Premature optimization is the root of all evil -- DonaldKnuth ================ I have one of my SD card ARM systems handling a lot of email. It would be too convoluted to explain why. I just do. I figured it would be a good stress test. It is a front end for passing emails to spamassassin on other systems. Using about 2.5 watts of total power for the ARM based front end! It has been processing about 12,000 email messages a week according to the logs. I am using Postfix in a mostly normal configuration. Every mail message will produce a file in /var/spool and various logging. I found that it was beneficial for interactive performance to increase vm.dirty_ratio from 20% to a larger value. I went with 60%. That probably isn't a perfect number for me but it works fine and so I kept it. The problem had been that it was spending a lot of time writing out dirty pages. It only has 485M of available ram and 20% isn't much. It would appear to hit the dirty_ratio limit and then hold off all writes until it could catch up writing out dirty pages. It still did everything it needed to do but interactively there were frequent pauses before responding. By increasing vm.dirty_ratio so that more pages could be dirty it would allow the email files to be processed and inevitably deleted at which point there is no longer a need to write them out. In my system load case by increasing vm.dirty_ratio I could reduce the amount of total actual I/O being done to the SD card significantly. I worry that I didn't have a good objective way to measure this effect. And therefore I might have tuned it incorrectly. But it was a "light switch" for responsiveness and feels much better. ================ Another thing that I did was to install 'eatmydata' in order to use the LD_PRELOAD library to disable fsync(). A lot of applications have added fsync() calls everywhere to disable the file system buffer cache. I wanted to minimize writes to the SD card. Applications that use fsync() are forcing writes through the cache to storage. This does two bad things. Defeating the cache is many times slower. Defeating the cache causes a lot of I/O for flash storage. Both things are undesirable with slower flash storage such as SD cards. I think disabling fsync() had more positive performance effect than tweaking vm.dirty_ratio. Both had strong positive effects for my system load case. Other cases will be uniquely different. YMMV. Bob
Attachment:
signature.asc
Description: Digital signature