Wed Jun 9 23:46:33 PDT 2010
- Previous message: [Slony1-general] huge virtual memory size of slony1 proccess
- Next message: [Slony1-general] huge virtual memory size of slony1 proccess
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
10.06.2010 10:07, Scott Marlowe пишет: > 2010/6/9 Alexander V Openkin<open at immo.ru>: > >> 09.06.2010 18:27, Scott Marlowe пишет: >> >>> Oh whoa, I thought you were talking about the postgres backend that >>> slony connects to using up that much memory. >>> >>> >> no, we tolking about slon processes, not about postgres backend. >> >> >>> I wonder if there's some accounting difference in how your vps works >>> versus running right on the server. >>> >>> >> I have ~five replication cluster on slony1-1.2.14 and postgresql-8.3.9 on >> i686 architecture and >> we never see such problem... >> I think that no differents between running slony cluster on hardware server >> or VPS >> > Is this the same OS as on hardware? The accounting seems all kinds of > wrong to me. I just can't see slony asking for and getting 4G or 8G > of ram. > > The same linux kernel, on OpenVZ hardware server, we can run different OS (different linux distributions), but the kernel will be same. i run ps auxf on hardware server [root at vz19 ~]# ps auxf |grep slon |grep cms postgres 6973 0.0 0.0 40636 1836 ? S 09:58 0:00 \_ /usr/bin/slon -f /etc/slony1.d/blabla postgres 6974 0.0 0.0 4108420 1544 ? Sl 09:58 0:00 | \_ /usr/bin/slon -f /etc/slony1.d/blabla postgres 7016 0.0 0.0 40640 1836 ? S 09:58 0:00 \_ /usr/bin/slon -f /etc/slony1.d/blabla2 postgres 7017 0.0 0.0 4108424 1544 ? Sl 09:58 0:00 \_ /usr/bin/slon -f /etc/slony1.d/blabla2 [root at vz19 ~]# the fifth colunm is a VSZ (in kb) it show us two 4G segments... >>>> Besides OpenVZ divide shared memory and resident memory >>>> >>>> [root at vps6147 /]# cat /proc/user_beancounters |grep -E >>>> 'privvmpages|shmpages' >>>> privvmpages 2029830 2033439 2621440 2621440 5 >>>> shmpages 17632 17632 412000 412000 0 >>>> [root at vps6147 /]# >>>> >>>> first column - the current value in 4k pages, it`s indicates very small >>>> shared segment and huge resident segment, >>>> >>>> >>> Yeah, that's different from what I was thinking was going on. >>> >>> >>> >>>> Do you have a expirience using slony1 on x86_64 servers ? >>>> >>>> >>> Quite a bit actually. >>> >>>> We using slony1 replication about 3 year on i686 architecture and we >>>> hav`t >>>> >>> Is that a "have" or "haven't" ? >>> >> i mean haven't. >> i have a 3 year expirience with slon replication and postgresql8.{0,1,2,3} >> on i686 architecture and i have never seen it before >> > I have mostly experience on x86_64 / AMD64 hardware. A little in the > past on 32 bit pentium, but that was slony 1.0 days. > > >> yesterday i read a news on slony.info "Slony-I 2.0.3 is not usable in its >> current state." >> > Correct. Like 2.0.4 will be close. I tried it last year and it blew > up twice. Luckily switching out 1.2.latest for 2.0.x is pretty easily > done. > > >>>> similar problem.... >>>> >>>> PS we using the same OpenVZ template for application servers, and >>>> probability error in template or in the current VPS is minimum. >>>> >>> I've never run dbs inside vms before (seems counter productive to me) >>> >> PS sorry for my awful english, i am russian ) >> > Your English is much better than my Russian, no need to apologize. > > Have you tried switching it out for slony 1.2.latest? I'm thinking > it won't help this memory usage issue, but if you're in production you > should really be on 1.2.latest not 2.0.x. > > I'll try 1.2.latest, and show result's
- Previous message: [Slony1-general] huge virtual memory size of slony1 proccess
- Next message: [Slony1-general] huge virtual memory size of slony1 proccess
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-general mailing list