From: Achilleas Mantzios <achill@matrix.gatewaynet.com>
Organization: Dynacom Tankers Mgmt
To: pgsql-performance@postgresql.org
Subject: Re: Postgres Performance Tuning
Date: Mon, 4 Apr 2011 14:14:14 +0200
User-Agent: KMail/1.9.7
References: <4D999211.9080507@orkash.com>
	<BANLkTi=irsx4RauJoLbPDRLqy8-MCP7G7g@mail.gmail.com>
	<4D99B0B1.4020702@orkash.com>
In-Reply-To: <4D99B0B1.4020702@orkash.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <201104041514.14509.achill@matrix.gatewaynet.com>

You got to have something to compare against.
I would say, try to run some benchmarks (pgbench from contrib) and compare =
them
against a known good instance of postgresql, if you have access in such a m=
achine.

That said, and forgive me if i sound a little "explicit" but if you dont kn=
ow how to install iostat
then there are few chances that you understand unix/linux/bsd concepts prop=
erly
and therefore any efforts to just speed up postgresql in such an environmen=
t , at this point,
will not have the desired effect, because even if you manage to solve smth =
now,
tommorow you will still be in confusion about smth else that might arise.
So, i suggest:
1) try to get an understanding on how your favorite distribution works (rea=
d any relevant info, net, books, etc..)
2) Go and get the book "PostgreSQL 9.0 High Performance" by Greg Smith. It =
is a very good book
not only about postgresql but about the current state of systems performanc=
e as well.

=CE=A3=CF=84=CE=B9=CF=82 Monday 04 April 2011 14:51:13 =CE=BF/=CE=B7 Adarsh=
 Sharma =CE=AD=CE=B3=CF=81=CE=B1=CF=88=CE=B5:
>=20
> Thanks Scott :
>=20
> My iostat package is not installed but have a look on below output:
>=20
> [root@s8-mysd-2 8.4SS]# vmstat 10
> procs -----------memory---------- ---swap-- -----io---- --system--=20
> -----cpu------
>  r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy=
=20
> id wa st
>  1  0 147664  93920  72332 15580748    0    1   113   170   47   177  6 =
=20
> 1 92  1  0
>  0  0 147664  94020  72348 15580748    0    0     0     4  993   565  0 =
=20
> 0 100  0  0
>  0  0 147664  93896  72364 15580748    0    0     0     5  993   571  0 =
=20
> 0 100  0  0
>  0  0 147664  93524  72416 15580860    0    0     0   160 1015   591  0 =
=20
> 0 100  0  0
>  0  0 147664  93524  72448 15580860    0    0     0     8 1019   553  0 =
=20
> 0 100  0  0
>  0  0 147664  93648  72448 15580860    0    0     0     0 1019   555  0 =
=20
> 0 100  0  0
>  0  0 147664  93648  72448 15580860    0    0     0     3 1023   560  0 =
=20
> 0 100  0  0
>=20
> [root@s8-mysd-2 8.4SS]# iostat
> -bash: iostat: command not found
> [root@s8-mysd-2 8.4SS]#
>=20
> Best regards,
> Adarsh
>=20
> Scott Marlowe wrote:
> > On Mon, Apr 4, 2011 at 5:34 AM, Adarsh Sharma <adarsh.sharma@orkash.com=
> wrote:
> >  =20
> >> Mem:  16299476k total, 16198784k used,   100692k free,    73776k buffe=
rs
> >> Swap: 16787884k total,   148176k used, 16639708k free, 15585396k cached
> >>
> >>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+
> >> COMMAND
> >>  3401 postgres  20   0 4288m 3.3g 3.3g S    0 21.1   0:24.73
> >> postgres
> >>  3397 postgres  20   0 4286m 119m 119m S    0  0.8   0:00.36
> >> postgres
> >> PLease help me to understand how much memory does 1 Connection Uses an=
d how
> >> to use Server parameters accordingly.
> >>    =20
> >
> > OK, first, see the 15585396k cached?  That's how much memory your OS
> > is using to cache file systems etc.  Basically that's memory not being
> > used by anything else right now, so the OS borrows it and uses it for
> > caching.
> >
> > Next, VIRT is how much memory your process would need to load every
> > lib it might need but may not be using now, plus all the shared memory
> > it might need, plus it's own space etc.  It's not memory in use, it's
> > memory that might under the worst circumstances, be used by that one
> > process.  RES is the amount of memory the process IS actually
> > touching, including shared memory that other processes may be sharing.
> >  Finally, SHR is the amount of shared memory the process is touching.
> > so, taking your biggest process, it is linked to enough libraries and
> > shared memory and it's own private memory to add up to 4288Meg.  It is
> > currently actually touching 3.3G.  Of that 3.3G it is touching 3.3G is
> > shared with other processes.  So, the difference between RES and SHR
> > is 0, so the delta, or extra memory it's using besides shared memory
> > is ZERO (or very close to it, probably dozens or fewer of megabytes).
> >
> > So, you're NOT running out of memory.  Remember when I mentioned
> > iostat, vmstat, etc up above?  Have you run any of those?
> >  =20
>=20
>=20


=2D-=20
Achilleas Mantzios