Re: Postgres Performance Tuning

Поиск
Список
Период
Сортировка
От Achilleas Mantzios
Тема Re: Postgres Performance Tuning
Дата
Msg-id 201104041514.14509.achill@matrix.gatewaynet.com
обсуждение исходный текст
Ответ на Re: Postgres Performance Tuning  (Adarsh Sharma <adarsh.sharma@orkash.com>)
Список pgsql-performance
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 machine.

That said, and forgive me if i sound a little "explicit" but if you dont know how to install iostat
then there are few chances that you understand unix/linux/bsd concepts properly
and therefore any efforts to just speed up postgresql in such an environment , 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 (read 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 performance as well.

Στις Monday 04 April 2011 14:51:13 ο/η Adarsh Sharma έγραψε:
>
> Thanks Scott :
>
> My iostat package is not installed but have a look on below output:
>
> [root@s8-mysd-2 8.4SS]# vmstat 10
> procs -----------memory---------- ---swap-- -----io---- --system--
> -----cpu------
>  r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy
> id wa st
>  1  0 147664  93920  72332 15580748    0    1   113   170   47   177  6
> 1 92  1  0
>  0  0 147664  94020  72348 15580748    0    0     0     4  993   565  0
> 0 100  0  0
>  0  0 147664  93896  72364 15580748    0    0     0     5  993   571  0
> 0 100  0  0
>  0  0 147664  93524  72416 15580860    0    0     0   160 1015   591  0
> 0 100  0  0
>  0  0 147664  93524  72448 15580860    0    0     0     8 1019   553  0
> 0 100  0  0
>  0  0 147664  93648  72448 15580860    0    0     0     0 1019   555  0
> 0 100  0  0
>  0  0 147664  93648  72448 15580860    0    0     0     3 1023   560  0
> 0 100  0  0
>
> [root@s8-mysd-2 8.4SS]# iostat
> -bash: iostat: command not found
> [root@s8-mysd-2 8.4SS]#
>
> Best regards,
> Adarsh
>
> Scott Marlowe wrote:
> > On Mon, Apr 4, 2011 at 5:34 AM, Adarsh Sharma <adarsh.sharma@orkash.com> wrote:
> >
> >> Mem:  16299476k total, 16198784k used,   100692k free,    73776k buffers
> >> 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 and how
> >> to use Server parameters accordingly.
> >>
> >
> > 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?
> >
>
>



--
Achilleas Mantzios

В списке pgsql-performance по дате отправления:

Предыдущее
От: Adarsh Sharma
Дата:
Сообщение: Re: Postgres Performance Tuning
Следующее
От: Scott Marlowe
Дата:
Сообщение: Re: Postgres Performance Tuning