Re: postgresql + apache under heavy load

Поиск
Список
Период
Сортировка
От scott.marlowe
Тема Re: postgresql + apache under heavy load
Дата
Msg-id Pine.LNX.4.33.0401211158550.21143-100000@css120.ihs.com
обсуждение исходный текст
Ответ на Re: postgresql + apache under heavy load  (Alex Madon <alex.madon@bestlinuxjobs.com>)
Ответы Re: postgresql + apache under heavy load  (Alex Madon <alex.madon@bestlinuxjobs.com>)
Список pgsql-general
On Wed, 21 Jan 2004, Alex Madon wrote:

> Hello Scott,
> Thank you for your answer.
>
> >I'm not familiar with DBX.  Is that connection pooling or what?
> >
> >
> I could not find this information, sorry.
>
> >Are you SURE all your memory is in use?  What exactly does top say about
> >things like cached and buff memory (I'm assuming you're on linux, any
> >differences in top on another OS would be minor.)  If the kernel still
> >shows a fair bit of cached and buff memory, your memory is not getting all
> >used up.
> >
> Well my xosview show that caching begin at a concurrency of 40.
> At 80 my cache begins to be filled completely, so machine having big
> problems.

I think you're confusing what I meant.  Caching is good.  Swapping is bad.
Having a large amount of cache is a good thing.  It means the OS is
caching all your data in memory for faster access.

> >>If I increases to
> >>ab -n 1000 -c 100 http://localsite/testscript
> >>I get this memory problem.
> >>
> >>
> >
> >Where's the break point?  Just wondering.  Does it show up at 20, 40, 60,
> >80, or only at 100?  If so, that's really not bad.
> >
>  Here is some results (I kept -n 100 an just vraied the -c option)
> --c 1
> Failed requests:        0
> Time per request:       322.096 [ms] (mean, across all concurrent requests)
>
> -c 2
> Failed requests:        0
> Time per request:       374.220 [ms] (mean, across all concurrent requests)
>
> -c 10
> Failed requests:        68
>  (Connect: 0, Length: 68, Exceptions: 0)
> Time per request:       314.779 [ms] (mean, across all concurrent requests)

OK, there's a problem, you're getting failed requests at -c 10, which
means you likely have postgresql configured in the wrong
direction.  configure postgresql to use more memory (sort_mem can be set
to about 8 megs without a lot of issues on most boxes, going higher may
use up all your memory in certain situations (high concurrency)).

> For a higher concurrency, the cache is completly filled, and have to
> reboot the machine.

No, you should NEVER have to reboot a unix box.  period.  filled cache,
again, is a GOOD THING.   not bad.

> (I didn't leave the system caching forever, just press to reboot
> button)... could be interesting to wait to see if the systems recovers
> after a while

Yes, please do.  Also, show us a save of top while under load.

I'm betting your machine has plenty of memory, and is not using it
effectively, due to postgresql being too conservatively configured.




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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Getting rid of duplicate tables.
Следующее
От: Alex Madon
Дата:
Сообщение: Re: postgresql + apache under heavy load