Christopher Browne a écrit :
Jeff Trout <[EMAIL PROTECTED]> writes:
I've run some of the queries that show up in explain, which seem to
be coming out sane. I'm just wondering if there is something I
should be looking into about speeding it up, or if I should
investigate something like log shipping. (I've got a master and 3
slaves. 2 of the slaves can lag a bit, 1 of the slaves should be
about <=1s )
I don't think log shipping would help anything here, from two perspectives:
1. It still requires having a regular subscriber around; all it
therefore buys you is the ability for *EXTRA* copies to be made more
cheaply.
2. There shouldn't be anything about log shipping itself that would
provide any extra efficiencies.
Should I look into perhaps seeing if those slow notify... queries
were trying to run at the same time as that log switch?
If things are too slow, about the only thing that has been observed (I
can't call it verified) that is argued to make a difference is to
increase the number of tuples processed at a time.
You *might* get a benefit by increasing the parameter
"SLON_DATA_FETCH_SIZE", presently set to 10, in slon.h, to some
moderately larger number.
I played a time with that, and also with removing the 'seqscan off' from
slony source.
The seqscan off come probably from long time ago ? Is it still necessary ?
I would expect it to be a Bad Thing to increase it to >> 1000, as this
would seem likely to make memory usage increase, with little
concommittant potential for improvement.
Assuming that fiddling with this *does* provide potential for
improvement for heavy-update sites, I would expect increasing it to
something like 50 to be the "conservative" approach...
However, that assumes that this could be a fruitful improvement, which
has yet to be verified...
For the most part, if you are finding things "too slow," then I would
be more inclined to point firstly at the ideas of:
- Tune Thy Database
and
- If Thine Database Be Tuned, then Upgrade Thine Hardware.
Performance of replication is mostly an emergent property falling from
how heavily loaded your systems are, and whether they actually have
the "bandwidth" free to cope with replication.
There isn't any obvious "Go Faster" flag - if there were, we'd have either:
a) Set it as a default, or
b) Noticed that it was a significant config parameter worth fiddling with.
_______________________________________________
Slony1-general mailing list
[email protected]
http://lists.slony.info/mailman/listinfo/slony1-general
