I have been reading this article on KernelTrap, describing a debate amongst the kernel devs regarding atime. http://kerneltrap.org/node/14148
This made me wonder, are there any dependencies in Scalix that requires atime to be correct? I know Scalix is very much IO-bound (especially reads), so I think this could have an impact on large installations.
I am always loath to move away from the distro defaults (in the RH case keeping atime enabled), but if there's no risk of things not working correctly I can easily enable this on some installations.
Does Scalix use atime anywhere?
Moderators: ScalixSupport, admin
-
Valerion
- Scalix Star
- Posts: 2730
- Joined: Thu Feb 26, 2004 7:40 am
- Location: Johannesburg, South Africa
- Contact:
-
ianare
- Posts: 61
- Joined: Tue Sep 19, 2006 1:13 pm
-
rogueind
-
jch
- Scalix
- Posts: 202
- Joined: Thu Mar 25, 2004 10:25 am
I've just searched the code for uses of atime in the code. There's one place where omscan carefully preserves it (I think so that orphans don't appear to be accessed unnecessarily) but that's it.
The only thing that might cause problems with access time is scripts that are looking for files to delete in ~/tmp and ~/temp. I did wonder if omscan's normal temporary file clean up was using the atime for that, but it appears not. Nothing in our server sources uses find's -atime though, at least nothing that grep can find.
I read the kerneltrap article last night. The "relatime" patch looks interesting, but what I found much more interesting was the discussion about fsync(2). We like fsync, we like it a lot, we call it all over the place
Actually, that's only half true. We do use fsync(2) a lot, because we commit changes to the disk a lot. It would be nice to be able to rely on the ext3 journal to do that for us, but we can't. It appears that fsync(2), however, is a little inefficient because it flushes all pending changes for the file system. This might be hurting performance quite a bit -- it's hard to be definitive about it because most changes to the message store are committed with fsync(2).
What the behaviour of fsync(2) does really underline though is that you are definitely better off having ~/tmp and ~/temp are separate file systems and you can have the "noatime,nodiratime,data=writeback" options on those file systems because we don't care about the contents after a crash.
It would be nice to hear from someone who has mounted their message store noatime,nodiratime and measured the performance difference.
Meanwhile, on my laptop, I've just done a fresh svn checkout of the source into a noatime,nodiratime file system to see how much difference it makes. I'll let you know in about 20 minutes.
jch
The only thing that might cause problems with access time is scripts that are looking for files to delete in ~/tmp and ~/temp. I did wonder if omscan's normal temporary file clean up was using the atime for that, but it appears not. Nothing in our server sources uses find's -atime though, at least nothing that grep can find.
I read the kerneltrap article last night. The "relatime" patch looks interesting, but what I found much more interesting was the discussion about fsync(2). We like fsync, we like it a lot, we call it all over the place
Actually, that's only half true. We do use fsync(2) a lot, because we commit changes to the disk a lot. It would be nice to be able to rely on the ext3 journal to do that for us, but we can't. It appears that fsync(2), however, is a little inefficient because it flushes all pending changes for the file system. This might be hurting performance quite a bit -- it's hard to be definitive about it because most changes to the message store are committed with fsync(2).
What the behaviour of fsync(2) does really underline though is that you are definitely better off having ~/tmp and ~/temp are separate file systems and you can have the "noatime,nodiratime,data=writeback" options on those file systems because we don't care about the contents after a crash.
It would be nice to hear from someone who has mounted their message store noatime,nodiratime and measured the performance difference.
Meanwhile, on my laptop, I've just done a fresh svn checkout of the source into a noatime,nodiratime file system to see how much difference it makes. I'll let you know in about 20 minutes.
jch
-
jch
- Scalix
- Posts: 202
- Joined: Thu Mar 25, 2004 10:25 am
I'm not really surprised: the compilation time was about the same as normal, it would probably improve if I mounted my root file system noatime,nodiratime to avoid writing the atime on all those files in /usr/include.
While the compilation was running I was thinking about how much it would benefit the performance of the mail server. On a reasonably configured server, disk I/O is split pretty evenly between read and write: the number of file system reads compared to file system writes is enormous, but the cache takes care of most of the reads. Most of the writes are very small (there are places where we just write two ior three bytes). The number of file system reads though, does suggest that the number of times that the atime is written is going to make a difference to the overall I/O burden. It may well drop the number of writes by an appreciable amount, especially given the behaviour of fsync(2).
We're not in a position to do comparative performance analysis right now, but I really would love to hear from someone who has tried it, even if to say "seems snappier" or "no discernable change".
Of course, all I've done is grep for uses of the atime, it's possible that I've missed something important, so go carefully.
jch
While the compilation was running I was thinking about how much it would benefit the performance of the mail server. On a reasonably configured server, disk I/O is split pretty evenly between read and write: the number of file system reads compared to file system writes is enormous, but the cache takes care of most of the reads. Most of the writes are very small (there are places where we just write two ior three bytes). The number of file system reads though, does suggest that the number of times that the atime is written is going to make a difference to the overall I/O burden. It may well drop the number of writes by an appreciable amount, especially given the behaviour of fsync(2).
We're not in a position to do comparative performance analysis right now, but I really would love to hear from someone who has tried it, even if to say "seems snappier" or "no discernable change".
Of course, all I've done is grep for uses of the atime, it's possible that I've missed something important, so go carefully.
jch
-
stephan.klein
- Posts: 68
- Joined: Thu Feb 22, 2007 1:10 pm
- Location: Germany
-
florian
- Scalix
- Posts: 3852
- Joined: Fri Dec 24, 2004 8:16 am
- Location: Frankfurt, Germany
- Contact:
Who is online
Users browsing this forum: Google [Bot] and 2 guests