Обсуждение: Disable WAL completely - Performance and Persistency research
Hi All,
As part of my masters at TAU, I'm currently conducting some research regarding new persistent memory technology.
I'm using PG for this research and would like to better understand some of the performance bottlenecks.
For this reason I'm trying to disable the WAL completely, using some hacks on the source code and compiling my own version.
So what I'm actually looking for, is some guidance about a simple way to:
1. Disable the WAL by not writing anything to the xlog directory. I don't care about recovery/fault tolerance or PITR/ replication etc at the moment.
I'm aware that the WAL and checkpoint are bind in many ways and are crucial for PG core features.
I tried changing the status of all tables to "unlogged" tables by changing RelationNeedsWAL MACRO, as well as "needs_wal" parameter at storage.c.
But, got no performance benefit, so I guess this was the wrong place to change.
2. Cancel the locking around WAL files - I don't care about corrupted files at the moment, I just want to see what is the maximum performance benefit that I can get without lock contention.
Any guidance on how to do so would be appreciated :)
Kind regards,
Netanel
As part of my masters at TAU, I'm currently conducting some research regarding new persistent memory technology.
I'm using PG for this research and would like to better understand some of the performance bottlenecks.
For this reason I'm trying to disable the WAL completely, using some hacks on the source code and compiling my own version.
So what I'm actually looking for, is some guidance about a simple way to:
1. Disable the WAL by not writing anything to the xlog directory. I don't care about recovery/fault tolerance or PITR/ replication etc at the moment.
I'm aware that the WAL and checkpoint are bind in many ways and are crucial for PG core features.
I tried changing the status of all tables to "unlogged" tables by changing RelationNeedsWAL MACRO, as well as "needs_wal" parameter at storage.c.
But, got no performance benefit, so I guess this was the wrong place to change.
2. Cancel the locking around WAL files - I don't care about corrupted files at the moment, I just want to see what is the maximum performance benefit that I can get without lock contention.
Any guidance on how to do so would be appreciated :)
Kind regards,
Netanel
On Thu, Jul 7, 2016 at 5:01 PM, Netanel Katzburg <netanel10k@gmail.com> wrote: > 1. Disable the WAL by not writing anything to the xlog directory. I don't > care about recovery/fault tolerance or PITR/ replication etc at the moment. > I'm aware that the WAL and checkpoint are bind in many ways and are crucial > for PG core features. > Any guidance on how to do so would be appreciated :) WAL insertion routines are in xloginsert.c. Did you try to play with those? -- Michael
Hi Michael,
Sorry for the delay,
The answer is yes,
I tried 2 things so far:
1. As I understand:
is the primary insert function in xloginsert.c.XLogRecPtrXLogInsert(RmgrId rmid, uint8 info)
I tried commenting the following line at this function, so I can return a phony pointer every time the function is called, just as in bootstrap mode.
if (IsBootstrapProcessingMode() && rmid != RM_XLOG_ID)
2. At xlog.c, CopyXLogRecordToWAL(int write_len, bool isLogSwitch, XLogRecData *rdata,
XLogRecPtr StartPos, XLogRecPtr EndPos), Commenting the memcpy syscall:
...
memcpy(currpos, rdata_data, rdata_len);
...
BUT, both options are not good, as they are stopping me from even running initdb.
Maybe someone have a lead regarding changes to be done at xlog.c:
XLogInsertRecord(XLogRecData *rdata, XLogRecPtr fpw_lsn)
Any other lead regarding xloginsert.c is welcomed as well.
Regards,
Netanel
On Thu, Jul 7, 2016 at 4:17 PM, Michael Paquier <michael.paquier@gmail.com> wrote:
On Thu, Jul 7, 2016 at 5:01 PM, Netanel Katzburg <netanel10k@gmail.com> wrote:
> 1. Disable the WAL by not writing anything to the xlog directory. I don't
> care about recovery/fault tolerance or PITR/ replication etc at the moment.
> I'm aware that the WAL and checkpoint are bind in many ways and are crucial
> for PG core features.
> Any guidance on how to do so would be appreciated :)
WAL insertion routines are in xloginsert.c. Did you try to play with those?
--
Michael
On 10 July 2016 at 18:27, Netanel Katzburg <netanel10k@gmail.com> wrote:
BUT, both options are not good, as they are stopping me from even running initdb.
The easiest path for testing will be to use an unpatched PostgreSQL to `initdb` and create a new database. Then start up a patched one that simply skips WAL writing against an already-`initdb`'d data directory.
You probably won't be able to safely restart PostgreSQL, but all you're doing is performance analsys so one-shot operation on a throw-away data directory is probably fine.
On 11 July 2016 at 19:14, Netanel Katzburg <netanel10k@gmail.com> wrote:
Hi,You were right, the method you described worked well. Thanks you!
But so far, could not get any noticeable improvement in Number of transactions / latency.
What are you comparing to?
To start with, compare with:
- an unpatched PostgreSQL, configured normally, with normal logged tables
- an unpatched PostgreSQL, using UNLOGGED tables
- an unpatched PostgreSQL, using UNLOGGED tables and synchronous_commit = off (or fsync=off, but remember, that disables data integrity protections for system catalogs and everything).
Make sure you're introducing a suitably write-concurrent workload that might actually be waiting on WAL.
Personally I'd be surprised if you saw any significant difference over using UNLOGGED tables. That's why we have them ;)
Hi,
But so far, could not get any noticeable improvement in Number of transactions / latency.
You were right, the method you described worked well. Thanks you!
But so far, could not get any noticeable improvement in Number of transactions / latency.
I have tried:
1. At xlog.c, CopyXLogRecordToWAL(int write_len, bool isLogSwitch, XLogRecData *rdata,
1. At xlog.c, CopyXLogRecordToWAL(int write_len, bool isLogSwitch, XLogRecData *rdata,
XLogRecPtr StartPos, XLogRecPtr EndPos), Commenting the memcpy syscall:
2. XLogInsert(RmgrId rmid, uint8 info), the primary insert function in xloginsert.c.memcpy(currpos, rdata_data, rdata_len);
I tried commenting the following line at this function, so I can return a phony pointer every time the function is called, just as in bootstrap mode.
if (IsBootstrapProcessingMode() && rmid != RM_XLOG_ID)
3. At xlog.c, XLogInsertRecord(XLogRecData *rdata, XLogRecPtr fpw_lsn).
Commenting the WALInsertLock(s), as well as, commenting the spinlocks around - Update shared LogwrtRqst. (Write, if we crossed page boundary.)
4. The last thing I tried regarding XLogInsertRecord function is to comment:
"/*
"/*
* All the record data, including the header, is now ready to be
* inserted. Copy the record in the space reserved.
*/
CopyXLogRecordToWAL(rechdr->xl_tot_len, isLogSwitch, rdata,
StartPos, EndPos);"
Regards,
Netanel
On Mon, Jul 11, 2016 at 8:27 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
On 10 July 2016 at 18:27, Netanel Katzburg <netanel10k@gmail.com> wrote:BUT, both options are not good, as they are stopping me from even running initdb.
The easiest path for testing will be to use an unpatched PostgreSQL to `initdb` and create a new database. Then start up a patched one that simply skips WAL writing against an already-`initdb`'d data directory.You probably won't be able to safely restart PostgreSQL, but all you're doing is performance analsys so one-shot operation on a throw-away data directory is probably fine.--
On Thu, Jul 7, 2016 at 1:01 AM, Netanel Katzburg <netanel10k@gmail.com> wrote: > Hi All, > > As part of my masters at TAU, I'm currently conducting some research > regarding new persistent memory technology. > I'm using PG for this research and would like to better understand some of > the performance bottlenecks. > For this reason I'm trying to disable the WAL completely, using some hacks > on the source code and compiling my own version. > > So what I'm actually looking for, is some guidance about a simple way to: > > 1. Disable the WAL by not writing anything to the xlog directory. I don't > care about recovery/fault tolerance or PITR/ replication etc at the moment. > I'm aware that the WAL and checkpoint are bind in many ways and are crucial > for PG core features. > I tried changing the status of all tables to "unlogged" tables by changing > RelationNeedsWAL MACRO, as well as "needs_wal" parameter at storage.c. > But, got no performance benefit, so I guess this was the wrong place to > change. > > 2. Cancel the locking around WAL files - I don't care about corrupted files > at the moment, I just want to see what is the maximum performance benefit > that I can get without lock contention. > > Any guidance on how to do so would be appreciated :) I have a very old patch which introduces a config variable (JJNOWAL) that skips all WAL, except for the WAL of certain checkpoints (which are needed for initdb and to restart the server after a clean shutdown). I have rebased it up to HEAD. It seems to work, but I haven't tested thoroughly that it still does the correct thing in every corner case. (a lot of changes have been made to xlog code since last time I used this.) Obviously if the server goes down uncleanly while this setting is active, it will not be usable anymore. Cheers, Jeff
Вложения
<div dir="ltr">Your patch is very helpful, I'm still checking it on different file-systems.<br />I really liked the ideaof using only the edge checkpoints.<br />Thanks.</div><div class="gmail_extra"><br /><div class="gmail_quote">On Mon,Jul 11, 2016 at 9:26 PM, Jeff Janes <span dir="ltr"><<a href="mailto:jeff.janes@gmail.com" target="_blank">jeff.janes@gmail.com</a>></span>wrote:<br /><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px#ccc solid;padding-left:1ex"><span class="">On Thu, Jul 7, 2016 at 1:01 AM, Netanel Katzburg <<a href="mailto:netanel10k@gmail.com">netanel10k@gmail.com</a>>wrote:<br /> > Hi All,<br /> ><br /> > As part ofmy masters at TAU, I'm currently conducting some research<br /> > regarding new persistent memory technology.<br />> I'm using PG for this research and would like to better understand some of<br /> > the performance bottlenecks.<br/> > For this reason I'm trying to disable the WAL completely, using some hacks<br /> > on the sourcecode and compiling my own version.<br /> ><br /> > So what I'm actually looking for, is some guidance about asimple way to:<br /> ><br /> > 1. Disable the WAL by not writing anything to the xlog directory. I don't<br /> >care about recovery/fault tolerance or PITR/ replication etc at the moment.<br /> > I'm aware that the WAL and checkpointare bind in many ways and are crucial<br /> > for PG core features.<br /> > I tried changing the status ofall tables to "unlogged" tables by changing<br /> > RelationNeedsWAL MACRO, as well as "needs_wal" parameter at storage.c.<br/> > But, got no performance benefit, so I guess this was the wrong place to<br /> > change.<br /> ><br/> > 2. Cancel the locking around WAL files - I don't care about corrupted files<br /> > at the moment, I justwant to see what is the maximum performance benefit<br /> > that I can get without lock contention.<br /> ><br/> > Any guidance on how to do so would be appreciated :)<br /><br /></span>I have a very old patch which introducesa config variable (JJNOWAL)<br /> that skips all WAL, except for the WAL of certain checkpoints (which<br /> areneeded for initdb and to restart the server after a clean<br /> shutdown).<br /><br /> I have rebased it up to HEAD. It seems to work, but I haven't tested<br /> thoroughly that it still does the correct thing in every corner case.<br/> (a lot of changes have been made to xlog code since last time I used<br /> this.)<br /><br /> Obviously if theserver goes down uncleanly while this setting is<br /> active, it will not be usable anymore.<br /><br /> Cheers,<br /><br/> Jeff<br /></blockquote></div><br /></div>