SEO

Oracle and Solaris are/were the choice combination to run Oracle on. I
would think that with this being the case, SUN Microsystems must have
optimized Solaris to be an excellent OS for Relational Database
Management Systems. That being said, could using PostgreSQL on Sun's
Solaris OS improve performance compared to other operating systems like
Windows and Linux?

What about Sun Studio C compiler. I heard it produces really fast
executables. Is it possible to use that compiler instead of gcc to
compile PostgreSQL to get a faster PostgreSQL by taking advantage of
Sun's C compiler producing a faster executable?

We probably all have heard about Oracle's Linux distribution. Does
Oracle's Linux distro provide better PostgreSQL/ RDBMS performance over
Solaris 10 or Redhat distros?

regards,

karen

Karen Hill wrote:
> Oracle and Solaris are/were the choice combination to run Oracle on. I
> would think that with this being the case, SUN Microsystems must have
> optimized Solaris to be an excellent OS for Relational Database
> Management Systems.

Some benchmarks agree:
http://www.mysql.com/news-and-events...e_2006_19.html


> That being said, could using PostgreSQL on Sun's
> Solaris OS improve performance compared to other operating systems like
> Windows and Linux?

Have you seen http://www.sun.com/software/solaris/postgresql.jsp ?

>
> What about Sun Studio C compiler. I heard it produces really fast
> executables. Is it possible to use that compiler instead of gcc to
> compile PostgreSQL to get a faster PostgreSQL by taking advantage of
> Sun's C compiler producing a faster executable?
>
> We probably all have heard about Oracle's Linux distribution.
> Does
> Oracle's Linux distro provide better PostgreSQL/ RDBMS performance over
> Solaris 10 or Redhat distros?

Test it on your workload and tell us.

>
> regards,
>
> karen

news@buffy.sighup.org.uk wrote:

> Which is taller, a horse or a zebra?
>
> The question is impossible to even begin to answer without knowing a lot
> more about the problem you are trying to solve.
>
> In general, databases are not CPU limited. Memory and disk speed are
> usually the limiting factors.
>

But of course, this is well known. Hopefully, my post did not read
like I was trying to compare the operating systems on different
hardware. Solaris 10 runs quite nicely on x86. For instance, let us
say we have one x86 AMD server where we triple boot into Windows, Linux
and Solaris 10 to do the performance tests.

There should be an operating system that would have superior
performance on that x86 AMD Opteron server even if the results
(are/could) be close.

regards,
karen

The Natural Philosopher wrote:

>
> Hear hear..and there is a lot you can tune..best way to get a DB to fly
> is to have terabytes of disk caching.

Is disk caching a good idea? IIRC, when browsing through the postgres
developers list, I read a few developers lament that many disks lie
about the completion status of a write because of caching...

In fact, if I understand it well, at least on postgresql, is it not
better to have many smaller sized disks (that instead of one big one)
that don't cache. This way one can use tablespaces and partial indexes
to split the tables up among the disks that way the rdbms doesn't have
to wait for just one disk to make a complete revolution around.

Things like IO in this situation would make an efficient operating
system perform better would you think?

regards,

karen

Karen Hill wrote:
> news@buffy.sighup.org.uk wrote:
>
>
>>Which is taller, a horse or a zebra?
>>
>>The question is impossible to even begin to answer without knowing a lot
>>more about the problem you are trying to solve.
>>
>>In general, databases are not CPU limited. Memory and disk speed are
>>usually the limiting factors.
>>
>
>
> But of course, this is well known. Hopefully, my post did not read
> like I was trying to compare the operating systems on different
> hardware. Solaris 10 runs quite nicely on x86. For instance, let us
> say we have one x86 AMD server where we triple boot into Windows, Linux
> and Solaris 10 to do the performance tests.
>
> There should be an operating system that would have superior
> performance on that x86 AMD Opteron server even if the results
> (are/could) be close.
>
But on which workload?

To know which combination works best for you, you have to do the tests.

--
Ian Collins.

In <1162862894.104440.185460@h48g2000cwc.googlegroups .com> "Karen Hill" <karen_hill22@yahoo.com> writes:

>news@buffy.sighup.org.uk wrote:

>> The question is impossible to even begin to answer without knowing a lot
>> more about the problem you are trying to solve.

>But of course, this is well known. Hopefully, my post did not read
>like I was trying to compare the operating systems on different
>hardware. Solaris 10 runs quite nicely on x86. For instance, let us
>say we have one x86 AMD server where we triple boot into Windows, Linux
>and Solaris 10 to do the performance tests.

>There should be an operating system that would have superior
>performance on that x86 AMD Opteron server even if the results
>(are/could) be close.

Such benchmarks have been done. Each OS was better in some areas and
poorer on others. Most of the time, the differences were not
significant. In general, any well-designed operating system will only
be a minor factor in performance tests. It will be the hardware that
limits performance. You should choose the operating system based on
criteria other than performance.


--
-Gary Mills- -Unix Support- -U of M Academic Computing and Networking-

Karen Hill wrote:
> The Natural Philosopher wrote:
>
>> Hear hear..and there is a lot you can tune..best way to get a DB to fly
>> is to have terabytes of disk caching.
>
> Is disk caching a good idea? IIRC, when browsing through the postgres
> developers list, I read a few developers lament that many disks lie
> about the completion status of a write because of caching...
>
They all do.

That doesn't matter, as long as the writes complete before the machine
crashes :-)

> In fact, if I understand it well, at least on postgresql, is it not
> better to have many smaller sized disks (that instead of one big one)
> that don't cache.

Many smaller is good as it gives better seek times on random access. But
still cache. Also if RAIDED more resilient.

At least always put the transaction log on a separate disk anyway.


> This way one can use tablespaces and partial indexes
> to split the tables up among the disks that way the rdbms doesn't have
> to wait for just one disk to make a complete revolution around.

Most disk drivers will do read ahead caching anyway. That plus LRU
caching will mean that large areas of the disk - usually indexes and the
like- will be in RAM anyway.

>
> Things like IO in this situation would make an efficient operating
> system perform better would you think?
>

Yes, but there are greater variations within drivers *within* an
operating system than *between* OS's.

We had a system running on a SCO box years ago....dog slow till we got
the disk caching up to monumental proportions and added indices to
reflect the searches we mostly did. On the SAME OS, kernel tuning and db
indexing made 100:1 difference. All down to optimising disk access.



> regards,
>
> karen
>

Karen Hill wrote:

> news@buffy.sighup.org.uk wrote:
>
>
>>Which is taller, a horse or a zebra?
>>
>>The question is impossible to even begin to answer without knowing a lot
>>more about the problem you are trying to solve.
>>
>>In general, databases are not CPU limited. Memory and disk speed are
>>usually the limiting factors.
>>
>
>
> But of course, this is well known. Hopefully, my post did not read
> like I was trying to compare the operating systems on different
> hardware. Solaris 10 runs quite nicely on x86. For instance, let us
> say we have one x86 AMD server where we triple boot into Windows, Linux
> and Solaris 10 to do the performance tests.
>
> There should be an operating system that would have superior
> performance on that x86 AMD Opteron server even if the results
> (are/could) be close.
>
> regards,
> karen
>

Doing the tests is worth days or weeks of speculation!!

"Gary Mills" <mills@cc.umanitoba.ca> wrote in message
news:eios6h$eff$1@canopus.cc.umanitoba.ca...
> In <1162862894.104440.185460@h48g2000cwc.googlegroups .com> "Karen Hill"
> <karen_hill22@yahoo.com> writes:

> Such benchmarks have been done. Each OS was better in some areas and
> poorer on others. Most of the time, the differences were not
> significant. In general, any well-designed operating system will only
> be a minor factor in performance tests. It will be the hardware that
> limits performance. You should choose the operating system based on
> criteria other than performance.

But if performance is all your after, the software and algorithms used
becomes key over hardware.

I once had the opportunity to port a mainframe application in modula 2 (?)
many years ago. The first thing I noticed was the method used was not
optimal. It took 4 hours on a mainframe. So I ported it to C a 286 PC
running SCO changing the algorithm in which it was based on. It took 10
minutes. Today, on Linux it is only a few seconds.

But I am assuming messing with the software is an option. In which case if
software is not an option, then your hardware is the best bet.

The Natural Philosopher wrote (in part):

>> This way one can use tablespaces and partial indexes
>> to split the tables up among the disks that way the rdbms doesn't have
>> to wait for just one disk to make a complete revolution around.
>
> Most disk drivers will do read ahead caching anyway. That plus LRU
> caching will mean that large areas of the disk - usually indexes and the
> like- will be in RAM anyway.
>
The hard drives I use all have 8 Megabyte cache buffers built right into the
hard drive. For output, this makes a lot of sense because the drive can
signal complete as soon as the data are in the buffer and then let the drive
do whatever seeking and waiting for rotational latency time at leisure.

But on input, it is not so clear how to profitably do read ahead, since the
drive does not know how the file system is organized. If the computer asks
for sector 1, 2, and 3, is there any point in reading the rest of the
cylinder or track? After the drive notices that a few sectors have been read
sequentially, it could read more. But if the file system is a little
fragmented, probably the next block is not 4, but 571. And on
multiprogramming systems, even if one process is reading sequentially, all
the other processes will be moving the heads around and the drive itself
will have difficulty recognizing sequential access even if, from the
point-of-view of any one process, that is what is happening.

Now decent disk drivers, and I suppose the drives themselves if they do
command queuing, can accumulate a bunch of IO commands and apply an elevator
algorithm to optimize seeking. They can also speculate and read an entire
track or cylinder whenever an IO request comes along on speculation. And
with the large memory sizes on computers these days, that is not a bad use
of RAM.

It is not clear to me that the indices will be in RAM unless you have a lot
of it. In IBM's DB2, I set it up like this in the hope of getting the main
indices into RAM. The machine has 8 GBytes RAM, but any one process can see
only 4 GBytes because this is a 32-bit machine with 2 Hyperthreaded Xeon
processors. The page size is 4096 bytes

-- CREATE buffer pool for STOCK_DATA: 102,400,000 bytes.
-- SIZE in pages.
CREATE BUFFERPOOL BP_STOCK_DATA
SIZE 25000;

-- CREATE buffer pool for STOCK_INDICES: 819,200,000 bytes.
-- SIZE in pages.
-- Large because we hope to get entire index into memory sometimes.
CREATE BUFFERPOOL BP_STOCK_INDICES
SIZE 200000;

-- CREATE DMS space for STOCK_DATA.
-- STOCK_DATA are on three drives, so we try 3 extents of prefetch.
-- EXTENTSIZE in pages; PREFETCHSIZE in pages.
CREATE TABLESPACE STOCK_DATA
MANAGED BY DATABASE
USING (DEVICE '/dev/raw/raw1' 2048279,
DEVICE '/dev/raw/raw2' 2048279,
DEVICE '/dev/raw/raw3' 2048279
)
EXTENTSIZE 32 PREFETCHSIZE 96
BUFFERPOOL BP_STOCK_DATA
OVERHEAD 7.5 TRANSFERRATE 0.12;

-- CREATE DMS space for STOCK_INDICES.
-- STOCK_INDICES are on one drive, so we try one extent of prefetch.
-- EXTENTSIZE in pages; PREFETCHSIZE in pages.
CREATE TABLESPACE STOCK_INDICES
MANAGED BY DATABASE
USING (DEVICE '/dev/raw/raw4' 3976087
)
EXTENTSIZE 64 PREFETCHSIZE 64
BUFFERPOOL BP_STOCK_INDICES
OVERHEAD 7.5 TRANSFERRATE 0.12;

By doing this, I have gotten it so that the logfile (on a different drive
from these 4 (that are on SCSI drives) is the IO bottleneck. I am planning
to replace the EIDE drive for the logfile with a 10,000rpm SCSI drive when I
get around to it. I already have the drive on the shelf.

BTW: This DB2 system is set up to do RAW IO; i.e., it skips the Linux file
system, but it does use the Linux device drivers. This allows it to skip
core-to-core copies, allocate disk contiguously, and do IO in chunks of 32
or 64 page extents (131072 bytes or 262144 bytes) that are contiguous.

--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 11:05:01 up 17 days, 13:33, 3 users, load average: 4.08, 4.21, 4.11