I suspect (but can't be sure) that slon 1.1.0 has some kind of memory
leak which we're only really seeing on the slave subscriber.
Our slave database server was restarted about a week ago and what we're
finding is that each day the amount of memory used keeps creeping up. To
the point where the 1Gb of physical RAM is exhausted, and then the
system starts using swap. Because of the RAID card used on this
(temporary) slave server, this leads to dire performance with a high
percentage i/o wait...
Killing the slon process and even stopping and restarting postgres
doesn't seem to really alleviate the problem very much. Only a server
reboot seems to do the trick, and then we get no problems for about a
week to 10 days.
When we were using slon 1.0.5 we never saw these kinds of problem...
Neither the OS (debian Linux fs01b 2.6.8.1-4-686-smp #1 SMP i686
GNU/Linux) nor the db (postgres 7.4.6) have changed - only slon is
upgraded (from 1.0.5 to 1.1.0).
This server only runs postgres, slon and a cron rsync job once every 15
minutes. We keep seeing high loads averages when the server is rsyncing
data from another server periodically through the day or when the
nightly vacuum is performed on the databases BUT not within a few days
of a server reboot.
We don't have any *large* records (no blobs etc), and
updates/inserts/deletes are usually in the order of several hundred
records an hour I would guess. There isn't really any large amounts of
slon traffic between the two databases.
Does this make any sense or ring any bells for anyone else?
John
Ian Burrell wrote:
It used to be that we would get 'out of memory' errors from slon
processes after the grew gradually for a wekk. Now, we have them
dying when trying to process a SYNC event.
We do have some really large records. I think the biggest is 3.7
million bytes and one table in sl_log_1 has an average length of
127,000.
The machine has 16 GB of RAM. We are running 32-bit slon processes on
64-bit x86_64 kernel so there should be say 2 GB of process memory. I
suspect that there is a memory leak in the slon daemon. Even the
largest 100 records should fit in memory.
- Ian
_______________________________________________
Slony1-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/slony1-general
_______________________________________________
Slony1-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/slony1-general
