Re: postgresql +AMD64 +big address spaces - does it work? - Mailing list pgsql-general
From | Andy B |
---|---|
Subject | Re: postgresql +AMD64 +big address spaces - does it work? |
Date | |
Msg-id | S_bFc.6246$HQ1.1238@fe2.news.blueyonder.co.uk Whole thread Raw |
In response to | Re: postgresql +AMD64 +big address spaces - does it work? ("Glen Parker" <glenebob@nwlink.com>) |
List | pgsql-general |
Hello again and thanks to everyone for the replies so far. Tom, and all, I hear what you are all saying, and furthermore, in cases where the amount of RAM is much smaller than the database size, I agree totally. However, I'm *only* talking about a particular scenario which, till now, has really only been true of small databases, and that is: -------------------------------- RAM - (total size of database) = (easily enough RAM for everything else to run smoothly on the server). -------------------------------- I get the feeling that, that regardless 64bit support or not, that the *concept* of a database which just happens to all easily fit within RAM isn't one that gets the thumbs down... ...and I think I must be missing something! If you bear with me, could I just give you a better idea of where I'm coming from, because I think I may have missed an important concept, or might be able to sway you. (I don't mind which way this goes, other than my server dreams will be in tatters if you're right and I'm confused, so be gentle with me!) Before I start, just to repeat that that though I have only been using postgresql for 18 months and haven't run a huge database before, I do have a large amount of experience of designing memory intensive multi-threaded real time applications running in a unix virtual memory environment (specifically SGI IRIX boxes), and am very comfortable with the postrgresql implementation model. (and I did choose it over MySQL, so I am a fan.) Ok! --------------------------- Where I'm coming from! --------------------------- I am developing a postgresql based national website, which hopefully will have a million or two users if successful (though hopefully not all at once :) ) The details aren't important, other than to say that the functionality I'm planning is quite advanced - it's more of a web application than website as such, and the database is going to get an absolute hammering. Most importantly, a large percentage of the data within the database is going to be 'active' (i.e. the target of queries) on a minute by minute basis. Luckily for me, it isn't due to go live just yet :) There is now 'proper' 64 bit support in Linux for both Intel and AMD and we've already seen a few linux boxes with half a terabyte of RAM - shareable as a single address space. (e.g. boxes like the Altix 3000 from SGI) Even commodity server boxes (such as the HP DL585) now provide the environment for multiple threads to share a single huge address space backed up by up to 64GB of RAM, accessible by 4 CPUs. I'm not more up to speed on the hardware side, but this is only going one way: up! So, with this new hardware and 64 bit OSs, it is theoretically possible to dramatically reduce the IO bottlenecks on a database server by simply sticking in enough RAM so that the database ends up in RAM, leaving most of the IO being 'O' for syncing updates. We're talking about High Performance Database Surely this is a very desirable setup for someone like me? ____ Here's how it could work: 1. The postgresql postmaster (is that right?) - the process responsible for setting up the shared buffer cache - does what it normally does, except that it works with 64 bit addressing so your cache can be 40MB, or 200GB. (CPU limited to 64GB currently in most 64bit processor systems but this will change) 2. You setup the buffer cache size so that it could easily hold *the entire database*. (Or the active part... the decision of how big is subject to all the current guidelines. The only difference is that there is no 2GB limit). e.g. on my 64GB system, my entire database is 16GB and I instruct postgresql to setup a 20GB shared buffer cache, in order to allow for headroom for updates. 3. At the postgresql level, database pages ('buffers?') get cached, and stay in the buffer cache, because there is enough space for everything to reside in the postgresql cache and more. 4. Additionally, at the virtual memory level, Linux isn't going to kick pages of this huge shared buffer cache out to disk, because there's plenty of RAM kicking around for everything else, and in fact, the target for such a machine is for it to be running at close to zero swap activity. We're talking about a high performance system after all, and swap activity is the last thing you want in a high performance setup. Note that Linux is still managing *all the memory*. I'm not interfering at all with virtual memory. (Though IRIX's mpin() is very handy... I must find out if Linux has a similar call) 5. Assuming your database *does* easily fit in the shared buffer cache, queries will run like the wind, limited only by CPU availability and the performance of the front end web servers + connections to deliver queries and accept the results. 6. You get more bang for your buck, especially in systems with a heavy load of concurrent postgresql backend activity, which would normally put enormous strain on the IO system. 7. An extra benefit is that the database application developer can contemplate query plans which, under the small cache, big database scenario are just not sensible in a high load environment. (Can you tell that I've already done this?!) ------------------------------------------------- Anyway - current implementation aside, what theoretically is stopping you all from jumping with joy at the prospect of running nationwide databases from RAM? Thanks for your input so far, and if you think I should move this thread elsewhere, I'd be happy to. I'd also be interested in helping with making the changes to allow the shared buffer cache to be 64 bit friendly, though I've never helped on an open source project, and my previous mistakes have only affected hundreds of people, not millions ;) Regards, Andy ------------------------------------------------- > 3. A large fixed-size shared-buffer arena is the worst of all possible > worlds in terms of dynamic memory management. The real-world situation > is that RAM has to be shared among PG shared buffers, private memory of > PG backend processes, and (usually) workspace of other non-Postgres > processes that are running on the server machine. The kernel is in a > far better position than we are to evaluate these competing demands and > make the right adjustments to changing situations. The kernel can > easily drop cached disk pages from its buffers to allocate more RAM to > process workspace, or the reverse when process demands drop; but we > can't change the size of the shared-buffer arena on the fly. > > Bottom line: let the kernel manage as much memory as possible.
pgsql-general by date: