Thread: solaris slow
Hi
I have installed postgres 8.4.4 (libxml and plperl)on a Sun Microsystems sun4u Sun Fire 880 with:
- 4 700Mhz processors
- 8 Gb Ram
- System 9 operSolaris
- 64-bit sparcv9 Applications
- 32-bit sparc Applications
- SCSI-3. Discs do not have any arrangement
It was compiled with the sun-studio (flag-bit X05 and 32 bits ....) ... i follow the recommendations from:
http://www.postgresql.org/docs/8.4/static/installation-platform-notes.html # INSTALLATION-NOTES-SOLARIS
Also I have installed postgres (8.4.2) on a PC (Dell Optiplex 960) with the next characteristics:
- 3 Gb ram
- 1 processor of 3.2 Ghz Dual Core
- A hard SATAS
- 06/02/1928 Linux (gentoo)
We design some performance tests (special for my application); this test was executed with pgbench:
pgbench -c 5 -T 600 -n -U aeedc -f test.sql aeespc
The results was the next:
on pc :
Thu July 29 15:50:02 CDT 2010
transaction type: Custom query
scaling factor: 1
query mode: simple
number of clients: 5
duration: 120 s
Actually number of Transactions processed: 159
tps = 1.302670 (Including Establishing connections)
tps = 1.302746 (excluding Establishing connections)
Thu July 29 15:52:04 CDT 2010
on Solaris:
Mon July 26 18:41:58 CDT 2010
transaction type: Custom query
scaling factor: 1
query mode: simple
number of clients: 5
duration: 120 s
Actually number of Transactions processed: 85
tps = 0.668752 (Including Establishing connections)
tps = 0.669172 (excluding Establishing connections)
Mon July 26 18:44:05 CDT 2010
As observed, is much slower solaris.
I also see the difference in disk access. For example iostat throws in the pc (filter some columns)
device r/s w/s rKB/s wKB/s await %util
sda 0.12 3.62 8.24 45.85 6.06 0.16
sda 0 2.2 0 126.4 0.64 0.08
sda 0 0.8 0 8 0 0
sda 0 1.6 0 31.2 0.12 0.02
sda 0 1.2 0 8.8 0.17 0.02
sda 0 1.8 0 36 0.11 0.02
sda 0 1 0 5.6 0.6 0.06
and on Solaris:
r/s w/s kr/s kw/s wait wsvc_t asvc_t %w %b
c1t0d0 0.1 2.8 2.5 25.3 0.1 27.8 22.8 0 2
c1t0d0 0 4.8 0 36.8 0 0 5.8 0 3
c1t0d0 0 10.8 0 92.8 0 0 8 0 6
c1t0d0 0 12.2 0 97.6 1.2 99.8 77.6 5 7
it is also slower solaris ...
I made the following "tunnings" in solaris without managing to improve the performance:
http://blogs.sun.com/jkshah/entry/best_practices_with_postgresql_8
http://archives.postgresql.org/pgsql-performance/2006-02/msg00190.php
http://vnull.pcnet.com.pl/dl/postgresql/pgsol_best_practices.pdf
My questions
- are there another way to improve the performance of solaris? where can i
read more?
- the PC (with linux) have better performance than SUN (solaris).... therefore
never going to get better performance ... what do you think about it?
Greetings and thanks in advance.
I have installed postgres 8.4.4 (libxml and plperl)on a Sun Microsystems sun4u Sun Fire 880 with:
- 4 700Mhz processors
- 8 Gb Ram
- System 9 operSolaris
- 64-bit sparcv9 Applications
- 32-bit sparc Applications
- SCSI-3. Discs do not have any arrangement
It was compiled with the sun-studio (flag-bit X05 and 32 bits ....) ... i follow the recommendations from:
http://www.postgresql.org/docs/8.4/static/installation-platform-notes.html # INSTALLATION-NOTES-SOLARIS
Also I have installed postgres (8.4.2) on a PC (Dell Optiplex 960) with the next characteristics:
- 3 Gb ram
- 1 processor of 3.2 Ghz Dual Core
- A hard SATAS
- 06/02/1928 Linux (gentoo)
We design some performance tests (special for my application); this test was executed with pgbench:
pgbench -c 5 -T 600 -n -U aeedc -f test.sql aeespc
The results was the next:
on pc :
Thu July 29 15:50:02 CDT 2010
transaction type: Custom query
scaling factor: 1
query mode: simple
number of clients: 5
duration: 120 s
Actually number of Transactions processed: 159
tps = 1.302670 (Including Establishing connections)
tps = 1.302746 (excluding Establishing connections)
Thu July 29 15:52:04 CDT 2010
on Solaris:
Mon July 26 18:41:58 CDT 2010
transaction type: Custom query
scaling factor: 1
query mode: simple
number of clients: 5
duration: 120 s
Actually number of Transactions processed: 85
tps = 0.668752 (Including Establishing connections)
tps = 0.669172 (excluding Establishing connections)
Mon July 26 18:44:05 CDT 2010
As observed, is much slower solaris.
I also see the difference in disk access. For example iostat throws in the pc (filter some columns)
device r/s w/s rKB/s wKB/s await %util
sda 0.12 3.62 8.24 45.85 6.06 0.16
sda 0 2.2 0 126.4 0.64 0.08
sda 0 0.8 0 8 0 0
sda 0 1.6 0 31.2 0.12 0.02
sda 0 1.2 0 8.8 0.17 0.02
sda 0 1.8 0 36 0.11 0.02
sda 0 1 0 5.6 0.6 0.06
and on Solaris:
r/s w/s kr/s kw/s wait wsvc_t asvc_t %w %b
c1t0d0 0.1 2.8 2.5 25.3 0.1 27.8 22.8 0 2
c1t0d0 0 4.8 0 36.8 0 0 5.8 0 3
c1t0d0 0 10.8 0 92.8 0 0 8 0 6
c1t0d0 0 12.2 0 97.6 1.2 99.8 77.6 5 7
it is also slower solaris ...
I made the following "tunnings" in solaris without managing to improve the performance:
http://blogs.sun.com/jkshah/entry/best_practices_with_postgresql_8
http://archives.postgresql.org/pgsql-performance/2006-02/msg00190.php
http://vnull.pcnet.com.pl/dl/postgresql/pgsol_best_practices.pdf
My questions
- are there another way to improve the performance of solaris? where can i
read more?
- the PC (with linux) have better performance than SUN (solaris).... therefore
never going to get better performance ... what do you think about it?
Greetings and thanks in advance.
On Mon, 2010-08-02 at 14:35 +0000, Felipe de Jesús Molina Bravo wrote: > Hi > > We design some performance tests (special for my application); this > test was executed with pgbench: > > pgbench -c 5 -T 600 -n -U aeedc -f test.sql aeespc > You noted SCSI disks on solaris. They may not have the CACHE turned on, on the drive. The SATA drives will have cache turned on and will be faster. That said, your results are slow as a whole. Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
On 08/02/10 7:35 AM, Felipe de Jesús Molina Bravo wrote: > Hi > > > I have installed postgres 8.4.4 (libxml and plperl)on a Sun > Microsystems sun4u Sun Fire 880 with: > > - 4 700Mhz processors > ... > Also I have installed postgres (8.4.2) on a PC (Dell Optiplex 960) > with the next characteristics: > > - 3 Gb ram > - 1 processor of 3.2 Ghz Dual Core ... dual 3.2Ghz Core2 processor cores are going to be far faster than a 9 year old quad 700Mhz ultrasparc-III's, regardless of the operating system. If you want to compare operating system performance, you should do so on the same hardware platform. btw, the standard disks on a SunFire 880 are FC-AL not SCSI... old 1Gbps FC, I believe, with 36-146GB 10K rpm FC drives standard, with all the internal drives sharing the same 1Gbps FC port. Another factor, if your linux system was using LVM (its the default storage configuration on many distributions), there's a pretty good chance the drive mapper is ignoring write barriers, which greatly speeds up random writes at the expense of reliable commits.
2010/8/2 John R Pierce <pierce@hogranch.com>: > On 08/02/10 7:35 AM, Felipe de Jesús Molina Bravo wrote: >> >> Hi >> >> >> I have installed postgres 8.4.4 (libxml and plperl)on a Sun Microsystems >> sun4u Sun Fire 880 with: >> >> - 4 700Mhz processors >> ... >> Also I have installed postgres (8.4.2) on a PC (Dell Optiplex 960) with >> the next characteristics: >> >> - 3 Gb ram >> - 1 processor of 3.2 Ghz Dual Core > > ... > > dual 3.2Ghz Core2 processor cores are going to be far faster than a 9 year > old quad 700Mhz ultrasparc-III's, regardless of the operating system. > Good point. Note to the OP, you can install OpenSolaris on your PC hardware if you want to compare the same hardware with a different OS.
El 2 de agosto de 2010 19:14, John R Pierce <pierce@hogranch.com> escribió:
On 08/02/10 7:35 AM, Felipe de Jesús Molina Bravo wrote:...Hi...
I have installed postgres 8.4.4 (libxml and plperl)on a Sun Microsystems sun4u Sun Fire 880 with:
- 4 700Mhz processors
Also I have installed postgres (8.4.2) on a PC (Dell Optiplex 960) with the next characteristics:
- 3 Gb ram
- 1 processor of 3.2 Ghz Dual Core
dual 3.2Ghz Core2 processor cores are going to be far faster than a 9 year old quad 700Mhz ultrasparc-III's, regardless of the operating system.
If you want to compare operating system performance, you should do so on the same hardware platform.
btw, the standard disks on a SunFire 880 are FC-AL not SCSI... old 1Gbps FC, I believe, with 36-146GB 10K rpm FC drives standard, with all the internal drives sharing the same 1Gbps FC port.
Another factor, if your linux system was using LVM (its the default storage configuration on many distributions), there's a pretty good chance the drive mapper is ignoring write barriers, which greatly speeds up random writes at the expense of reliable commits.
My file-system is Reiser 3.
I try with "CACHE turned on" (recommendation from Josua ... thanks) with the same results.
I tried to migrate my database from the PC to Sun ... with the same performance.....but I can not
I try with "CACHE turned on" (recommendation from Josua ... thanks) with the same results.
I tried to migrate my database from the PC to Sun ... with the same performance.....but I can not
My conclution is:
I'll ever get similar performance because the technology of PC is more recent than SUN .... thanks to all for your answers
see you
On Mon, 2010-08-02 at 14:35 +0000, Felipe de Jesús Molina Bravo wrote: > Hi > > We design some performance tests (special for my application); this > test was executed with pgbench: > > pgbench -c 5 -T 600 -n -U aeedc -f test.sql aeespc > You noted SCSI disks on solaris. They may not have the CACHE turned on, on the drive. The SATA drives will have cache turned on and will be faster. That said, your results are slow as a whole. Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
On 02/08/2010 21:14, John R Pierce wrote: > Another factor, if your linux system was using LVM (its the default > storage configuration on many distributions), there's a pretty good > chance the drive mapper is ignoring write barriers, which greatly speeds > up random writes at the expense of reliable commits. A lot has been discussed about how well LVM plays with PostgreSQL. But for sure, write barriers are not related to commits. A reliable commit is about disks synchronously flushing their caches to platters (and of course, before that, OS cache being flushed to disk cache, which is the easy part). In ACID terms, write barries help with C, not with D. Actually, a write barrier is kind of the opposite of a flush, it's a "don't flush this before that". It enforces an order on writes, but doesn't enforce their immediate execution. Of course, if the disk _doesn't_ support write barriers, poor's man workaround is to enforce a complete flush instead. AFAIK, there's no POSIX API to request a write barrier at application level. There's only the sync (i.e. flush) related API. And I'm pretty sure PostegreSQL issues the right syncs at the right times. LVM correctly reports it doesn't support write barriers. The FS then knows what to do (issue a full flush instead), and no harm is done (because not all disks support wbs, the code to handle that case has to be there in the FS). The FS just runs slower. But just as safe as without LVM. And since PostgreSQL issues syncs (or uses synchronous APIs), there's little point discussing of wbs here, since it's all about flushing. Wbs are issued by the FS in order to _avoid_ a flush: the FS major concern is C, not D; but when it's the application requesting a flush, the flush can't be avoided, and wbs are almost useless. .TM.