Thank you very much Michele for your answer.
I understand that assigning different priorities to each web app is a
complex problem. I mean, it's complex in the sense that it involves
many different areas. But I think that with the information I have and
the configuration variables I know, I
I've made this change to one of the apps. I'll be testing with other
apps in the next days. To get it running I had to import fcgi_fork
from flup.server instead of simple fcgi.
I know this subject is way away from this group, but I'm tempted to
ask, given the quality of the info I've received
2014-12-03 14:16 GMT-03:00 Michele Comitini michele.comit...@gmail.com:
why not flup?
- not event based. Event based servers are usually more responsive under
load.
- seems pretty unmantained.
- misses some tuning options.
I see. I've read a little about gevent and I understand that it
Actually I was referring to max-procs parameter of the fastcgi server that
is setup in lighttpd virtual host configuration. I don't know if you mean
that. In my virtual host configuration, I setup the fastcgi server like
this:
fastcgi.server = (
.fcgi = (localhost = (
why not flup?
- not event based. Event based servers are usually more responsive under
load.
- seems pretty unmantained.
- misses some tuning options.
max-procs in lighttpd configuration:
- leave it to 1
- work with the following options in your script:
WSGIServer(application, minSpare=1,
Everything ok with your plan. One note, instead of playing with the
max-procs in lighttpd you can use the fastcgi server parameters. btw don't
use flup use this:
https://github.com/momyc/gevent-fastcgi
and arrange the num_workers parameter.
to do that differently for each application may end up
Sorry about the delay. I recently installed pgbouncer. I let postgresql
max_connection set to 80, and configure pgbouncer with a max_client_conn of
1000 and a default_pool_size of 20.
Now when I check pg_stat_activity I can see different amounts of idle
connections per app, more accordingly with
@lisandro: michele is right.. the pool_size parameter calculation are
accurate only if there's one process per app. web2py can't coordinate pools
among different processes...
also, max_client_conn is exactly the maximum number of connection the
pgbouncer process will allow coming in. Once over
What you have here is lighttpd starting 1 forking flup server. The
important part is this:
from flup.server.fcgi_fork import WSGIServer
With that you have a python interpreter for each request, up to a maximum.
The default is 5 spare children, the default maximum is 50.
Under lighttpd is also
Thank you very much Niphlod and Michele for your help! Now I have a more
clear understanding of all this. I understand now why I was seeing 5
fastcgi processes regardless of the max-procs configuration (that was
because I was using fcgi_fork, and I was actually seeing one process and
its 5
did you restart the webserver ? I don't think that changing pool_size at
runtime when connections are still open will make the number of active
connection dropped.
On Friday, November 28, 2014 8:48:07 PM UTC+1, Lisandro wrote:
Mmm... I see. That was my understanding in the first place.
At
Yes in deed. I've restarted the webserver and the database server.
Recently I've tried setting pool_size to 1 for every app, that is, for
every website. Restarted postgresql and webserver (lighttpd). And then I
used this SQL statement to check the total count of connections for every
database (or
pool_size==number of threads in a web2py process.
I suggest to work around the problem by setting the number of threads to 1
in you flup server. I.e. no threading.
You should also see smoother performance across applications on higher
loads.
2014-11-30 15:51 GMT+01:00 Lisandro Rostagno
p.s. by no threading I mean to use processes in place of threads. The
number of processes is something you must tune based on server resources,
2xn where n is the number of cores is a safe choice.
2014-11-30 20:04 GMT+01:00 Michele Comitini michele.comit...@gmail.com:
pool_size==number of
I go back to this thread because today I ran with the same problem:
postgresql reaching max_connection limits and, therefor, some of my
websites throwing intermitent HTTP 500 errors (because web2py couldn't
connect to the database).
To remind, we are talking of a VPS with multiple instances of
On Friday, November 28, 2014 3:31:02 PM UTC+1, Lisandro wrote:
I go back to this thread because today I ran with the same problem:
postgresql reaching max_connection limits and, therefor, some of my
websites throwing intermitent HTTP 500 errors (because web2py couldn't
connect to the
Mmm... I see. That was my understanding in the first place.
At that time I did the maths, I had 10 apps, each one using a
pool_size of 3. In postgresql.conf max_connections was set to 80.
However this morning, with those numbers, almost every of my websites
was throwing intermitent HTTP 500
theoretically a db = DAL(, pool_size=5) will create AT MOST 5
connections to that db. you have 20, so any app's instance will create AT
MOST 20 connections to the db. if you postgres accepts AT MOST 50
connections, you'll reach the top at 2 apps and a half. As for the ram
consumed by
Thanks, now I understand, the error was probably caused by a wrong
configuration, because I had almost 10 websites connecting with
pool_size=20, and the postgresql server was limited to 50 max_connections.
Now I changed the values and it's working better.
In addition, I've been reading a lot
19 matches
Mail list logo
