Streaming replication on win32, still broken
in [PgSql]
|
From: Heikki Linnakangas on 18 Feb 2010 05:04 Magnus Hagander wrote: > O_DIRECT helps us when we're not going to read the file again, because > we don't waste cache on it. If we are, which is the case here, it > should be really bad for performance, since we actually have to do a > physical read. > > Incidentally, that should also apply to general WAL when archive_mdoe > is on. Do we optimize for that? Hmm, no we don't. We do take that into account so that we refrain from issuing posix_fadvice(DONTNEED) if archive_mode is on, but we don't disable O_DIRECT. Maybe we should.. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Fujii Masao on 18 Feb 2010 05:39 On Thu, Feb 18, 2010 at 7:04 PM, Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> wrote: > Magnus Hagander wrote: >> O_DIRECT helps us when we're not going to read the file again, because >> we don't waste cache on it. If we are, which is the case here, it >> should be really bad for performance, since we actually have to do a >> physical read. >> >> Incidentally, that should also apply to general WAL when archive_mdoe >> is on. Do we optimize for that? > > Hmm, no we don't. We do take that into account so that we refrain from > issuing posix_fadvice(DONTNEED) if archive_mode is on, but we don't > disable O_DIRECT. Maybe we should.. Since the performance of WAL write is more important than that of WAL archiving in general, that optimization might offer little benefit. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Magnus Hagander on 18 Feb 2010 06:14 2010/2/18 Fujii Masao <masao.fujii(a)gmail.com>: > On Thu, Feb 18, 2010 at 7:04 PM, Heikki Linnakangas > <heikki.linnakangas(a)enterprisedb.com> wrote: >> Magnus Hagander wrote: >>> O_DIRECT helps us when we're not going to read the file again, because >>> we don't waste cache on it. If we are, which is the case here, it >>> should be really bad for performance, since we actually have to do a >>> physical read. >>> >>> Incidentally, that should also apply to general WAL when archive_mdoe >>> is on. Do we optimize for that? >> >> Hmm, no we don't. We do take that into account so that we refrain from >> issuing posix_fadvice(DONTNEED) if archive_mode is on, but we don't >> disable O_DIRECT. Maybe we should.. > > Since the performance of WAL write is more important than that of WAL > archiving in general, that optimization might offer little benefit. Well, it's going to make the process that reads the WAL cause actual physical I/O... That'll take a chunk out of your total available I/O, which is likely to push you to the limit of your I/O capacity much quicker. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Heikki Linnakangas on 18 Feb 2010 07:46 Magnus Hagander wrote: > 2010/2/18 Fujii Masao <masao.fujii(a)gmail.com>: >> On Thu, Feb 18, 2010 at 7:04 PM, Heikki Linnakangas >> <heikki.linnakangas(a)enterprisedb.com> wrote: >>> Magnus Hagander wrote: >>>> O_DIRECT helps us when we're not going to read the file again, because >>>> we don't waste cache on it. If we are, which is the case here, it >>>> should be really bad for performance, since we actually have to do a >>>> physical read. >>>> >>>> Incidentally, that should also apply to general WAL when archive_mdoe >>>> is on. Do we optimize for that? >>> Hmm, no we don't. We do take that into account so that we refrain from >>> issuing posix_fadvice(DONTNEED) if archive_mode is on, but we don't >>> disable O_DIRECT. Maybe we should.. >> Since the performance of WAL write is more important than that of WAL >> archiving in general, that optimization might offer little benefit. > > Well, it's going to make the process that reads the WAL cause actual > physical I/O... That'll take a chunk out of your total available I/O, > which is likely to push you to the limit of your I/O capacity much > quicker. Right, doesn't seem sensible, though it would be nice to see a benchmark on that. Here's a patch to disable O_DIRECT when archiving or streaming is enabled. This is pretty hard to test, so any extra eyeballs would be nice.. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
From: Heikki Linnakangas on 19 Feb 2010 05:54 Heikki Linnakangas wrote: > Magnus Hagander wrote: >> Well, it's going to make the process that reads the WAL cause actual >> physical I/O... That'll take a chunk out of your total available I/O, >> which is likely to push you to the limit of your I/O capacity much >> quicker. > > Right, doesn't seem sensible, though it would be nice to see a benchmark > on that. > > Here's a patch to disable O_DIRECT when archiving or streaming is > enabled. This is pretty hard to test, so any extra eyeballs would be nice.. Committed. Can you check that this fixed the PANIC you saw? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: [HACKERS] OpenVMS? Next: auto_explain causes regression failures |