Thanx for the link.

I just think that it would be a good idea, instead of posting the links at this 
list, to include a
dense but detailed summary of the situation in your machine, and give as much 
data as possible.
In short, you might do a quantitative compilation of this thread, and present 
it in a nice way
in order to gain more attention.
Also, i think posting to -stable would be a better idea, -questions is for 
noobs.

On Παρ 09 Νοε 2012 09:37:14 Frank Broniewski wrote:
> FYI 
> http://freebsd.1045724.n5.nabble.com/Postgresql-related-memory-question-td5759467.html
> 
> 
> Am 2012-11-07 10:28, schrieb Achilleas Mantzios:
> > On Τετ 07 Νοε 2012 09:42:47 Frank Broniewski wrote:
> >> Hey, this is really cool. I directly tried the script and there's a line
> >> from the output that caught my eye:
> >>
> >>   > mem_gap_vm:  +   8812892160 (   8404MB) [ 26%] Memory gap: UNKNOWN
> >>
> >> is this the shared buffers? I guess so, but I want to confirm my guess ...
> >
> > Hmm, that would be ideal, (from an understanding perspective) but at least 
> > in my system (FreeBSD-8.3), no.
> >
> > psql -q -t -c "show shared_buffers" | grep -v -e '^$' | awk '{print $1}'
> > 3840MB
> >
> > SYSTEM MEMORY INFORMATION:
> > mem_gap_vm:  +    996843520 (    950MB) [  5%] Memory gap: UNKNOWN
> >
> > $mem_gap_vm  = $mem_all - ($mem_wire + $mem_active + $mem_inactive + 
> > $mem_cache + $mem_free);
> >
> > mem_all is some rounded and more rationalized version less than hw.physmem 
> > : $mem_all = $sysctl->{"vm.stats.vm.v_page_count"} * 
> > $sysctl->{"hw.pagesize"};
> >
> > Anyway, this is not so postgresql related at the moment. The correct thing 
> > to do (since you run production servers on FreeBSD) is to post to the 
> > relevant
> > FreeBSD list and/or forum. [email protected] and 
> > [email protected] would be a good start.
> > Also the forums : http://forums.freebsd.org/forumdisplay.php?f=3
> > Only after gathering substantial info from there, would it make sense to 
> > come back here and maybe ask more questions.
> > And since we are observing different percentages of gaps (mine is 5%, yours 
> > is 26%), i think maybe you should look into it on the FreeBSD camp.
> >
> > Please drop the link to the relevant thread there, if you decide to do so.
> >
> > I would like to follow this.
> >
> > Thanx!
> >
> >>
> >> Frank
> >>
> >> Am 2012-11-07 09:26, schrieb Achilleas Mantzios:
> >>> Vick,
> >>> fantastic script, thanx! FreeBSD sysctl system is awesome!
> >>>
> >>> On Τρι 06 Νοε 2012 14:33:43 Vick Khera wrote:
> >>>
> >>>
> >>>
> >>> On Mon, Nov 5, 2012 at 10:11 AM, Frank Broniewski <[email protected]> wrote:
> >>>
> >>> and this is after a few hours of running:
> >>>
> >>> Mem: 91M Active, 17G Inact, 3983M Wired, 1526M Cache, 3283M Buf, 155M Free
> >>> Swap: 4096M Total, 828K Used, 4095M Free
> >>>
> >>>
> >>>
> >>>
> >>> For comparison, here is the output of a 32GB FreeBSD 9.0/amd64 server, 
> >>> with Postgres 9.0.7 running since June 10, and is heavily pounded on 
> >>> 24x7.  The data + indexes are about 240GB on disk.  This server only runs 
> >>> postgres aside from the basic system processes.
> >>>
> >>>
> >>> Mem: 231M Active, 21G Inact, 3777M Wired, 1009M Cache, 3285M Buf, 191M 
> >>> Free
> >>> Swap: 4096M Total, 272K Used, 4096M Free
> >>>
> >>>
> >>> I agree with the conclusion that the shared memory segments are confusing 
> >>> the output of top.  There are no memory leaks, and FreeBSD doesn't "lose" 
> >>> any memory.
> >>>
> >>>
> >>> There are some scripts floating around that read values from sysctl 
> >>> vm.stats.vm and format them nicely to tell you how much memory is used up 
> >>> and free.  Try the one referenced here: 
> >>> http://www.cyberciti.biz/faq/freebsd-command-to-get-ram-information/
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> -
> >>> Achilleas Mantzios
> >>> IT DEPT
> >>>
> >>
> >>
> >>
> > -
> > Achilleas Mantzios
> > IT DEPT
> >
> 
> 
> 
-
Achilleas Mantzios
IT DEPT


-- 
Sent via pgsql-general mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Reply via email to