I keep getting the error:
FATAL: sorry, too many clients
already
I never had the problem before, but I recently upgraded to version 9.03 and also OS X lion preview release 2. It doesn't seem to matter how idle the processes are, they never die. I have to restart postgres every half hour or so. I'm using postgres via Rails 3 and Navicat, never had a problem with either before now and stopping both clients does nothing to solve the problem.
Any ideas or settings I'm missing? Not sure what settings I should display here for my setup, but everything should be default. Installed postgres using HOMEBREW.
Most likely go into postgresql.conf and edit max_connections and post the existing value.To see how many connections you have an what they are doing select from pg_stat_activity. Maybe your bleeding connections?
See this link
http://www.postgresql.org/docs/9.0/interactive/runtime-config-connection.html
Related
I have a MAMP setup which hosts a number of local servers. It seems capable of running them just fine but it seems almost daily the app itself is marked as not responding by the OS (macOS 10.15.2) and as such refuses to close the app at the end of the day. This becomes quite irritating as it happens constantly. I imagine I've changed something, perhaps related to RAM so it thinks it can use more than it can. Searching for "MAMP Not Responding" on google doesn't exactly show what I'm looking for though.
Any help diagnosing MAMP itself rather than the servers freezing up?
This seems to help me out.
Quit MAMP if open
Navigate to /MAMP/tmp/mysql
Rename mysql.sock.lock
Restart MAMP
I got this from MrSandman98765 answer here https://stackoverflow.com/a/61063332/2314252
I’ve partially fixed it tweaking MySQL settings File > Edit templates > MySQL (my.cfn) > 5.7.26
In my case, having 64 GB of Ram, I’ve heavily increased everything related to Ram and buffer size.
I saw “partially” because sometimes, working on large Magento sites I get again the issue. I think it could be better investigated with MySQL tuning tools.
Where does OSX Server store integration bots? Or is it my local Xcode who stores them? Server screwed my setup again, but this time I'm no longer able to see my bots.
Just want to express my deep frustration with Xcode CI:
OSX Server (or whatever it's called) is one of a kind piece of software, giving me incredible headaches lately with its' laginness, bugginess and poor performance. I think over the past week I experienced all possible errors Server has to offer:
"internal error updating bot" (please try again later);
"error reading service configuration" (or similar wording) - requires Xcode reset; continue to occur randomly again and again with no reasons;
"Xcode version is not supported" - only reboot seems to convince server to use Xcode which was already used previously
Randomly, fail integrations because "device is not connected", given that I test desktop application for OSX...
Finally, after yet another episode of screwing my setup, I no longer can see my bots on the server - they vanished. well done Server.
The bots and integrations are stored on the server.
The directory should look something like /Users/<xcode_server_tester_user_name>/Library/Caches/XCSBuilder/Bots
(OSX-Server 5.3 (16S4123), XCode 8.3.2 (8E2002))
I hate to say this but I found restarting the machine is a good way to resolve frustration No. 1 and 2.
device is not connected error often happens right after OS, OSX-Server or XCode is upgraded.
Usually reselecting devices from the XCode UI works for me.
Although sometimes it may require repeating multiple times and waiting for a long time for the device list to load.
On your OSX Server machine, deleting the simulator and re-adding it via Xcode->Devices sometimes helps too.
Another way is to delete all simulators from the linked Xcode on OSX Server machine and only keep the ones you want to test your project on. Config the bot to use All iOS Devices and Simulators.
Even though Xcode Server now runs as a specific user, the configuration files are kept in /Library/Developer/XcodeServer. You can also hit the Xcode Server API to get information about your bots.
In a Couchbase db.
I don't know how to access the contents though.
Enter this in Safari on your server
http://localhost:10355/_utils/
I've got a strange problem. My xampp seems to run just fine, at least the control panel says so. A couple of months back I was able to use xampp properly as well. But now, if I try to load anything in htdocs the browser tells me that the website is not available.
The only things that have changed since I used xampp successfully:
I've briefly installed wampp, but decided to deinstall it again. As far as I can tell, I have removed snd deinstalled everything succesfully.
And, I'm using an other internet connection. Is there a possibility that the firewall of the modem messes xampp up?
Any ideas are greatly appreciated.
PS: I did not post the config files of xampp, because I haven't changed them since everything worked properly, so I hardly think that it is relevant.
Considering your problem and the information I have gathered from you.
The best solution is:
Make a backup of all your files in htdocs.Uninstall Xampp completely.Download and install once again.
Note:
Latest Xampp versions comes with MariaDB unlike mysql.Now some versions of MariaDB is unstable.This would create problems when you are actually working with database and sql queries.
Either download and install Xampp which comes with Mysql or find a version of xampp which comes with a stable version of MariaDB and the latest PhpMyAdmin version.
Reinstalling solves issues like this most of the time.There may have been some kind of server conflict when you installed WAMP.So an all new installation is best.
You could also try clearing the browser history and cookie as an alternative.
I just installed the most recent version of pgAdmin III (1.20 installed on Windows 8). I haven't used this software before, so I may be overlooking something simple.
I'm able to connect ok (at least to heroku, with my DB name in the 'maintenance db' field). Additionally, when I select the server in pgAdmin, it shows my DB name listed on the right hand side, along with the rest of my credentials.
That said, it shows that there 0 databases for my server. Should I click 'databases(0)', I get this error:
Error: Column datconfig does not exist.
In my Googling, it seems that this error typically happens when users are running an older version of pgAdmin. I'm running the most recent, though .
Any ideas?
It seems to be a problem with Windows 8. I just installed the Mac client on a laptop, and everything went fine.
I'm running GitLab on Centos 7. GitLab was installed using YUM.
The initial gitlab version was 1.7.12.2.
The problem is with the WEB interface of the GitLab installation.
I'm trying to get the browser session to timeout so that it forces you to login again after a certain period.
I have noticed that a change request was implemented, so I upgraded from 1.7.12.2 to 1.7.14.3 using yum update.
Under the Administration setting (in Web UI) I can now see the extra parameter where you can set the timeout. I have now changed it tt two minutes(for testing so I don't have to wait so long), but it simply does not work.
I have also tried something bigger - 5 minutes - not working.
I have also done a gitlab-ctl stop, then gitlab-ctl reconfigure and then gitlab-ctl start. The new value still shows, but the browser session still does not timeout.
I have also created a new CentOS 7 installation from scratch, installed GitLab via yum with version 1.7.14.3 - this is as-is from the installation - so no previous upgrade problems or similar problems.
I have tried different browsers (FireFox and Chrome) on Windows 7/8, Even Mac. I have also cleared the browser cookies to make sure it gets the latest after the updates. No change in behavior.
Changing the time still has no effect....
Anybody with an idea what I'm doing wrong?
The truth is I think there is a bug in the current session expiration mechanism. See https://gitlab.com/gitlab-org/gitlab-ce/issues/2129
Short answer, your not crazy ;) Hopefully we can resolve this issue shortly.