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 <rostagnolisan...@gmail.com>: > 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 what it is the same, for every app, because every app has its > own database): > > select datname, count(*) from pg_stat_activity group by datname order by > datname; > > Just to remind, I have around 13 apps running, that is, 13 websites, 13 > databases. > With this new configuration of every app using a pool size of 1, I > restarted the database server and the webserver, and then I ran the > previous SQL statement to see the total connections for every app, and I > see 5 idle connections for every app, that is, for every website that has > some visitors browsing the site. > A couple of the websites almost never have visitors, so, for those > websites, there were no idle connections. Then I go to the homepage of > those websites, rechecked connections, and there I see 5 idle connections > for those websites. > > I already checked and re-checked the code of my app to be shure that I'm > setting "pool_size" parameter correctly. > > > In the other hand, I've been testing pgbouncer on localhost, reading about > it, and I'll be setting it for production. For what I've read, > independently of the postgresql max connections, I can set pgbouncer to a > max_client_conn of 2000 (for example) with a default_pool_size of 20. Then > all the apps connect to pgbouncer, and pgbouncer will multiplex connections > to postgres. However I don't want to mix things in this post, regardless of > pgbouncer, I would like to understand why I can't get to work web2py's > pooling mechanism. > > I'm really grateful for your help! I'll continue trying to figure it out. > Any comment or suggestion will be appreciated. Thanks! > > > 2014-11-30 9:48 GMT-03:00 Niphlod <niph...@gmail.com>: > >> 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 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 errors, and the error tickets were >>> all the same: FATAL: remaining connection slots are reserved for >>> non-replication superuser connections. >>> >>> Right now, I have almost 13 websites, all of them with pool_size in 3, >>> and max_connections in 80. >>> However, if I check the table "pg_stat_activity" I can see 65 >>> connections, and I can see there is 5 connections per app. >>> >>> I've tried even setting pool_size to 1 for one of the apps, restarted >>> database server and webserver, but again I check pg_stat_activity and >>> I see 5 connections for that app. ¿Am I missing something too ovbious? >>> >>> >>> 2014-11-28 14:25 GMT-03:00 Niphlod <nip...@gmail.com>: >>> > >>> > >>> > 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 >>> >> database). >>> >> >>> >> To remind, we are talking of a VPS with multiple instances of web2py >>> >> running, all of them serving the same web2py app, each one connecting >>> to a >>> >> different postgresql database (however the database structure is the >>> same >>> >> accross all the databases). Each web2py instance is served by a >>> lighttpd >>> >> virtual host through fastcgi. Each virtual host (that is, each web2py >>> >> instance) receives a different volume of traffic (that is obvious, >>> they are >>> >> different websites with different public). >>> >> >>> >> The original problem (the one that caused I post this question in the >>> >> first place) was that the postgresql database server was reaching the >>> >> "max_connections" limit and, in consecuence, some of the websites >>> were >>> >> throwing intermitent HTTP 500 errors (web2py couldn't connect to >>> database). >>> >> >>> >> Then, the user oriented me with "pool_size" parameter of DAL >>> constructor. >>> >> Thanks again! >>> >> I've been reading the web2py documentation about pooling [1] and I >>> notice >>> >> that it says that "When the next http request arrives, web2py tries >>> to >>> >> recycle a connection from the pool and use that for the new >>> transaction. If >>> >> there are no available connections in the pool, a new connection is >>> >> established". >>> >> So, if I didn't get it wrong, I deduce that with web2py's pooling >>> >> mechanism I can't overcome the "max_connections" postgresql limit. >>> That is >>> >> because, no matter the size of the pool, if the pool is full and the >>> website >>> >> is receiving a lot of requests, new connetions will be created, and >>> >> eventually the database server will reach the "max_conectios" limit. >>> > >>> > >>> > no, you got it wrong again. pool_size=5 will create AT MOST 5 >>> connections . >>> > if a 6th is needed, users will wait for a connection to be freed. >>> > if your postgresql accept at most 50 connections, do the math. >>> > Every db = DAL(, pool_size=5) lying around will create AT MOST 5 >>> > connections, and that means you can host 10 apps. >>> > If you need 50 apps, set pool_size=1 and let users wait, or set >>> > max_connections in postgres to a higher value. >>> > >>> > -- >>> > Resources: >>> > - http://web2py.com >>> > - http://web2py.com/book (Documentation) >>> > - http://github.com/web2py/web2py (Source code) >>> > - https://code.google.com/p/web2py/issues/list (Report Issues) >>> > --- >>> > You received this message because you are subscribed to a topic in the >>> > Google Groups "web2py-users" group. >>> > To unsubscribe from this topic, visit >>> > https://groups.google.com/d/topic/web2py/5RTO_RqCsus/unsubscribe. >>> > To unsubscribe from this group and all its topics, send an email to >>> > web2py+un...@googlegroups.com. >>> > For more options, visit https://groups.google.com/d/optout. >>> >> -- >> Resources: >> - http://web2py.com >> - http://web2py.com/book (Documentation) >> - http://github.com/web2py/web2py (Source code) >> - https://code.google.com/p/web2py/issues/list (Report Issues) >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "web2py-users" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/web2py/5RTO_RqCsus/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> web2py+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > Resources: > - http://web2py.com > - http://web2py.com/book (Documentation) > - http://github.com/web2py/web2py (Source code) > - https://code.google.com/p/web2py/issues/list (Report Issues) > --- > You received this message because you are subscribed to the Google Groups > "web2py-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to web2py+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.