Re: Caching by Postgres - Mailing list pgsql-performance
From | mark@mark.mielke.cc |
---|---|
Subject | Re: Caching by Postgres |
Date | |
Msg-id | 20050824173055.GA11788@mark.mielke.cc Whole thread Raw |
In response to | Re: Caching by Postgres (Donald Courtney <Donald.Courtney@Sun.COM>) |
Responses |
Re: Caching by Postgres
Re: Caching by Postgres |
List | pgsql-performance |
On Wed, Aug 24, 2005 at 09:21:12AM -0400, Donald Courtney wrote: > I built postgreSQL 8.1 64K bit on solaris 10 a few months ago > and side by side with the 32 bit postgreSQL build saw no improvement. > In fact the 64 bit result was slightly lower. I've had this sort of argument with a friend of mine who works at a retail computer sales company who always tries to pitch 64-bit platforms to me (I don't have one yet). There are a few issues in here that are hard to properly detach to allow for a fair comparison. The first, to always remember - is that the move from 64-bits to 32-bits doesn't come for free. In a real 64-bit system with a 64-bit operating system, and 64-bit applications, pointers are now double their 32-bit size. This means more bytes to copy around memory, and in an extreme case, has the potential to approach halfing both the memory latency to access many such pointers from RAM, and half the effective amount of RAM. In real world cases, not everything is a pointer, so this sort of performance degradation is doubtful - but it is something to keep in mind. In response to this, it appears that, at least on the Intel/AMD side of things, they've increased the bandwidth on the motherboard, and allowed for faster memory to be connected to the motherboard. They've increased the complexity of the chip, to allow 64-bit register operations to be equivalent in speed to 32-bit register operations. I have no idea what else they've done... :-) So, it may be difficult to properly compare a 32-bit system to a 64-bit system. Even if the Ghz on the chip appears equal, it isn't the same chip, and unless it is the exact same make, product and version of the motherboard, it may not be a fair compairson. Turning support for 32-bit on or off, and using a kernel that is only 32-bit may give good comparisons - but with the above explanation, I would expect the 32-bit application + kernel to out-perform the 64-bit application. So then we move on to what 64-bit is really useful for. Obviously, there is the arithmetic. If you were previously doing 64-bit arithmetic through software, you will notice an immediate speed improvement when doing it through hardware instead. If you have a program that is scanning memory in any way, it may benefit from 64-bit instructions (for example - copying data 64-bit words at a time instead of 32-bit words at a time). PostgreSQL might benefit slightly from either of these, slightly balancing the performance degradation of using more memory to store the pointers, and more memory bandwidth the access the pointers. The real benefit of 64-bit is address space. From the kernel perspective, it means that more programs, or bigger programs can run at once. From the application perspective, it means your application can use more than 32-bits of address space. For programs that make extensive use of mmap(), this can be a necessity. They are mapping very large files into their own address space. This isn't a performance boost, as much as it is a 'you can't do it', if the files mmap()'ed at the same time, will not fit within 32-bits of address space. This also becomes, potentially, a performance degradation, as the system is now having to manage applications that have very large page tables. Page faults may become expensive. PostgreSQL uses read(), instead of mmap(), and uses <2 Gbyte files. PostgreSQL doesn't require the additional address space for normal operation. If, however, you happen to have a very large amount of physical memory - more memory than is supported by a 32-bit system, but is supported by your 64-bit system, then the operating system should be able to use this additional physical memory to cache file system data pages, which will benefit PostgreSQL if used with tables that are larger than the memory supported by your 32-bit system, and which have queries which require more pages than the memory supported by your 32-bit system to be frequently accessed. If you have a huge database, with many clients accessing the data, this would be a definate yes. With anything less, it is a maybe, or a probably not. I've been looking at switching to 64-bit, mostly to benefit from the better motherboard bandwidth, and just to play around. I'm not expecting to require the 64-bit instructions. Hope this helps, mark -- mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/
pgsql-performance by date: