Re: file system and raid performance
От
Mark Wong
Тема
Re: file system and raid performance
Дата
Msg-id
70c01d1d0808081413w5438a27el6b3f2e934f4f5c85@mail.gmail.com
Ответ на
Re: file system and raid performance (Mark Mielke)
Список
Дерево обсуждения
file system and raid performance "Mark Wong" <markwkm@gmail.com>
Re: file system and raid performance "Fernando Ike" <fike@midstorm.org>
Re: file system and raid performance david@lang.hm
Re: file system and raid performance "Gregory S. Youngblood" <greg@tcscs.com>
Re: file system and raid performance "Mark Wong" <markwkm@gmail.com>
Re: file system and raid performance Mark Kirkwood <markir@paradise.net.nz>
Re: file system and raid performance "Gregory S. Youngblood" <greg@tcscs.com>
Re: file system and raid performance Mark Kirkwood <markir@paradise.net.nz>
Re: file system and raid performance Mark Kirkwood <markir@paradise.net.nz>
Re: file system and raid performance Mario Weilguni <mweilguni@sime.com>
Re: file system and raid performance "Mark Wong" <markwkm@gmail.com>
Re: file system and raid performance "Gregory S. Youngblood" <greg@tcscs.com>
Re: file system and raid performance "Mark Wong" <markwkm@gmail.com>
Re: file system and raid performance "Andrej Ricnik-Bay" <andrej.groups@gmail.com>
Re: file system and raid performance "Scott Marlowe" <scott.marlowe@gmail.com>
Re: file system and raid performance "Andrej Ricnik-Bay" <andrej.groups@gmail.com>
Re: file system and raid performance Mark Mielke <mark@mark.mielke.cc>
Re: file system and raid performance "Mark Wong" <markwkm@gmail.com>
Re: file system and raid performance "Mark Wong" <markwkm@gmail.com>
Re: file system and raid performance "Mark Wong" <markwkm@gmail.com>
Re: file system and raid performance Greg Smith <gsmith@gregsmith.com>
Re: file system and raid performance "Scott Marlowe" <scott.marlowe@gmail.com>
Re: file system and raid performance "Mark Wong" <markwkm@gmail.com>
Re: file system and raid performance Bruce Momjian <bruce@momjian.us>
Re: file system and raid performance "Mark Wong" <markwkm@gmail.com>
Re: file system and raid performance "Mark Wong" <markwkm@gmail.com>
Re: file system and raid performance Greg Smith <gsmith@gregsmith.com>
Re: file system and raid performance Mark Mielke <mark@mark.mielke.cc>
Re: file system and raid performance Bruce Momjian <bruce@momjian.us>
Re: file system and raid performance "M. Edward (Ed) Borasky" <znmeb@cesmail.net>
Re: file system and raid performance Jean-David Beyer <jeandavid8@verizon.net>
Re: file system and raid performance "Scott Marlowe" <scott.marlowe@gmail.com>
Re: file system and raid performance "M. Edward (Ed) Borasky" <znmeb@cesmail.net>
Re: file system and raid performance david@lang.hm
On Thu, Aug 7, 2008 at 3:08 PM, Mark Mielke wrote: > Andrej Ricnik-Bay wrote: > > 2008/8/8 Scott Marlowe : > > > noatime turns off the atime write behaviour. Or did you already know > that and I missed some weird post where noatime somehow managed to > slow down performance? > > > Scott, I'm quite aware of what noatime does ... you didn't miss a post, but > if you look at Mark's graphs on > http://wiki.postgresql.org/wiki/HP_ProLiant_DL380_G5_Tuning_Guide > they pretty much all indicate that (unless I completely misinterpret the > meaning and purpose of the labels), independent of the file-system, > using noatime slows read/writes down (on average) > > That doesn't make sense - if noatime slows things down, then the analysis is > probably wrong. > > Now, modern Linux distributions default to "relatime" - which will only > update access time if the access time is currently less than the update time > or something like this. The effect is that modern Linux distributions do not > benefit from "noatime" as much as they have in the past. In this case, > "noatime" vs default would probably be measuring % noise. It appears that the default mount option on this system is "atime". Not specifying any options, "relatime" or "noatime", results in neither being shown in /proc/mounts. I'm assuming if the default behavior was to use "relatime" that it would be shown in /proc/mounts. Regards, Mark
В списке pgsql-performance по дате отправления