Re: [GENERAL] server hardware recommendations (the archives aredead)
От | John Huttley |
---|---|
Тема | Re: [GENERAL] server hardware recommendations (the archives aredead) |
Дата | |
Msg-id | 002d01bf4771$78988040$1401a8c0@MWK.co.nz обсуждение исходный текст |
Ответ на | Re: [GENERAL] server hardware recommendations (the archives aredead) (The Hermit Hacker <scrappy@hub.org>) |
Список | pgsql-general |
----- Original Message ----- From: The Hermit Hacker <scrappy@hub.org> To: Bruce Momjian <pgman@candle.pha.pa.us> Cc: J. Roeleveld <j.roeleveld@softhome.net>; pgsql-list <pgsql-general@hub.org> Sent: Thursday, 16 December 1999 15:10 Subject: Re: [GENERAL] server hardware recommendations (the archives aredead) > On Wed, 15 Dec 1999, Bruce Momjian wrote: > > > [Charset iso-8859-1 unsupported, filtering to ASCII...] > > > > What filesystem? I know (thank god) very little about Linux, but > > > > there have been comments here by some Linux folks (Thomas, wasn't it > > > > you?) that indicated that ext2fs sucks for this? Are you running with > > > > fsync() on or off? > > > > > > What is the problem with ext2fs? Is it just performance? or is there a > > > serious chance for me losing data? > > > > The only comment made was something I said about raw devices on Linux. > > Didn't Thomas make some comment,at one point, about not using PostgreSQL > over ext2fs...I know he does use Linux, I just figured he was using a > different fs then ext2s... > Ok, to stick my oar in this. ext2 is very fast and efficient. but it does not have journalling and is not extent based. Therefore it is not 'modern'. Irrelevant. Problem with postgresql and linux relate to the fsync() system call. On 2.2 and earlier this is surprisingly inefficient. This is related to the structuring of the buffer-cache and VFS layers in linux. This was rectified in 2.3.10 and later, with potential order-of-magnitude increases in performance, particularly with SMP systems. Raw devices have been a contentious issue in linux. Linus's position has been that the OS io should be so perfect that no application layer io system can hope to surpass it. Any situation otherwise is a flaw in linux. It seems that this position is justified. Generally though, switching off fsync() when starting postmaster solves most performance problems. If you wish to use raw io to get beyond the 32bit file limit of intel linux.... well maybe you should be using 64bit linux. Sparc, alpha, MIPS. If you want a radical filesystem, checkout the reisferfs. I'm sure we would all be interested to hear the results. regards John
В списке pgsql-general по дате отправления: