Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

I have two identical servers (in terms of hardware), they are both standard installations of windows server 2008 r2, with minimal software installed (basically my code and required stuff like jvm etc).

On the one server, I am running sql server 2005, on the second server postgresql 9.1. The difference in performance b/n these 2 servers is staggering, it's so bad on postgresql that I'm regretting my initial "let's use postgresql instead of paying for the sql server license" speech to my boss. We're talking differences of 30 seconds vs 15 mins for the same command, and it's not just this one command, it's any query or command I throw at it. They both have pretty much the same data (records were inserted in different order), and both databases have the exact same structure / indexes etc.

But I'm hoping it's just a matter of performance tuning. The thing is, sql server is pretty much using all 32 gigs of ram on the server, whereas postgresl is using nothing, definitely less than a gig though I haven't actually figured it out in fine detail.

How do I get postgresql to use 20+ gigs of ram? These servers were built specifically for this database stuff, so any ram not in use by the database and supporting processes is wasted in my opinion.

share|improve this question

migrated from stackoverflow.com May 29 '12 at 6:44

This question came from our site for professional and enthusiast programmers.

1  
Did you change anything to the initial tuning? Step1: SET effective_cache_size=18G; (the default setting is extremely low) BTW: assuming this is a 64 bit machine (no PTE) –  wildplasser May 28 '12 at 21:12
1  
You're really not giving us enough to help a lot. Other than "It's slow" we don't know much about your dataset, how you're accessing it, what types of queries are generally running slowly, what you've already done to tune (and possibly mis-tune) your server. Heck, on a linux machine with lots of cores and memory channels, you can get crappy performance long before you've installed postgresql. Are you CPU or IO bound? What non-default settings do you have already? What kinds of queries are slow? –  Scott Marlowe May 29 '12 at 4:53
2  
Postgres doesn't "use ram" the way you speak of it. It relies on the OS file system page cache for the bulk of its caching, so when you watch ram usage on a system running postgres you typically see many GBs in use by OS buffers/cache, and individual postgres backend processes using only a few to a few tens of MBs each. –  dbenhur Jun 1 '12 at 22:34

4 Answers 4

There are many tweakable constants, initialised via postgres.conf. The most important ones are:

  • max_connections: the number of concurrent sessions
  • work_mem : the maximal amount of memory to be used for intermediate results such as hash tables
  • shared_buffers the amount of memory dedicated to 'pinned' buffer space.
  • effective_cache_size the amount of memory assumed to be used by the OS's LRU buffers.
  • random_page_cost : an estimate for the relative cost of disk seeks.

max_connections should not be set higher than needed, connections cost resources even when idle; in most cases a connection would spend more time waiting inside than waiting outside. (at the price of concurrency) A nice rule-of-thumb formula is "number of spindles+number of processors+X"

Work_mem is tricky: is can be applied to every subquery, so a query with 5 HASHJOINS might cost 5*work_mem. And for worst-case scenarios, you should als think of multiple sessions consuming this amount. (again a reason to keep max_connections low)

Shared_buffers is (IMHO) overrated. Normally it is advised to set it to about 1/4...1/2 of all available "free" memory, but I tend to keep it low, and set effective_cache_size to all available "free" memory.

Random_page_cost is the cost for a seek+read on the disk. It is relative to the "sequential_disk_cost", which is 1. The default (4) for random_page_cost is set too high for modern machines and network storage, normally it can be lowered to between 2 and 1.x.

share|improve this answer
    
Excellent! I never saw the significance of effective_cache_size, always fooled around only with shared_buffers. This really made a huge difference. I run pgtune as well and it recommended 20GB of 96 to be used for shard_buffers, but 64GB for effective_cache_size. Thanks! –  Gunther Jul 26 at 22:28

Consider using pgtune to help you tune the PostgreSQL configuration. From PgFoundry:

pgtune takes the wimpy default postgresql.conf and expands the database server to be as powerful as the hardware it's being deployed on

PostgreSQL's default configuration is very conservative and that tool is meant to help with this exact situation. The documentation is a light read and using the tool is pretty straightforward.

Keep in mind that there's no need to use pgtune's exact suggestions. Playing with its settings and watching the resulting changes to the conf file will give you a better understanding of PostgreSQL's configuration and how to tweak it manually.

share|improve this answer
1  
Last update of pgtune was in 2009, that's 5 years ago and still counting. I am wondering if its still valid for 9.1-9.2-9.3 series. –  sorin Feb 12 at 13:35

If every query or command is running slowly I suspect that:

  • you connect to database for every query you run;
  • you have configured some kind of authentication method, which does not work and it halts your queries until this particular authentication method times out.

Could you please tell us how much time it takes to run a query like select version()? If should be instant (0,16ms on my workstation).

share|improve this answer

If EVERY query is that much slower something is terribly wrong with the server or something. In my experience each db has a few things it's better at than the other, but performance wise pgsql is easily in the same realm as mssql server.

So, what OS are you running pgsql on? What hardware? What settings have you changed already? How big is your dataset? What's an example of a poor query and the output of explain analyze (Run your query like this:

explain analyze select ...rest of query here... ;

Post the output to http://explain.depesz.com/ and post the link here.

share|improve this answer
    
Yes, every query / command is running slowly, and yes "something" is terribly wrong hence my question. The issue is that mssql is making full use of the available ram on the server (so heavy caching) whereas psql is not. I appreciate comments and advice, but you must have missed the bulk of my question and the subject line itself... I just want to know how to get psql to make use of the available ram; currently trying some suggestions listed by the others... –  user85116 May 29 '12 at 20:39
    
Using your RAM is NOT the problem. Postgresql relies on the OS to do most of the caching. So, it doesn't NEED to use all the RAM. Again, you missed the bulk of my point. You're giving us precious little to help you with. I drive 5000 TPS postgresql clusters for a living. You can take my advice, or keep thinking you know how pgsql works and argue. –  Scott Marlowe May 29 '12 at 23:00

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.