views:

159

answers:

4

I was writing a code to find the speed of my database using a Perl script.

My intention was to make a 4,000 database connection after each fork (which would act as a 4,000 different clients) and sleep, and I issue the update command when I get the signal but the system itself becomes very slow and almost hangs for making the connections itself and even I couldn't send the signal using my terminal.

I am using DBI module, I have 4GB RAM in my system where Postgres 8.3 is running in a different machine.

+5  A: 

I'm not entirely clear on whether you're saying you wanted to a) Open 4,000 connections, fork, open 4,000 more connections, etc. or b) Fork 4,000 times and open one connection from each process, but 4,000 database connections or 4,000 processes is some pretty serious resource consumption either way. I'm not at all surprised that it's slowing your system to a crawl - I would expect that to be the end result regardless of the language used.

What are you actually attempting to achieve by creating all of these processes and/or connections? There's probably a better way to do it that won't be quite so resource-intensive.

Dave Sherohman
I think he's doing load testing. If you need to test 4000 connections, how else would you do it?
Gabe
Use multiple machines. 4,000 processes is a lot especially if they are all running a dynamic virtual machine like Perl.
mpeters
So should he use 1000 machines or just go out and buy 4000? I get your drift though maybe if you can split the connection between 2,4, 6, 8 ... machines it will help keep the single client machine from getting nailed, but the overhead is not really on the client here it's on the db server. Even if you have 4000 separate machines each with 1 connection the db server still can't handle it.
StarShip3000
Even if he is doing load testing, a) 4k procs/connections will impose a heavy load on the client, which can be expected to slow it down, and b) there are dedicated load-testing tools which would do the job more efficiently than creating a ton of perl processes.
Dave Sherohman
+4  A: 

I've seen pgpool in use on production systems where the number of postgres connections could not be limited to something reasonable. You may wish to look into using this yourself to mitigate against poor application design by your developers.

Essentially, pgpool acts as a proxy to postgres. It multiplexes queries on lots of connections to a much smaller (and manageable) number to the back-end database.

PP
thanks for pgpool , I have tested with pgbouncer and i did not get the impressive results.
abubacker
+2  A: 

That is relativity speaking a lot of connections to have at once, but not unheard of by any means. How much memory do you have on the database server? Each connection takes resources, if you don't have a database server setup to handle that volume of connections it will be slow no matter what language you use to connect.

A simple analogy would be if you had a Toyota Prius (old days I would had said Ford Pinto) pulling a semi trailer with 80,000 lbs (typical legal weight in a lot of the states) of weight in it. It would burn that little Prius up in a heartbeat like you are seeing. To do it right you need to buy your self a big rig and hook it to that trailer to move that amount of weight.

StarShip3000
Half a million pounds would likely burn up a big rig too (typical legal load is 80,000 lbs - truck and trailer).
StingyJack
Thanks for the info, I updated my answer so no one would try and pull 500,000 lbs with their big rigs.
StarShip3000
+1  A: 

Ignoring the wisdom of doing 4000 connection forks, you should work through your performance issues with something akin to Devel::NYTProf.

I would alternatively setup persistent workers in gearman and do my gearman client requests. Persistence and your scheduled forks on demand.

hpavc