We used to get this error a while back, so we put more RAM into our DB server, but sadly just got the error again:
Fatal error: Uncaught exception 'Exception' with message 'Could not create database connection: DBError!:SQLSTATE[08006] [7] FATAL: connection limit exceeded for non-superusers' in /home/websites/mysource_matrix/core/include/mysource.inc:3267
Stack trace:
#0 /home/websites/mysource_matrix/core/include/mysource.inc(220): MySource->changeDatabaseConnection('db')
#1 /home/websites/mysource_matrix/core/include/init.inc(243): MySource->init()
#2 /home/websites/mysource_matrix/core/cron/run.php(36): require_once('/home/websites/...')
#3 {main}
thrown in /home/websites/mysource_matrix/core/include/mysource.inc on line 3267
Currently, in our postgres config file, we have max_connections = 70. This seems super low. Should I bump this up? If so, to what number? We currently have 3369928kB of RAM on the server.
[quote]
Currently, in our postgres config file, we have max_connections = 70. This seems super low. Should I bump this up? If so, to what number? We currently have 3369928kB of RAM on the server.
[/quote]
70 will probaly allow for about 24 concurrent page generations (most pages initiate 3 connections to the DB: a db, db2 and db3 connection), which is actually quite a bit of work to be doing all at once (assuming you have a fairly normal number of CPU cores).
From memory you mentioned recently that there's no Proxy cache in front?
I would seriously be looking in to implementing that now to remove a lot of the load from repeat views.
[quote]
70 will probaly allow for about 24 concurrent page generations (most pages initiate 3 connections to the DB: a db, db2 and db3 connection), which is actually quite a bit of work to be doing all at once (assuming you have a fairly normal number of CPU cores).
From memory you mentioned recently that there's no Proxy cache in front?
I would seriously be looking in to implementing that now to remove a lot of the load from repeat views.
[/quote]
Correct, we don't have a proxy set up.
Is that something that is difficult to set up? And does that hardware have to be powerful?
[quote]
If you contact support directly they can probably email you our template squid.conf file (I'm not sure if we can publish it on the forum or not).
Thanks. So, is all that it takes to get it up and running, is install it on our apache server, add the config, and it is up and running? Or is it more complicated than that?
[quote]
Thanks. So, is all that it takes to get it up and running, is install it on our apache server, add the config, and it is up and running? Or is it more complicated than that?
[/quote]
Very slightly more complicated.
Apache will need to be listening on 127.0.0.1:80 and Squid will need to listen on <public ips>:80.
Then tell Squid to find Apache on the local host ip:
As long as you only have one Matrix instance this should pretty much always work. It gets more complicated if you have multiple instances on one IP because Squid has to decide which parent server to use based on the incomming Host header.
This can be done with fairly minimal down time, even without a UAT environment (but if you have UAT that'd be a REALLY good place to try it out).
Install Squid and configure it to listen on a non-standard port (e.g. 8080). Set the <public ip> and 8080 as your browser proxy and confirm it's ok. Once you are comfortable the site renders ok through the Squid instance, adjust Squid to listen on port 80 on the public ips only and Apache to listen on 127.0.0.1 only, then do a restart on both daemons.
Make sure to backup your Apache config just in case.
[u]If you get everything right[/u], down time should be less than 30 seconds in the worst case.
Your backout plan should be:
* shutdown squid
* restore apache config
* restart apache
p.s. once you have Squid working, make sure to set up a clear squid cache trigger (and confirm it actually works).
