8 HBAs at 200MB/sec would require a pretty significant Storage Processor backend unless cost is not a factor. Once you achieve that, there's a question of sharing/balancing I/O requirements of various other applications/databases on that same shared backend storage... Anjan -----Original Message----- From: Jignesh K. Shah [mailto:J.K.Shah@xxxxxxx] Sent: Monday, December 19, 2005 9:27 AM To: Luke Lonergan Cc: Juan Casero; pgsql-performance@xxxxxxxxxxxxxx Subject: Re: [PERFORM] PostgreSQL and Ultrasparc T1 Sun Fire T2000 has 3 PCI-E and 1PCI-X slot free when shipped. Using dual fiber channel 2G adapters you can get about 200MB x 8 = 1600MB/sec IO bandwidth. Plus when 4G HBAs are supported that will double up. Now I think generally that's good enough for 1TB raw data or 2-3 TB Database size. Of course typically the database size in PostgreSQL space will be in the 100-500GB range so a Sun Fire T2000 can be a good fit with enough area to grow at a very reasonable price. Of course like someone mentioned if all you have is 1 connection using postgresql which cannot spawn helper processes/threads, this will be limited by the single thread performance which is about 1.2Ghz compared on Sun Fire T2000 to AMD64 (Sun Fire X4200) which pretty much has similar IO Bandwidth, same size chassis, but the individual AMD64 cores runs at about 2.4Ghz (I believe) and max you can get is 4 cores but you also have to do a little trade off in terms of power consumption in lei of faster single thread performance. So Choices are available with both architecture. .However if you have a webserver driving a postgreSQL backend, then UltraSPARC T1 might be a better option if you suddenly wants to do 100s of db connections. The SunFire T2000 gives you 8 cores with 32 threads in all running on the system. With PostgreSQL 8.1 fix for SMP Bufferpool performance and with ZFS now available in Solaris Express release, it would be interesting to see how the combination of PostgreSQL 8.1 and ZFS works on Solaris since ZFS is one of the perfect file systems for PostgreSQL where it wants all complexities (like block allocation, fragmentation, etc) to the underlying file systems and not re-implement its own infrastructure. If somebody is already conducting their own tests, do let me know. As soon as I get some free cycles, I want to run ZFS with PostgreSQL using Solaris Express. If you have some preferred workloads do let me know. Regards, Jignesh Luke Lonergan wrote: >Juan, > >On 12/18/05 8:35 AM, "Juan Casero" <caseroj@xxxxxxxxxxx> wrote: > > > >>Can anyone tell me how well PostgreSQL 8.x performs on the new Sun Ultrasparc >>T1 processor and architecture on Solaris 10? I have a custom built retail >>sales reporting that I developed using PostgreSQL 7.48 and PHP on a Fedora >>Core 3 intel box. I want to scale this application upwards to handle a >>database that might grow to a 100 GB. Our company is green mission conscious >>now so I was hoping I could use that to convince management to consider a Sun >>Ultrasparc T1 or T2 system provided that if I can get the best performance >>out of it on PostgreSQL. So will newer versions of PostgreSQL (8.1.x) be >>able to take of advantage of the multiple cores on a T1 or T2? I cannot >>change the database and this will be a hard sell unless I can convince them >>that the performance advantages are too good to pass up. The company is >>moving in the Win32 direction and so I have to provide rock solid reasons for >>why I want to use Solaris Sparc on a T1 or T2 server for this database >>application instead of Windows on SQL Server. >> >> > >The Niagara CPUs are heavily multi-threaded and will require a lot of >parallelism to be exposed to them in order to be effective. > >Until Sun makes niagara-based machines with lots of I/O channels, there >won't be much I/O parallelism available to match the CPU parallelism. > >Bizgres MPP will use the process and I/O parallelism of these big SMP >machines and the version based on Postgres 8.1 will be out in February. > >- Luke > > > >---------------------------(end of broadcast)--------------------------- >TIP 5: don't forget to increase your free space map settings > > ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
