Re: Sync Rep v17
От | Daniel Farina |
---|---|
Тема | Re: Sync Rep v17 |
Дата | |
Msg-id | AANLkTi=un9ycBfJtvJ14D5qPgyGfeh6Z4-FHj3HUyFrQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Sync Rep v17 (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Sync Rep v17
|
Список | pgsql-hackers |
On Fri, Feb 18, 2011 at 4:06 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > > Well, good news all round. > > v17 implements what I believe to be the final set of features for sync > rep. This one I'm actually fairly happy with. It can be enjoyed best at > DEBUG3. I've been messing with this patch and am wondering if this behavior is expected: I've been frobbing the server around (I was messing around with the syncrep feature, but do not know if this is related just yet), and came upon a case I do not expect: it would appear that prior to establishing a connection to do streaming replication, the "startup process" (which is recovering) is very slowly catching up (or so it would be indicated by txid_current_snapshot()) and eating up enormous amounts of memory, such as 6GB at a time in RES, monotonically increasing. Furthermore, the incrementation of the txid_snapshot is very slow, and it doesn't seem like I'm coming close to making full use of my resources: cpu and block devices are not very busy. There may have been a brief spurt of pgbench activity that would generate such WAL traffic to replay. I have not done a hard shutdown to my knowledge, and the server does allow me to query relatively quickly as a standby. Looks like I'm about to hit 7+GB. Is there something I'm missing? -- fdr
В списке pgsql-hackers по дате отправления: