-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christian Boos wrote: > Russ Brown wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Not long back I switched from the prefork apache MPM to the worker one, >> at the suggestion of coderanger (due to better memory efficiency etc). I >> set it up to run on two processes each spawning a number of threads. >> >> Yesterday we encountered Trac being unable to connect to the database >> (Postgres 8.2, Trac 0.11 RC2), and when investigating it noticed that >> trac only had two connections open (two large requests were being >> processed at this time leading to the site being unavailable to other >> requests). >> > > This problem won't be solved by the new pool code, which doesn't prevent > long running requests to block others. > In some cases, we hold a db connection for too long with no good reason, > and this is likely the problem you had here. > > For example, I have a very big test changeset and while it's being > loaded, I can't make other requests which want to save something in the > db (even session related data, like for login/logout, timeline views, > query updates). This is not optimal, as there's no reason a db > connection should be kept alive during that processing. I've seen this > with SQLite and I've not yet tried to reproduce this with PostgreSQL. >
SQLite does database-level locking though doesn't it? So however you do it your database requests are always going to be serialised system-wide. Provided enough connections are available, Postgres should be able to handle as many requests as you like at the same time (with the constraints of hardware etc of course) provided that connections are available. When using the postgres backend, viewing a large changeset should have no effect whatsoever on users reading (and probably those writing too), again provided that there are connections available. >> I asked about this in IRC and was told that there were issues with the >> pooling in RC2 and that I should upgrade to 0.11. coderanger also >> mentioned the TRAC_DB_POOL_SIZE environment variable which could be used >> to control the connection pooling. >> >> I did that, but Trac still only held two connections open. I viewed >> trac/db/pool.py and saw no mention of TRAC_DB_POOL_SIZE. Looking at the >> file on trunk (of t.e.o) I do see it there, which suggests that >> TRAC_DB_POOL_SIZE was actually added post 0.11. I also don't see it in >> that file on the 0.11-stable branch. >> >> Is there any estimate as to when this change might be released (e.g. >> 0.11.1)? >> > > I didn't have problems with the new pool so far, neither did we receive > any bug report from trunk users, so I think it's safe to backport it to > 0.11-stable in the coming days. > That would be great! > -- Christian > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIZV0yhXYlbEtYt2wRAoWyAJ9e0ZqHmobp4ZtodVm+ZBIOXWNORgCgsGRl S6P2VqS+Nbe+Hy9VfiEvJE4= =p+19 -----END PGP SIGNATURE----- --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
