postgresql + apache under heavy load

[Alex Madon]

Hello,
I am testing a web application (using the DBX PHP function to call a
Postgresql backend).
I have 375Mb RAM on my test home box.
I ran ab (apache benchmark) to test the behaviour of the application
under heavy load.
When increasing the number of requests, all my memory is filled, and the
Linux server begins to cache and remains frozen.

ab -n 100 -c 10 http://localsite/testscript
behaves OK.

If I increases to
ab -n 1000 -c 100 http://localsite/testscript
I get this memory problem.

If I eliminate the connection to the (UNIX) socket of Postgresql, the
script behaves well even under very high load (and of course with much
less time spent per request).

I tried to change some parameters in postgresql.conf
max_connections = 32
to max_connections = 8

and

shared_buffers = 64
to shared_buffers = 16

without success.

I tried to use pmap on httpd and postmaster Process ID but don't get
much help.

Does anybody have some idea to help to debug/understand/solve this
issue? Any feedback is appreciated.
To me, it would not be a problem if the box is very slow under heavy
load (DoS like), but I really dislike having my box out of service after
such a DoS attack.
I am looking for a way to limit the memory used by postgres.

Thanks
Alex


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[scott.marlowe]

Re: postgresql + apache under heavy load

On Wed, 21 Jan 2004, Alex Madon wrote:
[color=blue]
> Hello,
> I am testing a web application (using the DBX PHP function to call a
> Postgresql backend).[/color]

I'm not familiar with DBX. Is that connection pooling or what?
[color=blue]
> I have 375Mb RAM on my test home box.
> I ran ab (apache benchmark) to test the behaviour of the application
> under heavy load.
> When increasing the number of requests, all my memory is filled, and the
> Linux server begins to cache and remains frozen.[/color]

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.
[color=blue]
> ab -n 100 -c 10 http://localsite/testscript
> behaves OK.[/color]

Keep in mind, this is 10 simo users beating the machine continuously.
that's functionally equivalent to about 100 to 200 people running through
pages as fast as people can.
[color=blue]
> If I increases to
> ab -n 1000 -c 100 http://localsite/testscript
> I get this memory problem.[/color]

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.
[color=blue]
> If I eliminate the connection to the (UNIX) socket of Postgresql, the
> script behaves well even under very high load (and of course with much
> less time spent per request).[/color]

Of course, the database is the most expensive part of an application,
CPU/Memory wise, written on apache/php
[color=blue]
> I tried to change some parameters in postgresql.conf
> max_connections = 32
> to max_connections = 8[/color]

Wrong direction. The number of connections postgresql CAN create costs
very little. The number of connections it does create, still, costs very
little. Have you checked to see if ab is getting valid pages, and not
"connection failed, too many connections already open" pages?
[color=blue]
> shared_buffers = 64
> to shared_buffers = 16[/color]

Way the wrong way. Shared buffers are the max memory all the backends
together share. The old setting was 512k ram, now you're down to 128k.
while 128k would be a lot of memory for a Commodore 128, for a machine
with 384 meg ram, it's nothing. Since this is a TOTAL shared memory
setting, not a per process thing, you can hand it a good chunk of ram and
not usually worry about it. Set it to 512 and just leave it. That's only
4 megs of shared memory, if your machine is running that low, other things
have gone wrong.
[color=blue]
> without success.
>
> I tried to use pmap on httpd and postmaster Process ID but don't get
> much help.
>
> Does anybody have some idea to help to debug/understand/solve this
> issue? Any feedback is appreciated.
> To me, it would not be a problem if the box is very slow under heavy
> load (DoS like), but I really dislike having my box out of service after
> such a DoS attack.[/color]

Does it not come back? That's bad.

[color=blue]
> I am looking for a way to limit the memory used by postgres.[/color]

Don't it's likely not using too much.

What does top say is the highest memory user?


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Joshua D. Drake]

Re: postgresql + apache under heavy load

Alex Madon wrote:
[color=blue]
> Hello,
> I am testing a web application (using the DBX PHP function to call a
> Postgresql backend).
> I have 375Mb RAM on my test home box.
> I ran ab (apache benchmark) to test the behaviour of the application
> under heavy load.
> When increasing the number of requests, all my memory is filled, and
> the Linux server begins to cache and remains frozen.
>
> ab -n 100 -c 10 http://localsite/testscript
> behaves OK.
>
> If I increases to
> ab -n 1000 -c 100 http://localsite/testscript
> I get this memory problem.[/color]


We would need a lot more information. What version of Linux? What
version of the Kernel? What is your shmmax settting?
What is your sort_mem setting? Did you use top to see where the hang up?
Are there any messages in /var/log/messages?

Sincerely,

Joshua D. Drake


[color=blue]
>
> If I eliminate the connection to the (UNIX) socket of Postgresql, the
> script behaves well even under very high load (and of course with much
> less time spent per request).
>
> I tried to change some parameters in postgresql.conf
> max_connections = 32
> to max_connections = 8
>
> and
>
> shared_buffers = 64
> to shared_buffers = 16
>
> without success.
>
> I tried to use pmap on httpd and postmaster Process ID but don't get
> much help.
>
> Does anybody have some idea to help to debug/understand/solve this
> issue? Any feedback is appreciated.
> To me, it would not be a problem if the box is very slow under heavy
> load (DoS like), but I really dislike having my box out of service
> after such a DoS attack.
> I am looking for a way to limit the memory used by postgres.
>
> Thanks
> Alex
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if
> your
> joining column's datatypes do not match[/color]



--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandpromp t.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[Richard Huxton]

Re: postgresql + apache under heavy load

On Wednesday 21 January 2004 14:11, Alex Madon wrote:[color=blue]
> Hello,
> I am testing a web application (using the DBX PHP function to call a
> Postgresql backend).
> I have 375Mb RAM on my test home box.[/color]
[10 connections is fine, 100 is not]
[color=blue]
> I tried to change some parameters in postgresql.conf
> max_connections = 32
> to max_connections = 8[/color]

Are you saying you had more than 8 connections open simultaneously? Are you
sure you restarted PG so that it noticed the new values? You can check config
settings with "show all;" from psql, or "show <setting>".

You'll want to use the "top" command to show the amount of memory each process
is using and then check the configuration/tuning articles at the following
URL:

http://www.varlena.com/varlena/GeneralBits/Tidbits/index.php

First step is to make sure your changes are being detected. Then, I'd guess
you want to set:
max_connections
shared_buffers
sort_mem
vacuum_mem (less important)
and then adjust effective_cache _size so it matches your normal load.

--
Richard Huxton
Archonet Ltd

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to majordomo@postg resql.org)

[Ericson Smith]

Re: postgresql + apache under heavy load

Could be problem be that PHP is not using connection efficiently?
Apache KeepAlive with PHP, is a dual edged sword with you holding the
blade :-)

If I am not mistaken, what happens is that a connection is kept alive
because Apache believes that other requests will come in from the client
who made the initial connection. So 10 concurrent connections are fine,
but they are not released timely enough with 100 concurrent connections.
The system ends up waiting around for other KeepAlive connections to
timeout before Apache allows others to come in. We had this exact
problem in an environment with millions of impressions per day going to
the database. Because of the nature of our business, we were able to
disable KeepAlive and the load immediately dropped (concurrent
connection on the Postgresql database also dropped sharply). We also
turned off PHP persistent connections to the database.

The drawback is that connections are built up and torn down all the
time, and with Postgresql, it is sort of expensive. But thats a fraction
of the expense of having KeepAlive on.

Warmest regards,
Ericson Smith
Tracking Specialist/DBA
+-----------------------+--------------------------------------+
| http://www.did-it.com | "Crush my enemies, see then driven |
| eric@did-it.com | before me, and hear the lamentations |
| 516-255-0500 | of their women." - Conan |
+-----------------------+--------------------------------------+



Alex Madon wrote:
[color=blue]
> Hello,
> I am testing a web application (using the DBX PHP function to call a
> Postgresql backend).
> I have 375Mb RAM on my test home box.
> I ran ab (apache benchmark) to test the behaviour of the application
> under heavy load.
> When increasing the number of requests, all my memory is filled, and
> the Linux server begins to cache and remains frozen.
>
> ab -n 100 -c 10 http://localsite/testscript
> behaves OK.
>
> If I increases to
> ab -n 1000 -c 100 http://localsite/testscript
> I get this memory problem.
>
> If I eliminate the connection to the (UNIX) socket of Postgresql, the
> script behaves well even under very high load (and of course with much
> less time spent per request).
>
> I tried to change some parameters in postgresql.conf
> max_connections = 32
> to max_connections = 8
>
> and
>
> shared_buffers = 64
> to shared_buffers = 16
>
> without success.
>
> I tried to use pmap on httpd and postmaster Process ID but don't get
> much help.
>
> Does anybody have some idea to help to debug/understand/solve this
> issue? Any feedback is appreciated.
> To me, it would not be a problem if the box is very slow under heavy
> load (DoS like), but I really dislike having my box out of service
> after such a DoS attack.
> I am looking for a way to limit the memory used by postgres.
>
> Thanks
> Alex
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if
> your
> joining column's datatypes do not match
>[/color]


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[Alex Madon]

Re: postgresql + apache under heavy load

Hello Scott,
Thank you for your answer.
[color=blue]
>I'm not familiar with DBX. Is that connection pooling or what?
>
>[/color]
I could not find this information, sorry.
[color=blue]
>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.
>[/color]
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.
[color=blue][color=green]
>>If I increases to
>>ab -n 1000 -c 100 http://localsite/testscript
>>I get this memory problem.
>>
>>[/color]
>
>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.
>[/color]
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)

-c 20
Failed requests: 68
Time per request: 369.290 [ms] (mean, across all concurrent requests)

-c 30
Failed requests: 43
Time per request: 441.947 [ms] (mean, across all concurrent requests)

=====Here begins caching to disk====

-c 40
Failed requests: 65
Time per request: 528.829 [ms] (mean, across all concurrent requests)

-c 50
Failed requests: 66
Time per request: 993.674 [ms] (mean, across all concurrent requests)

For a higher concurrency, the cache is completly filled, and have to
reboot the machine.
(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
[color=blue][color=green]
>>To me, it would not be a problem if the box is very slow under heavy
>>load (DoS like), but I really dislike having my box out of service after
>>such a DoS attack.
>>
>>[/color]
>
>Does it not come back? That's bad.
>
>[/color]
see above

thanks
Alex


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postg resql.org so that your
message can get through to the mailing list cleanly

[scott.marlowe]

Re: postgresql + apache under heavy load

On Wed, 21 Jan 2004, Alex Madon wrote:
[color=blue]
> Hello Scott,
> Thank you for your answer.
>[color=green]
> >I'm not familiar with DBX. Is that connection pooling or what?
> >
> >[/color]
> I could not find this information, sorry.
>[color=green]
> >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.
> >[/color]
> 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.[/color]

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.
[color=blue][color=green][color=darkred]
> >>If I increases to
> >>ab -n 1000 -c 100 http://localsite/testscript
> >>I get this memory problem.
> >>
> >>[/color]
> >
> >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.
> >[/color]
> 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)[/color]

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)).
[color=blue]
> For a higher concurrency, the cache is completly filled, and have to
> reboot the machine.[/color]

No, you should NEVER have to reboot a unix box. period. filled cache,
again, is a GOOD THING. not bad.
[color=blue]
> (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[/color]

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.




---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Alex Madon]

Re: postgresql + apache under heavy load

Hello Joshua,
Thank you for your reply.
Joshua D. Drake wrote:
[color=blue]
>
>
> We would need a lot more information. What version of Linux?[/color]

uname -a
Linux daube 2.4.20-8 #1 Thu Mar 13 17:18:24 EST 2003 i686 athlon i386
GNU/Linux

[color=blue]
> What version of the Kernel? What is your shmmax settting?[/color]

cat /proc/sys/kernel/shmmax
33554432
[color=blue]
>
> What is your sort_mem setting?[/color]

I didn't change the postgresql.conf settings:
#sort_mem = 1024 # min 64, size in KB
[color=blue]
> Did you use top to see where the hang up? Are there any messages in
> /var/log/messages?[/color]

Well as I said before the box is almost out of control: disk is caching
intensively; I run X Windows and the mouse can not point a shell... very
bad. The only thing I see is that cache is filling quickly with
xosview... and then X become frozen (or better said extremely slow).

Abou the logs:
I sent the PHP error messages to a file, and yes there are errors:
pg_connect(): Unable to connect to PostgreSQL server: FATAL:
Non-superuser connection limit exceeded
or
pg_connect(): Unable to connect to PostgreSQL server: FATAL: Sorry, too
many clients already


Thanks
Alex


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to majordomo@postg resql.org)

[Alex Madon]

Re: postgresql + apache under heavy load

Hello Richard,
Thank you for your answer.
Richard Huxton wrote:
[color=blue]
>Are you saying you had more than 8 connections open simultaneously?
>[/color]
Well, I don't know how to find that out.
What I did is issuing several tomes a ps aux and I never saw more than
6-7 postmaster SELECT.
[color=blue]
>Are you
>sure you restarted PG so that it noticed the new values? You can check config
>settings with "show all;" from psql, or "show <setting>".
>[/color]
Yes I restart it. The show command outputs the correct value (8).
[color=blue]
>
>You'll want to use the "top" command to show the amount of memory each process
>[/color]

A typical output (in a concurrency of 20, no cache) is:
ps aux | grep postgres
postgres 2332 0.0 0.0 8804 328 ? R 18:54 0:01
/usr/bin/postmaster -p 5432 -d2
postgres 2334 0.0 0.0 9792 68 ? S 18:54 0:00 postgres:
stats buffer process
postgres 2335 0.0 0.0 8828 200 ? S 18:54 0:00 postgres:
stats collector process
postgres 4386 0.0 0.2 4312 956 pts/3 S 19:22 0:00 -bash
postgres 4871 0.0 0.5 9480 2304 ? S 20:36 0:00 postgres:
user db [local] SELECT
postgres 4873 0.0 0.2 8816 1032 ? R 20:36 0:00 postgres:
user db [local] startup
myuser 4877 0.0 0.1 3572 624 pts/4 S 20:36 0:00 grep postgres
postgres 4878 0.0 0.5 9220 2228 ? R 20:36 0:00 postgres:
user db [local] SELECT
postgres 4879 0.0 0.5 9204 2016 ? R 20:36 0:00 postgres:
user db [local] SELECT
---------------------------top-----------------------------
114 processes: 99 sleeping, 12 running, 3 zombie, 0 stopped
CPU states: 91.8% user 8.1% system 0.0% nice 0.0% iowait 0.0% idle
Mem: 384580k av, 316328k used, 68252k free, 0k shrd, 25424k
buff
253976k actv, 36916k in_d, 4704k in_c
Swap: 265064k av, 64788k used, 200276k free 71132k
cached

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
4914 apache 16 0 9016 8416 2552 S 6.7 2.1 0:00 0 httpd
4832 apache 16 0 9016 8416 2552 S 6.3 2.1 0:01 0 httpd
4915 apache 16 0 9016 8416 2552 S 5.9 2.1 0:00 0 httpd
4917 apache 16 0 9016 8416 2552 S 5.9 2.1 0:00 0 httpd
4919 apache 16 0 9020 8420 2536 S 5.9 2.1 0:00 0 httpd
4774 apache 16 0 9016 8416 2552 S 5.7 2.1 0:02 0 httpd
4896 apache 16 0 9060 8460 2568 S 5.7 2.1 0:00 0 httpd
4908 apache 15 0 9016 8416 2552 S 5.7 2.1 0:00 0 httpd
4909 apache 16 0 9016 8416 2552 S 5.7 2.1 0:00 0 httpd
4658 apache 16 0 9136 8536 2568 S 5.5 2.2 0:04 0 httpd
4921 apache 16 0 9016 8416 2552 S 5.5 2.1 0:00 0 httpd
2581 root 16 0 14492 4544 1252 R 5.3 1.1 2:26 0 X
4795 apache 16 0 9104 8504 2568 S 5.3 2.2 0:02 0 httpd
4796 apache 16 0 9080 8480 2568 S 5.3 2.2 0:01 0 httpd
4782 apache 16 0 8924 8324 2568 R 3.5 2.1 0:02 0 httpd
2612 madona 15 0 4524 4136 2380 S 1.5 1.0 0:18 0 metacity
4656 apache 15 0 9084 8484 2568 S 1.3 2.2 0:03 0 httpd
4950 postgres 25 0 0 0 0 Z 1.1 0.0 0:00 0
postmaster <defunct>
3812 madona 15 0 44728 42M 17460 S 0.7 11.2 3:21 0
mozilla-bin
4947 postgres 25 0 2540 2392 1688 S 0.7 0.6 0:00 0 postmaster
4952 postgres 25 0 2812 2664 1872 R 0.7 0.6 0:00 0 postmaster
4610 madona 15 0 7460 7460 2152 R 0.5 1.9 0:00 0 xterm
4904 madona 15 0 1108 1108 856 R 0.3 0.2 0:00 0 top
4954 postgres 24 0 1916 1768 1244 R 0.1 0.4 0:00 0 postmaster
4959 postgres 25 0 1596 1448 940 S 0.1 0.3 0:00 0 postmaster
4961 postgres 25 0 984 824 640 R 0.1 0.2 0:00 0 postmaster
1 root 15 0 88 60 40 S 0.0 0.0 0:04 0 init



Thanks
Alex



---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[Alex Madon]

Re: postgresql + apache under heavy load

Hello Ericson,
Thank you for your reply.
Ericson Smith wrote:
[color=blue]
> Could be problem be that PHP is not using connection efficiently?
> Apache KeepAlive with PHP, is a dual edged sword with you holding the
> blade :-)[/color]

I turned off the KeepAlive option in httpd.conf

[
I think keepalive is not used by default by "ab" and that apche uses it
only on static content)-- see the last paragraph of:

http://httpd.apache.org/docs/keepalive.html

]
and set
pgsql.allow_per sistent = Off
in php.ini,
it didn't work for me.
thanks
Alex
[color=blue]
>
> If I am not mistaken, what happens is that a connection is kept alive
> because Apache believes that other requests will come in from the
> client who made the initial connection. So 10 concurrent connections
> are fine, but they are not released timely enough with 100 concurrent
> connections. The system ends up waiting around for other KeepAlive
> connections to timeout before Apache allows others to come in. We had
> this exact problem in an environment with millions of impressions per
> day going to the database. Because of the nature of our business, we
> were able to disable KeepAlive and the load immediately dropped
> (concurrent connection on the Postgresql database also dropped
> sharply). We also turned off PHP persistent connections to the database.
>
> The drawback is that connections are built up and torn down all the
> time, and with Postgresql, it is sort of expensive. But thats a
> fraction of the expense of having KeepAlive on.
>
> Warmest regards, Ericson Smith
> Tracking Specialist/DBA
> +-----------------------+--------------------------------------+
> | http://www.did-it.com | "Crush my enemies, see then driven |
> | eric@did-it.com | before me, and hear the lamentations |
> | 516-255-0500 | of their women." - Conan |
> +-----------------------+--------------------------------------+
>
>
> Alex Madon wrote:
>[color=green]
>> Hello,
>> I am testing a web application (using the DBX PHP function to call a
>> Postgresql backend).
>> I have 375Mb RAM on my test home box.
>> I ran ab (apache benchmark) to test the behaviour of the application
>> under heavy load.
>> When increasing the number of requests, all my memory is filled, and
>> the Linux server begins to cache and remains frozen.
>>
>> ab -n 100 -c 10 http://localsite/testscript
>> behaves OK.
>>
>> If I increases to
>> ab -n 1000 -c 100 http://localsite/testscript
>> I get this memory problem.
>>
>> If I eliminate the connection to the (UNIX) socket of Postgresql, the
>> script behaves well even under very high load (and of course with
>> much less time spent per request).
>>
>> I tried to change some parameters in postgresql.conf
>> max_connections = 32
>> to max_connections = 8
>>
>> and
>>
>> shared_buffers = 64
>> to shared_buffers = 16
>>
>> without success.
>>
>> I tried to use pmap on httpd and postmaster Process ID but don't get
>> much help.
>>
>> Does anybody have some idea to help to debug/understand/solve this
>> issue? Any feedback is appreciated.
>> To me, it would not be a problem if the box is very slow under heavy
>> load (DoS like), but I really dislike having my box out of service
>> after such a DoS attack.
>> I am looking for a way to limit the memory used by postgres.
>>
>> Thanks
>> Alex
>>
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 9: the planner will ignore your desire to choose an index scan if
>> your
>> joining column's datatypes do not match
>>[/color][/color]



---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to majordomo@postg resql.org)

[Alex Madon]

Re: postgresql + apache under heavy load

Hello Scott,
Thank you for your reply.
[color=blue]
>
>I think you're confusing what I meant. Caching is good. Swapping is[/color]
bad.[color=blue]
>Having a large amount of cache is a good thing. It means the OS is
>caching all your data in memory for faster access.
>[/color]
OK; Sorry about my approximative language. I was meaning, caching to
disk... so better said as you point out is swapping.
So my system is filling the RAM (OK to me) and then begins to fill all
the Swap.
When the swap is used at near 100%, the system becomes extremely
difficult to control (not actually crashing, but accessing disk very
noisily).
[color=blue]
>
>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)).
>[/color]
Thank you!
I setting sort_mem to 8 Mb and max_connections = 32, I have zero failed
with a c=20 and 1 failed with a c=30!
Decreasing max_connections to 8 gave me a lot of failed as before.
[color=blue]
>
>No, you should NEVER have to reboot a unix box. period. filled cache,
>again, is a GOOD THING. not bad.
>[/color]
sorry, I was meaning swapping.

[color=blue][color=green]
>>button)... could be interesting to wait to see if the systems recovers
>>after a while[/color]
>
>
>Yes, please do. Also, show us a save of top while under load.[/color]

Well, increasing the sort_mem and max_connections was very good to have
less failed, but this does not solve the memory limitation.
Perhaps that comes from my superficial understanding of concurrency.

Does anybody have a simple formula to know how much memory a ab
benchmark will need in this case (assuming one knows the memory needed
by one apache process (A) and the memory used by one postgres process (P)?

I would say, issuing a ab -n N -c C (asuming there is no shared library
between apache and postgres)
memory needed= CxA + CxP
(independent of N?)

Just another pedestrian question: what usually happens to a linux box
when swap is exhausted?
Is the parent process killed? Could this crash the whole machine?

My conclusion up to now, is that this box does not stand more than 40
concurrent connections.
To stand more concurrent connections, I'd need to increase the RAM or
redesign my software, e.g. using a PHP cache, static pages being served
much faster (almost by a factor 100...)
Thanks
Alex



---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[Robert Treat]

Re: postgresql + apache under heavy load

On Wed, 2004-01-21 at 13:48, Alex Madon wrote:[color=blue]
> Hello Scott,
> Thank you for your answer.
>[color=green]
> >I'm not familiar with DBX. Is that connection pooling or what?
> >
> >[/color]
> I could not find this information, sorry.
>[/color]

It's generic database access functions written in C. It's not connection
pooling.

http://www.php.net/manual/en/ref.dbx.php

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to majordomo@postg resql.org)

[Richard Huxton]

Re: postgresql + apache under heavy load

On Wednesday 21 January 2004 19:40, Alex Madon wrote:
Alex - I'm copying scott in on this since he asked for details on top too.[color=blue]
>
> Richard Huxton wrote:[color=green]
> >Are you saying you had more than 8 connections open simultaneously?[/color]
>
> Well, I don't know how to find that out.
> What I did is issuing several tomes a ps aux and I never saw more than
> 6-7 postmaster SELECT.[/color]

Good enough for me - that's what I'd have done.
[color=blue][color=green]
> >Are you
> >sure you restarted PG so that it noticed the new values? You can check
> > config settings with "show all;" from psql, or "show <setting>".[/color]
>
> Yes I restart it. The show command outputs the correct value (8).[/color]

Good - I don't think PG is using up your system memory, then (but we'll see).
[color=blue]
> ---------------------------top-----------------------------
> 114 processes: 99 sleeping, 12 running, 3 zombie, 0 stopped
> CPU states: 91.8% user 8.1% system 0.0% nice 0.0% iowait 0.0% idle
> Mem: 384580k av, 316328k used, 68252k free, 0k shrd, 25424k
> buff
> 253976k actv, 36916k in_d, 4704k in_c
> Swap: 265064k av, 64788k used, 200276k free 71132k
> cached[/color]

If I'm decoding this through the email line wrapping you've got 71MB of disk
cached in RAM and 25MB used as i/o buffers (which is a good thing). I'm a
little puzzled as to why your swap is so high, but as long as it isn't
growing rapidly there shouldn't be a problem.
[color=blue]
> PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
> 4914 apache 16 0 9016 8416 2552 S 6.7 2.1 0:00 0 httpd
> 4832 apache 16 0 9016 8416 2552 S 6.3 2.1 0:01 0 httpd[/color]

OK - so each httpd process is using about 8500KB with 2500KB shared = 6MB
each.
[color=blue]
> 4947 postgres 25 0 2540 2392 1688 S 0.7 0.6 0:00 0
> postmaster
> 4952 postgres 25 0 2812 2664 1872 R 0.7 0.6 0:00 0
> postmaster
> 4954 postgres 24 0 1916 1768 1244 R 0.1 0.4 0:00 0 postmaster
> 4959 postgres 25 0 1596 1448 940 S 0.1 0.3 0:00 0 postmaster
> 4961 postgres 25 0 984 824 640 R 0.1 0.2 0:00 0 postmaster[/color]

Here we've got what appears to be about 1MB per PG backend. Since you've only
got 8, that should be fine.

[I noticed you were running X and mozilla (on top of gnome?). If you don't
need them, close them - that can free up to 64MB, depending on what you're
running]

I don't think you've got a RAM shortage, I think your settings are too small
and you're running out of I/O bandwidth. If you run "vmstat 5", what does it
show - you're interested in the i/o section: blocks in (bi) and out (bo) as
well as memory.
Save your readings, then follow the advice in that GeneralBits link I posted
earlier and see if that makes a difference.

--
Richard Huxton
Archonet Ltd

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[scott.marlowe]

Re: postgresql + apache under heavy load

On Wed, 21 Jan 2004, Alex Madon wrote:
[color=blue][color=green]
> >You'll want to use the "top" command to show the amount of memory each process
> >[/color]
>
> A typical output (in a concurrency of 20, no cache) is:
> ps aux | grep postgres
> postgres 2332 0.0 0.0 8804 328 ? R 18:54 0:01
> /usr/bin/postmaster -p 5432 -d2
> postgres 2334 0.0 0.0 9792 68 ? S 18:54 0:00 postgres:
> stats buffer process
> postgres 2335 0.0 0.0 8828 200 ? S 18:54 0:00 postgres:
> stats collector process
> postgres 4386 0.0 0.2 4312 956 pts/3 S 19:22 0:00 -bash
> postgres 4871 0.0 0.5 9480 2304 ? S 20:36 0:00 postgres:
> user db [local] SELECT
> postgres 4873 0.0 0.2 8816 1032 ? R 20:36 0:00 postgres:
> user db [local] startup
> myuser 4877 0.0 0.1 3572 624 pts/4 S 20:36 0:00 grep postgres
> postgres 4878 0.0 0.5 9220 2228 ? R 20:36 0:00 postgres:
> user db [local] SELECT
> postgres 4879 0.0 0.5 9204 2016 ? R 20:36 0:00 postgres:
> user db [local] SELECT
> ---------------------------top-----------------------------
> 114 processes: 99 sleeping, 12 running, 3 zombie, 0 stopped
> CPU states: 91.8% user 8.1% system 0.0% nice 0.0% iowait 0.0% idle
> Mem: 384580k av, 316328k used, 68252k free, 0k shrd, 25424k
> buff
> 253976k actv, 36916k in_d, 4704k in_c
> Swap: 265064k av, 64788k used, 200276k free 71132k
> cached
>
> PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
> 4914 apache 16 0 9016 8416 2552 S 6.7 2.1 0:00 0 httpd
> 4832 apache 16 0 9016 8416 2552 S 6.3 2.1 0:01 0 httpd
> 4915 apache 16 0 9016 8416 2552 S 5.9 2.1 0:00 0 httpd
> 4917 apache 16 0 9016 8416 2552 S 5.9 2.1 0:00 0 httpd
> 4919 apache 16 0 9020 8420 2536 S 5.9 2.1 0:00 0 httpd
> 4774 apache 16 0 9016 8416 2552 S 5.7 2.1 0:02 0 httpd
> 4896 apache 16 0 9060 8460 2568 S 5.7 2.1 0:00 0 httpd
> 4908 apache 15 0 9016 8416 2552 S 5.7 2.1 0:00 0 httpd
> 4909 apache 16 0 9016 8416 2552 S 5.7 2.1 0:00 0 httpd
> 4658 apache 16 0 9136 8536 2568 S 5.5 2.2 0:04 0 httpd
> 4921 apache 16 0 9016 8416 2552 S 5.5 2.1 0:00 0 httpd
> 2581 root 16 0 14492 4544 1252 R 5.3 1.1 2:26 0 X
> 4795 apache 16 0 9104 8504 2568 S 5.3 2.2 0:02 0 httpd
> 4796 apache 16 0 9080 8480 2568 S 5.3 2.2 0:01 0 httpd
> 4782 apache 16 0 8924 8324 2568 R 3.5 2.1 0:02 0 httpd
> 2612 madona 15 0 4524 4136 2380 S 1.5 1.0 0:18 0 metacity
> 4656 apache 15 0 9084 8484 2568 S 1.3 2.2 0:03 0 httpd
> 4950 postgres 25 0 0 0 0 Z 1.1 0.0 0:00 0
> postmaster <defunct>
> 3812 madona 15 0 44728 42M 17460 S 0.7 11.2 3:21 0
> mozilla-bin
> 4947 postgres 25 0 2540 2392 1688 S 0.7 0.6 0:00 0 postmaster
> 4952 postgres 25 0 2812 2664 1872 R 0.7 0.6 0:00 0 postmaster
> 4610 madona 15 0 7460 7460 2152 R 0.5 1.9 0:00 0 xterm
> 4904 madona 15 0 1108 1108 856 R 0.3 0.2 0:00 0 top
> 4954 postgres 24 0 1916 1768 1244 R 0.1 0.4 0:00 0 postmaster
> 4959 postgres 25 0 1596 1448 940 S 0.1 0.3 0:00 0 postmaster
> 4961 postgres 25 0 984 824 640 R 0.1 0.2 0:00 0 postmaster
> 1 root 15 0 88 60 40 S 0.0 0.0 0:04 0 init[/color]

OK, the memory usage is NOT your problem. You have crashing postgresql
backends, see the <defunct> and the listing of 3 zombie processes in top?
That's bad. You very likely have bad memory in your box, or possibly
other hardware problems. It could be software, if you've got a really odd
configuration (i.e. compiling apache against one ldap sdk, and php against
another can make apache start failing, something similar may be happening
in postgresql, but I doubt it.)

You should go to www.memtest86.com and download their free tester and see
if your machine has any bad ram.

The reason the machine will get really slow when this happens is that the
postgresql database has to reset all the cache on all backends when one
crashes to prevent corruption.

The fact that X goes unresponsive is simply a load issue. Have a little
more patience. Even with bad memory under it, linux / unix will usually
come back from the brink once the load goes away.

You need to make sure logging is enabled on postgresql and then you can
look at the logs for clues as to why the backends are crashing.


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[scott.marlowe]

Re: postgresql + apache under heavy load

On Wed, 21 Jan 2004, Richard Huxton wrote:
[color=blue]
> [I noticed you were running X and mozilla (on top of gnome?). If you don't
> need them, close them - that can free up to 64MB, depending on what you're
> running][/color]

Note that if you've got a 64 Meg memory video card, and X uses 4 megs of
system ram, it will show, in linux, as using 68 Megs of ram. Turning off
X, however, will only free up the 4 megs of system ram, not the 64 on the
video card. so, it's not uncommon for folks to see a modern video card in
their system, look at top, and go "geeze, X is a total memory hog" when in
fact it's just that linux / top count the video memory as part of the
memory allocated to X.

That said, I'd at least run a less heavyweight window manager like
afterstep or twm, not gnome or kde on a box like that one.
[color=blue]
> I don't think you've got a RAM shortage, I think your settings are too small
> and you're running out of I/O bandwidth. If you run "vmstat 5", what does it
> show - you're interested in the i/o section: blocks in (bi) and out (bo) as
> well as memory.[/color]

Also, look at si/so (swap in and out) to monitor swap activity. If those
numbers are low, then swapping isn't an issue...



---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend