On 3 February 2010 12:52, Akemi Yagi amyagi@gmail.com wrote:

On Wed, Feb 3, 2010 at 4:38 AM, James Hogarth james.hogarth@gmail.com wrote:

...

RHEL doesn't have a reltime enabled kernel so centos doesn't either by default. I believe that there is a kernel in plus that is reltime enabled but due to potentially breaking ABI compatibility with RHEL I don't make use of it.

As you can see in my earlier note (and the referenced bug tracker) that was posted almost at the same time as yours, when I attempted to add a relatime patch to the centosplus kernel, it did break the kABI. Therefore it was not applied (there was a workaround however).

At any rate, the point I wanted to make is that the centosplus kernel must remain (and has been) kABI-compatible with the distro/RHEL kernel.

Akemi _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Ah thanks Akemi - I thought the plus repository existed as something that might break ABI compatibility - I'm pleasantly surprised to find I'm wrong if not the case :)

And I saw your post just after I made mine (I must have been typing the same time as you) and you definitely covered the material better.

James

On 2/3/2010 2:45 PM, nate wrote:

Rajagopal Swaminathan wrote:

...

But in a production db server, which is backed up by HP DP, is it advisable to mount with noatime?

noatime typically helps when dealing with lots of files, most DB servers have a small number of files that are large in size, so noatime is likely not to provide any noticeable improvement I think.

On the other hand you are unlikely to miss it on most filesystems, especially any that you back up with a file-oriented mechanism like tar or rsync. The only time it matters is for rare apps like a mail client that might try to notify you when your mailbox has been written more recently than the last read.

Rob Kampen wrote:

I do not agree - every read of the db will update the filesystem with noatime missing, thus specifying noatime does give performance improvements - the size of the files does not matter as much - rather the number of reads vs writes.

Interesting, didn't think about that aspect, I dug around and at least for MySQL and Postgresql noatime doesn't appear to provide any noticeable benefit(it may be a measurable one in some cases)

http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimizati...

http://www.ffnn.nl/pages/articles/linux/server-wide-performance-benchmarking...

If your doing a ton of reads and only have a few files, it's likely there isn't going to be many atime updates as the file is kept open for an extended period of time(e.g. scanning a table with 100k rows).

For DB performance there's a lot more useful areas to spend time tuning. As DBAs often say you can get 10% more performance tuning the OS and getting better hardware, and you can get 1000% better performance by tuning the queries and data structures, or something like that :)

nate