Обсуждение: PostgreSQL and Ultrasparc T1
Hi - 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. Thanks, Juan -------------------------------------------------------
On 12/18/05, Juan Casero <caseroj@comcast.net> 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. I do not know that anyone outside pilot orgs have received their orders for the new T1 machines, so real world experience will not be available yet. The big question is whether or not it manages the processors only for threads (in which case Postgresql won't benefit much) or for processes as well. PostgreSQL takes a "process-parallel" approach to parallelism, not thread-level. There are lost of historical reasons, but, that's just hte way it is for now. Chris -- | Christopher Petrilli | petrilli@gmail.com
From: pgsql-performance-owner@postgresql.org on behalf of Juan Casero
QUOTE:
Hi -
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.
ENDQUOTE:
Well, generally, AMD 64 bit is going to be a better value for your dollar, and run faster than most Sparc based machines.
Also, PostgreSQL is generally faster under either BSD or Linux than under Solaris on the same box. This might or might not hold as you crank up the numbers of CPUs.
PostgreSQL runs one process for connection. So, to use extra CPUs, you really need to have >1 connection running against the database.
Mostly, databases tend to be either I/O bound, until you give them a lot of I/O, then they'll be CPU bound.
After that lots of memory, THEN more CPUs. Two CPUs is always useful, as one can be servicing the OS and another the database. But unless you're gonna have lots of users hooked up, more than 2 to 4 CPUs is usually a waste.
So, I'd recommend a dual core or dual dual core (i.e. 4 cores) AMD64 system with 2 or more gigs ram, and at least a pair of fast drives in a mirror with a hardare RAID controller with battery backed cache. If you'll be trundling through all 100 gigs of your data set regularly, then get all the memory you can put in a machine at a reasonable cost before buying lots of CPUs.
But without knowing what you're gonna be doing we can't really make solid recommendations...
Juan, On 12/18/05 8:35 AM, "Juan Casero" <caseroj@comcast.net> 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
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@comcast.net> 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 > >
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@Sun.COM]
Sent: Monday, December 19, 2005 9:27 AM
To: Luke Lonergan
Cc: Juan Casero; pgsql-performance@postgresql.org
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@comcast.net> 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
Jignesh, On 12/19/05 6:27 AM, "Jignesh K. Shah" <J.K.Shah@Sun.COM> wrote: > 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. The free PCI slots don't indicate the I/O speed of the machine, otherwise I'll just go back 4 years and use a Xeon machine. Can you educate us a bit on the T-2000, like where can we find a technical publication that can answer the following: Are all of the PCI-E and PCI-X independent, mastering channels? Are they connected via a crossbar or is it using the JBus? Is the usable memory bandwidth available to the HBAs and CPU double the 1,600MB/s, or 3,200MB/s? > 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. So - OLTP / webserver, that makes sense. - Luke
Hi Luke, I have gone to the max with 4 fibers on Sun Fire T2000. But I am not sure about the answers that you asked. Let me see ifI can get answers for them. I am going to try to max out the IO on these systems with 8 fibers as soon as I get additionalstorage so stay tuned for that. By the way you don't have to wait for my tests. Just get a trial server and try it on your own. If you don't like it returnit. https://www.sun.com/emrkt/trycoolthreads/contactme.html Check out Jonathan's blog for more details http://blogs.sun.com/jonathan However if you do try it with PostgreSQL, do let me know also with your experience. Regards, Jignesh ----- Original Message ----- From: Luke Lonergan <llonergan@greenplum.com> Date: Monday, December 19, 2005 12:31 pm Subject: Re: [PERFORM] PostgreSQL and Ultrasparc T1 To: Jignesh Shah <J.K.Shah@Sun.COM> Cc: Juan Casero <caseroj@comcast.net>, pgsql-performance@postgresql.org > Jignesh, > > > On 12/19/05 6:27 AM, "Jignesh K. Shah" <J.K.Shah@Sun.COM> wrote: > > > 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. > > The free PCI slots don't indicate the I/O speed of the machine, > otherwiseI'll just go back 4 years and use a Xeon machine. > > Can you educate us a bit on the T-2000, like where can we find a > technicalpublication that can answer the following: > > Are all of the PCI-E and PCI-X independent, mastering channels? > Are they > connected via a crossbar or is it using the JBus? Is the usable > memorybandwidth available to the HBAs and CPU double the 1,600MB/s, > or 3,200MB/s? > > > 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. > > So - OLTP / webserver, that makes sense. > > - Luke > > >
Jignesh, On 12/19/05 11:29 AM, "Jignesh Shah" <J.K.Shah@Sun.COM> wrote: > I have gone to the max with 4 fibers on Sun Fire T2000. But I am not sure > about the answers that you asked. Let me see if I can get answers for them. I > am going to try to max out the IO on these systems with 8 fibers as soon as I > get additional storage so stay tuned for that. Cool - how close did you get to 800MB/s? > By the way you don't have to wait for my tests. Just get a trial server and > try it on your own. If you don't like it return it. > > https://www.sun.com/emrkt/trycoolthreads/contactme.html Done - I'll certainly test Postgres / Bizgres on it - you know me ;-) > However if you do try it with PostgreSQL, do let me know also with your > experience. See above. The Niagara is UltraSparc III compatible - so the GCC compiler should emit good code for it, right? - Luke
Hi Luke,
I got about 720 MB/sec to 730 MB/sec with plain dd tests on my current storage configuration (8 LUNS on 4 fibers)
whichslowed me down (10K rpm 146 GB disks FC) with 4 LUNS going through a longer pass to the disks (via a controller
masterarray to slave JBODs to provide ) .
extended device statistics
r/s w/s Mr/s Mw/s wait actv wsvc_t asvc_t %w %b device
0.8 14.0 0.0 0.0 0.0 0.3 0.0 17.8 0 4 c3t0d0
91.4 0.0 91.4 0.0 0.0 1.0 0.0 10.5 0 96 c0t40d0
96.0 0.0 96.0 0.0 0.0 1.0 0.0 10.0 0 96 c5t40d1
95.8 0.0 95.8 0.0 0.0 1.0 0.0 10.0 0 96 c0t40d1
96.8 0.0 96.8 0.0 0.0 1.0 0.0 9.9 0 96 c5t40d0
84.6 0.0 84.6 0.0 0.0 1.0 0.0 11.4 0 96 c4t46d1
85.6 0.0 85.6 0.0 0.0 1.0 0.0 11.2 0 96 c4t46d0
85.2 0.0 85.2 0.0 0.0 1.0 0.0 11.3 0 96 c2t46d1
85.4 0.0 85.4 0.0 0.0 1.0 0.0 11.3 0 96 c2t46d0
I can probably bump it up a bit with fine storage tuning (LUN) but there is no limitation on the Sun Fire T2000 to
bottleneckon anything plus dd tests are not the best throughput measurement tool.
Yes UltraSPARC T1 supports the SPARC V9 architecture and can support all the SPARC binaries already generated or newly
generatedusing gcc or Sun Studio 11 which is also free.
http://developers.sun.com/prodtech/cc/downloads/sun_studio/
Regards,
Jignesh
----- Original Message -----
From: Luke Lonergan <llonergan@greenplum.com>
Date: Monday, December 19, 2005 2:38 pm
Subject: Re: [PERFORM] PostgreSQL and Ultrasparc T1
To: Jignesh Shah <J.K.Shah@Sun.COM>
Cc: Juan Casero <caseroj@comcast.net>, pgsql-performance@postgresql.org
> Jignesh,
>
> On 12/19/05 11:29 AM, "Jignesh Shah" <J.K.Shah@Sun.COM> wrote:
>
> > I have gone to the max with 4 fibers on Sun Fire T2000. But I am
> not sure
> > about the answers that you asked. Let me see if I can get answers
> for them. I
> > am going to try to max out the IO on these systems with 8 fibers
> as soon as I
> > get additional storage so stay tuned for that.
>
> Cool - how close did you get to 800MB/s?
>
> > By the way you don't have to wait for my tests. Just get a trial
> server and
> > try it on your own. If you don't like it return it.
> >
> > https://www.sun.com/emrkt/trycoolthreads/contactme.html
>
> Done - I'll certainly test Postgres / Bizgres on it - you know me ;-)
>
> > However if you do try it with PostgreSQL, do let me know also
> with your
> > experience.
>
> See above.
>
> The Niagara is UltraSparc III compatible - so the GCC compiler
> should emit
> good code for it, right?
>
> - Luke
>
>
>
> ---------------------------(end of broadcast)-----------------------
> ----
> TIP 2: Don't 'kill -9' the postmaster
>
Ok. That is what I wanted to know. Right now this database is a PostgreSQL 7.4.8 system. I am using it in a sort of DSS role. I have weekly summaries of the sales for our division going back three years. I have a PHP based webapp that I wrote to give the managers access to this data. The webapp lets them make selections for reports and then it submits a parameterized query to the database for execution. The returned data rows are displayed and formatted in their web browser. My largest sales table is about 13 million rows along with all the indexes it takes up about 20 gigabytes. I need to scale this application up to nearly 100 gigabytes to handle daily sales summaries. Once we start looking at daily sales figures our database size could grow ten to twenty times. I use postgresql because it gives me the kind of enterprise database features I need to program the complex logic for the queries. I also need the transaction isolation facilities it provides so I can optimize the queries in plpgsql without worrying about multiple users temp tables colliding with each other. Additionally, I hope to rewrite the front end application in JSP so maybe I could use the multithreaded features of the Java to exploit a multicore multi-cpu system. There are almost no writes to the database tables. The bulk of the application is just executing parameterized queries and returning huge amounts of data. I know bizgres is supposed to be better at this but I want to stay away from anything that is beta. I cannot afford for this thing to go wrong. My reasoning for looking at the T1000/2000 was simply the large number of cores. I know postgresql uses a super server that forks copies of itself to handle incoming requests on port 5432. But I figured the number of cores on the T1000/2000 processors would be utilized by the forked copies of the postgresql server. From the comments I have seen so far it does not look like this is the case. We had originally sized up a dual processor dual core AMD opteron system from HP for this but I thought I could get more bang for the buck on a T1000/2000. It now seems I may have been wrong. I am stronger in Linux than Solaris so I am not upset I am just trying to find the best hardware for the anticipated needs of this application. Thanks, Juan On Monday 19 December 2005 01:25, Scott Marlowe wrote: > From: pgsql-performance-owner@postgresql.org on behalf of Juan Casero > > QUOTE: > > Hi - > > > 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. > > ENDQUOTE: > > Well, generally, AMD 64 bit is going to be a better value for your dollar, > and run faster than most Sparc based machines. > > Also, PostgreSQL is generally faster under either BSD or Linux than under > Solaris on the same box. This might or might not hold as you crank up the > numbers of CPUs. > > PostgreSQL runs one process for connection. So, to use extra CPUs, you > really need to have >1 connection running against the database. > > Mostly, databases tend to be either I/O bound, until you give them a lot of > I/O, then they'll be CPU bound. > > After that lots of memory, THEN more CPUs. Two CPUs is always useful, as > one can be servicing the OS and another the database. But unless you're > gonna have lots of users hooked up, more than 2 to 4 CPUs is usually a > waste. > > So, I'd recommend a dual core or dual dual core (i.e. 4 cores) AMD64 system > with 2 or more gigs ram, and at least a pair of fast drives in a mirror > with a hardare RAID controller with battery backed cache. If you'll be > trundling through all 100 gigs of your data set regularly, then get all the > memory you can put in a machine at a reasonable cost before buying lots of > CPUs. > > But without knowing what you're gonna be doing we can't really make solid > recommendations...
Jignesh, On 12/19/05 12:21 PM, "Jignesh Shah" <J.K.Shah@Sun.COM> wrote: > I got about 720 MB/sec to 730 MB/sec with plain dd tests on my current > storage configuration (8 LUNS on 4 fibers) which slowed me down (10K rpm 146 > GB disks FC) with 4 LUNS going through a longer pass to the disks (via a > controller master array to slave JBODs to provide ) . > > extended device statistics > r/s w/s Mr/s Mw/s wait actv wsvc_t asvc_t %w %b device > 0.8 14.0 0.0 0.0 0.0 0.3 0.0 17.8 0 4 c3t0d0 > 91.4 0.0 91.4 0.0 0.0 1.0 0.0 10.5 0 96 c0t40d0 > 96.0 0.0 96.0 0.0 0.0 1.0 0.0 10.0 0 96 c5t40d1 > 95.8 0.0 95.8 0.0 0.0 1.0 0.0 10.0 0 96 c0t40d1 Can you please explain these columns? R/s, is that millions of pages or extents or something? How do I translate this to 730 million bytes per second? - Luke
Jignesh, On 12/19/05 12:21 PM, "Jignesh Shah" <J.K.Shah@Sun.COM> wrote: > extended device statistics > r/s w/s Mr/s Mw/s wait actv wsvc_t asvc_t %w %b device > 0.8 14.0 0.0 0.0 0.0 0.3 0.0 17.8 0 4 c3t0d0 > 91.4 0.0 91.4 0.0 0.0 1.0 0.0 10.5 0 96 c0t40d0 > 96.0 0.0 96.0 0.0 0.0 1.0 0.0 10.0 0 96 c5t40d1 > 95.8 0.0 95.8 0.0 0.0 1.0 0.0 10.0 0 96 c0t40d1 > 96.8 0.0 96.8 0.0 0.0 1.0 0.0 9.9 0 96 c5t40d0 > 84.6 0.0 84.6 0.0 0.0 1.0 0.0 11.4 0 96 c4t46d1 > 85.6 0.0 85.6 0.0 0.0 1.0 0.0 11.2 0 96 c4t46d0 > 85.2 0.0 85.2 0.0 0.0 1.0 0.0 11.3 0 96 c2t46d1 > 85.4 0.0 85.4 0.0 0.0 1.0 0.0 11.3 0 96 c2t46d0 Doh! Forget my last message, each of these is a single drive. Wacky layout though - it looks like c0,c2,c3,c4,c5 - is that 5 controllers there? Also - what are the RAID options on this unit? To get optimal performance on an 8 core unit, would we want to map 1 active process to each of these drives? Can the CPU run all 8 threads simultaneously? - Luke
I guess it depends on what you term as your metric for measurement. If it is just one query execution time .. It may not be the best on UltraSPARC T1. But if you have more than 8 complex queries running simultaneously, UltraSPARC T1 can do well compared comparatively provided the application can scale also along with it. The best way to approach is to figure out your peak workload, find an accurate way to measure the "true" metric and then design a benchmark for it and run it on both servers. Regards, Jignesh Juan Casero wrote: >Ok. That is what I wanted to know. Right now this database is a PostgreSQL >7.4.8 system. I am using it in a sort of DSS role. I have weekly summaries >of the sales for our division going back three years. I have a PHP based >webapp that I wrote to give the managers access to this data. The webapp >lets them make selections for reports and then it submits a parameterized >query to the database for execution. The returned data rows are displayed >and formatted in their web browser. My largest sales table is about 13 >million rows along with all the indexes it takes up about 20 gigabytes. I >need to scale this application up to nearly 100 gigabytes to handle daily >sales summaries. Once we start looking at daily sales figures our database >size could grow ten to twenty times. I use postgresql because it gives me >the kind of enterprise database features I need to program the complex logic >for the queries. I also need the transaction isolation facilities it >provides so I can optimize the queries in plpgsql without worrying about >multiple users temp tables colliding with each other. Additionally, I hope >to rewrite the front end application in JSP so maybe I could use the >multithreaded features of the Java to exploit a multicore multi-cpu system. >There are almost no writes to the database tables. The bulk of the >application is just executing parameterized queries and returning huge >amounts of data. I know bizgres is supposed to be better at this but I want >to stay away from anything that is beta. I cannot afford for this thing to >go wrong. My reasoning for looking at the T1000/2000 was simply the large >number of cores. I know postgresql uses a super server that forks copies of >itself to handle incoming requests on port 5432. But I figured the number of >cores on the T1000/2000 processors would be utilized by the forked copies of >the postgresql server. From the comments I have seen so far it does not look >like this is the case. We had originally sized up a dual processor dual core >AMD opteron system from HP for this but I thought I could get more bang for >the buck on a T1000/2000. It now seems I may have been wrong. I am stronger >in Linux than Solaris so I am not upset I am just trying to find the best >hardware for the anticipated needs of this application. > >Thanks, >Juan > >On Monday 19 December 2005 01:25, Scott Marlowe wrote: > > >>From: pgsql-performance-owner@postgresql.org on behalf of Juan Casero >> >>QUOTE: >> >>Hi - >> >> >>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. >> >>ENDQUOTE: >> >>Well, generally, AMD 64 bit is going to be a better value for your dollar, >>and run faster than most Sparc based machines. >> >>Also, PostgreSQL is generally faster under either BSD or Linux than under >>Solaris on the same box. This might or might not hold as you crank up the >>numbers of CPUs. >> >>PostgreSQL runs one process for connection. So, to use extra CPUs, you >>really need to have >1 connection running against the database. >> >>Mostly, databases tend to be either I/O bound, until you give them a lot of >>I/O, then they'll be CPU bound. >> >>After that lots of memory, THEN more CPUs. Two CPUs is always useful, as >>one can be servicing the OS and another the database. But unless you're >>gonna have lots of users hooked up, more than 2 to 4 CPUs is usually a >>waste. >> >>So, I'd recommend a dual core or dual dual core (i.e. 4 cores) AMD64 system >>with 2 or more gigs ram, and at least a pair of fast drives in a mirror >>with a hardare RAID controller with battery backed cache. If you'll be >>trundling through all 100 gigs of your data set regularly, then get all the >>memory you can put in a machine at a reasonable cost before buying lots of >>CPUs. >> >>But without knowing what you're gonna be doing we can't really make solid >>recommendations... >> >> > >---------------------------(end of broadcast)--------------------------- >TIP 4: Have you searched our list archives? > > http://archives.postgresql.org > >
Jignesh K. Shah wrote: > I guess it depends on what you term as your metric for measurement. > If it is just one query execution time .. It may not be the best on > UltraSPARC T1. > But if you have more than 8 complex queries running simultaneously, > UltraSPARC T1 can do well compared comparatively provided the > application can scale also along with it. I just want to clarify one issue here. It's my understanding that the 8-core, 4 hardware thread (known as strands) system is seen as a 32 cpu system by Solaris. So, one could have up to 32 postgresql processes running in parallel on the current systems (assuming the application can scale). -- Alan
On Tue, 20 Dec 2005, Alan Stange wrote: > Jignesh K. Shah wrote: >> I guess it depends on what you term as your metric for measurement. >> If it is just one query execution time .. It may not be the best on >> UltraSPARC T1. >> But if you have more than 8 complex queries running simultaneously, >> UltraSPARC T1 can do well compared comparatively provided the application >> can scale also along with it. > > I just want to clarify one issue here. It's my understanding that the > 8-core, 4 hardware thread (known as strands) system is seen as a 32 cpu > system by Solaris. > So, one could have up to 32 postgresql processes running in parallel on the > current systems (assuming the application can scale). note that like hyperthreading, the strands aren't full processors, their efficiancy depends on how much other threads shareing the core stall waiting for external things. David Lang
David Lang wrote: > On Tue, 20 Dec 2005, Alan Stange wrote: > >> Jignesh K. Shah wrote: >>> I guess it depends on what you term as your metric for measurement. >>> If it is just one query execution time .. It may not be the best on >>> UltraSPARC T1. >>> But if you have more than 8 complex queries running simultaneously, >>> UltraSPARC T1 can do well compared comparatively provided the >>> application can scale also along with it. >> >> I just want to clarify one issue here. It's my understanding that >> the 8-core, 4 hardware thread (known as strands) system is seen as a >> 32 cpu system by Solaris. So, one could have up to 32 postgresql >> processes running in parallel on the current systems (assuming the >> application can scale). > > note that like hyperthreading, the strands aren't full processors, > their efficiancy depends on how much other threads shareing the core > stall waiting for external things. Exactly.
On Tue, 20 Dec 2005, Alan Stange wrote: > David Lang wrote: >> On Tue, 20 Dec 2005, Alan Stange wrote: >> >>> Jignesh K. Shah wrote: >>>> I guess it depends on what you term as your metric for measurement. >>>> If it is just one query execution time .. It may not be the best on >>>> UltraSPARC T1. >>>> But if you have more than 8 complex queries running simultaneously, >>>> UltraSPARC T1 can do well compared comparatively provided the application >>>> can scale also along with it. >>> >>> I just want to clarify one issue here. It's my understanding that the >>> 8-core, 4 hardware thread (known as strands) system is seen as a 32 cpu >>> system by Solaris. So, one could have up to 32 postgresql processes >>> running in parallel on the current systems (assuming the application can >>> scale). >> >> note that like hyperthreading, the strands aren't full processors, their >> efficiancy depends on how much other threads shareing the core stall >> waiting for external things. > Exactly. Until we have a machine in hand (and substantial technical > documentation) we won't know all the limitations. by the way, when you do get your hands on it I would be interested to hear how Linux compares to Solaris on the same hardware. given how new the hardware is it's also likly that linux won't identify the hardware properly (either seeing it as 32 true processors or just as 8 without being able to use the strands), so the intitial tests may not reflect the Linux performance in a release or two. David Lang
Jignesh,
Juan says the following below:
"I figured the number of cores on the T1000/2000 processors would be
utilized by the forked copies of the postgresql server. From the comments
I have seen so far it does not look like this is the case."
I think this needs to be refuted. Doesn't Solaris switch processes as well
as threads (LWPs, whatever) equally well amongst cores? I realize the
process context switch is more expensive than the thread switch, but
Solaris will utilize all cores as processes or threads become ready to run,
correct?
BTW, it's great to see folks with your email address on the list. I feel
it points to a brighter future for all involved.
Thanks,
Rick
"Jignesh K. Shah"
<J.K.Shah@Sun.COM
> To
Sent by: Juan Casero <caseroj@comcast.net>
pgsql-performance cc
-owner@postgresql pgsql-performance@postgresql.org
.org Subject
Re: [PERFORM] PostgreSQL and
Ultrasparc T1
12/19/2005 11:19
PM
I guess it depends on what you term as your metric for measurement.
If it is just one query execution time .. It may not be the best on
UltraSPARC T1.
But if you have more than 8 complex queries running simultaneously,
UltraSPARC T1 can do well compared comparatively provided the
application can scale also along with it.
The best way to approach is to figure out your peak workload, find an
accurate way to measure the "true" metric and then design a benchmark
for it and run it on both servers.
Regards,
Jignesh
Juan Casero wrote:
>Ok. That is what I wanted to know. Right now this database is a
PostgreSQL
>7.4.8 system. I am using it in a sort of DSS role. I have weekly
summaries
>of the sales for our division going back three years. I have a PHP based
>webapp that I wrote to give the managers access to this data. The webapp
>lets them make selections for reports and then it submits a parameterized
>query to the database for execution. The returned data rows are displayed
>and formatted in their web browser. My largest sales table is about 13
>million rows along with all the indexes it takes up about 20 gigabytes. I
>need to scale this application up to nearly 100 gigabytes to handle daily
>sales summaries. Once we start looking at daily sales figures our
database
>size could grow ten to twenty times. I use postgresql because it gives me
>the kind of enterprise database features I need to program the complex
logic
>for the queries. I also need the transaction isolation facilities it
>provides so I can optimize the queries in plpgsql without worrying about
>multiple users temp tables colliding with each other. Additionally, I
hope
>to rewrite the front end application in JSP so maybe I could use the
>multithreaded features of the Java to exploit a multicore multi-cpu
system.
>There are almost no writes to the database tables. The bulk of the
>application is just executing parameterized queries and returning huge
>amounts of data. I know bizgres is supposed to be better at this but I
want
>to stay away from anything that is beta. I cannot afford for this thing
to
>go wrong. My reasoning for looking at the T1000/2000 was simply the large
>number of cores. I know postgresql uses a super server that forks copies
of
>itself to handle incoming requests on port 5432. But I figured the number
of
>cores on the T1000/2000 processors would be utilized by the forked copies
of
>the postgresql server. From the comments I have seen so far it does not
look
>like this is the case. We had originally sized up a dual processor dual
core
>AMD opteron system from HP for this but I thought I could get more bang
for
>the buck on a T1000/2000. It now seems I may have been wrong. I am
stronger
>in Linux than Solaris so I am not upset I am just trying to find the best
>hardware for the anticipated needs of this application.
>
>Thanks,
>Juan
>
>On Monday 19 December 2005 01:25, Scott Marlowe wrote:
>
>
>>From: pgsql-performance-owner@postgresql.org on behalf of Juan Casero
>>
>>QUOTE:
>>
>>Hi -
>>
>>
>>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.
>>
>>ENDQUOTE:
>>
>>Well, generally, AMD 64 bit is going to be a better value for your
dollar,
>>and run faster than most Sparc based machines.
>>
>>Also, PostgreSQL is generally faster under either BSD or Linux than under
>>Solaris on the same box. This might or might not hold as you crank up
the
>>numbers of CPUs.
>>
>>PostgreSQL runs one process for connection. So, to use extra CPUs, you
>>really need to have >1 connection running against the database.
>>
>>Mostly, databases tend to be either I/O bound, until you give them a lot
of
>>I/O, then they'll be CPU bound.
>>
>>After that lots of memory, THEN more CPUs. Two CPUs is always useful, as
>>one can be servicing the OS and another the database. But unless you're
>>gonna have lots of users hooked up, more than 2 to 4 CPUs is usually a
>>waste.
>>
>>So, I'd recommend a dual core or dual dual core (i.e. 4 cores) AMD64
system
>>with 2 or more gigs ram, and at least a pair of fast drives in a mirror
>>with a hardare RAID controller with battery backed cache. If you'll be
>>trundling through all 100 gigs of your data set regularly, then get all
the
>>memory you can put in a machine at a reasonable cost before buying lots
of
>>CPUs.
>>
>>But without knowing what you're gonna be doing we can't really make solid
>>recommendations...
>>
>>
>
>---------------------------(end of broadcast)---------------------------
>TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>
>
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
But yes All LWPs (processes and threads) are switched across virtual CPUS . There is intelligence built in Solaris to understand which strands are executing on which cores and it will balance out the cores too so if there are only 8 threads running they will essentially run on separate cores rather than 2 cores with 8 threads. The biggest limitation is application scaling. pgbench shows that with more processes trying to bottleneck on same files will probably not perform better unless you tune your storage/file system. Those are the issues which we typically try to solve with community partners (vendors, open source) since that gives the biggest benefits. Best example to verify in such multi-processes environment, do you see greater than 60% avg CPU utilization in your dual/quad config Xeons/Itaniums, then Sun Fire T2000 will help you a lot. However if you are stuck below 50% (for dual) or 25% (for quad) which means you are pretty much stuck at 1 CPU performance and/or probably have more IO related contention then it won't help you with these systems. I hope you get the idea on when a workload will perform better on Sun Fire T2000 without burning hands. I will try to test some more with PostgreSQL on these systems to kind of highlight what can work or what will not work. Is pgbench the workload that you prefer? (It already has issues with pg_xlog so my guess is it probably won't scale much) If you have other workload informations let me know. Thanks. Regards, Jignesh Richard_D_Levine@raytheon.com wrote: >Jignesh, > >Juan says the following below: > >"I figured the number of cores on the T1000/2000 processors would be >utilized by the forked copies of the postgresql server. From the comments >I have seen so far it does not look like this is the case." > >I think this needs to be refuted. Doesn't Solaris switch processes as well >as threads (LWPs, whatever) equally well amongst cores? I realize the >process context switch is more expensive than the thread switch, but >Solaris will utilize all cores as processes or threads become ready to run, >correct? > >BTW, it's great to see folks with your email address on the list. I feel >it points to a brighter future for all involved. > >Thanks, > >Rick > > > > "Jignesh K. Shah" > <J.K.Shah@Sun.COM > > To > Sent by: Juan Casero <caseroj@comcast.net> > pgsql-performance cc > -owner@postgresql pgsql-performance@postgresql.org > .org Subject > Re: [PERFORM] PostgreSQL and > Ultrasparc T1 > 12/19/2005 11:19 > PM > > > > > > > > >I guess it depends on what you term as your metric for measurement. >If it is just one query execution time .. It may not be the best on >UltraSPARC T1. >But if you have more than 8 complex queries running simultaneously, >UltraSPARC T1 can do well compared comparatively provided the >application can scale also along with it. > >The best way to approach is to figure out your peak workload, find an >accurate way to measure the "true" metric and then design a benchmark >for it and run it on both servers. > >Regards, >Jignesh > > >Juan Casero wrote: > > > >>Ok. That is what I wanted to know. Right now this database is a >> >> >PostgreSQL > > >>7.4.8 system. I am using it in a sort of DSS role. I have weekly >> >> >summaries > > >>of the sales for our division going back three years. I have a PHP based >>webapp that I wrote to give the managers access to this data. The webapp >>lets them make selections for reports and then it submits a parameterized >>query to the database for execution. The returned data rows are displayed >> >> > > > >>and formatted in their web browser. My largest sales table is about 13 >>million rows along with all the indexes it takes up about 20 gigabytes. I >> >> > > > >>need to scale this application up to nearly 100 gigabytes to handle daily >>sales summaries. Once we start looking at daily sales figures our >> >> >database > > >>size could grow ten to twenty times. I use postgresql because it gives me >> >> > > > >>the kind of enterprise database features I need to program the complex >> >> >logic > > >>for the queries. I also need the transaction isolation facilities it >>provides so I can optimize the queries in plpgsql without worrying about >>multiple users temp tables colliding with each other. Additionally, I >> >> >hope > > >>to rewrite the front end application in JSP so maybe I could use the >>multithreaded features of the Java to exploit a multicore multi-cpu >> >> >system. > > >>There are almost no writes to the database tables. The bulk of the >>application is just executing parameterized queries and returning huge >>amounts of data. I know bizgres is supposed to be better at this but I >> >> >want > > >>to stay away from anything that is beta. I cannot afford for this thing >> >> >to > > >>go wrong. My reasoning for looking at the T1000/2000 was simply the large >> >> > > > >>number of cores. I know postgresql uses a super server that forks copies >> >> >of > > >>itself to handle incoming requests on port 5432. But I figured the number >> >> >of > > >>cores on the T1000/2000 processors would be utilized by the forked copies >> >> >of > > >>the postgresql server. From the comments I have seen so far it does not >> >> >look > > >>like this is the case. We had originally sized up a dual processor dual >> >> >core > > >>AMD opteron system from HP for this but I thought I could get more bang >> >> >for > > >>the buck on a T1000/2000. It now seems I may have been wrong. I am >> >> >stronger > > >>in Linux than Solaris so I am not upset I am just trying to find the best >>hardware for the anticipated needs of this application. >> >>Thanks, >>Juan >> >>On Monday 19 December 2005 01:25, Scott Marlowe wrote: >> >> >> >> >>>From: pgsql-performance-owner@postgresql.org on behalf of Juan Casero >>> >>>QUOTE: >>> >>>Hi - >>> >>> >>>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. >>> >>>ENDQUOTE: >>> >>>Well, generally, AMD 64 bit is going to be a better value for your >>> >>> >dollar, > > >>>and run faster than most Sparc based machines. >>> >>>Also, PostgreSQL is generally faster under either BSD or Linux than under >>>Solaris on the same box. This might or might not hold as you crank up >>> >>> >the > > >>>numbers of CPUs. >>> >>>PostgreSQL runs one process for connection. So, to use extra CPUs, you >>>really need to have >1 connection running against the database. >>> >>>Mostly, databases tend to be either I/O bound, until you give them a lot >>> >>> >of > > >>>I/O, then they'll be CPU bound. >>> >>>After that lots of memory, THEN more CPUs. Two CPUs is always useful, as >>>one can be servicing the OS and another the database. But unless you're >>>gonna have lots of users hooked up, more than 2 to 4 CPUs is usually a >>>waste. >>> >>>So, I'd recommend a dual core or dual dual core (i.e. 4 cores) AMD64 >>> >>> >system > > >>>with 2 or more gigs ram, and at least a pair of fast drives in a mirror >>>with a hardare RAID controller with battery backed cache. If you'll be >>>trundling through all 100 gigs of your data set regularly, then get all >>> >>> >the > > >>>memory you can put in a machine at a reasonable cost before buying lots >>> >>> >of > > >>>CPUs. >>> >>>But without knowing what you're gonna be doing we can't really make solid >>>recommendations... >>> >>> >>> >>> >>---------------------------(end of broadcast)--------------------------- >>TIP 4: Have you searched our list archives? >> >> http://archives.postgresql.org >> >> >> >> > >---------------------------(end of broadcast)--------------------------- >TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > > > >
On Tue, Dec 20, 2005 at 12:20:55PM -0500, Jignesh K. Shah wrote: > Is pgbench the workload that you prefer? (It already has issues with > pg_xlog so my guess is it probably won't scale much) > If you have other workload informations let me know. From what the user described, dbt3 would probably be the best benchmark to use. Note that they're basically read-only, which is absolutely not what pgbench does. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Sun, Dec 18, 2005 at 11:35:15AM -0500, Juan Casero 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 People have seen some pretty big gains going from 7.4 to 8.1. I recently migrated http://stats.distributed.net and the daily processing (basically OLAP) times were cut in half. As someone else mentioned, IO is probably going to be your biggest consideration, unless you have a lot of queries running at once. Probably your best bang for the buck will be from an Opteron-based server with a good number of internal drives. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461