[ale] Disk performance

Brian Mathis brian.mathis+ale at betteradmin.com
Sun Aug 25 00:59:46 EDT 2013


On Sat, Aug 24, 2013 at 8:13 PM, Alex Carver <agcarver+ale at acarver.net>wrote:

> On 8/24/2013 18:03, Ed Cashin wrote:
>
>> On Sat, Aug 24, 2013 at 8:38 PM, Alex Carver <agcarver+ale at acarver.net>**
>> wrote:
>> ...
>>
>>  Well, looks like mostly still working although it has a memory leak
>>> somewhere.  The free memory (according to top) is slowly dropping.  It
>>> went
>>> from 380MB to 365MB in about two hours so 15MB went somewhere during that
>>> time.  Probably one of the cron jobs or apache, just don't know which
>>> yet.
>>>
>>>
>> If you haven't already, you might check whether that memory is simply
>> being
>> used to cache stuff.  Linux aggressively caches blocks from disk in pages
>> of memory, which is usually a convenience.
>>
>
> Good point, I'll look at that later and see what's up.  Although this has
> led me to investigate one of my other machines (a P2) to check its drives.
>  The drives are fine, they're just running a bit slow (20MB/s) though I'm
> not too concerned since it's a low volume mail server (and certainly better
> than the 200 KB/s I was getting on the troublesome machine).
>
>

This wouldn't explain a sudden drop in performance, but make sure you have
your partitions mounted using the "relatime" mount option.  One unfortunate
problem with Linux is that it keeps track of every time a file is accessed,
which means that every time you read a file, it causes a write back to the
disk.

Older kernels used the "noatime" option, but "relatime" is the modern
incarnation of that.  The only caveat is if you are using backup software
that relies on the access time, which I think is somewhat rare.  Using
"relatime" should solve those problems though.


❧ Brian Mathis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20130824/69189b04/attachment.html>


More information about the Ale mailing list