My client has some SUN server type SUN Server Enterprise4500 (64bits).

He proposes me to install Postgresql on his server instead of buying a Dell Server Poweredge 4600 (32bits)

What is the difference in terms of installation, running and maintenance of installing postgresql on a 64bit server than on a 32bit server.

Is the difference only at the OS level which is redhat or are there impacts on the database ?

Thank you for you help and experience.

GH






My client has some SUN server type SUN Server Enterprise4500 
(64bits).
 
He proposes me to install Postgresql on his server 
instead of buying a Dell Server Poweredge 4600 (32bits)
 
What is the difference in terms of installation, 
running and maintenance of installing postgresql on a 64bit server than on a 
32bit server.
 
Is the difference only at the OS level which is 
redhat or are there impacts on the database ?
 
Thank you for you help and experience.
 
GH
Fri, 23 May 2003 21:49:14 +0200
"Guillaume Houssay" <ghoussay@noos.fr>
Postgresql on SUN Server
On Fri, 23 May 2003, Guillaume Houssay wrote:

> My client has some SUN server type SUN Server Enterprise4500 (64bits).
> 
> He proposes me to install Postgresql on his server instead of buying a 
> Dell Server Poweredge 4600 (32bits)

Depending on the how many CPUs it has and what not, the E4500 may not be 
much faster, or may even be slower.  but it should be rock solid reliable, 
the E seris are nearly bulletproof hardware.

> What is the difference in terms of installation, running and 
> maintenance of installing postgresql on a 64bit server than on a 32bit 
> server.

None really.  You may as well set --enable-integer-datetimes when 
compiling since there should be no great performance penalty for running 
64 bit values for datetime.

Other than that, no great difference.  note that being on 64 bit hardware 
means you can likely have much more shared buffer memory than on X86 
hardware, where you're limited to ~2 gig.

> Is the difference only at the OS level which is redhat or are there 
> impacts on the database ?

Mostly the OS.  I know RedHat had dropped their Sparc line, but there is a 
project out there (can't recall the name, but you can google for it) that 
'ports' RedHat's releases to Sparc hardware.

Debian maintains a Sparc port if you want to use debian.


Fri, 23 May 2003 14:01:04 -0600 (MDT)
"scott.marlowe" <scott.marlowe@ihs.com>
Re: Postgresql on SUN Server
On Vie 23 May 2003 17:01, scott.marlowe wrote:
>
> None really.  You may as well set --enable-integer-datetimes when
> compiling since there should be no great performance penalty for
> running 64 bit values for datetime.
>
> Other than that, no great difference.  note that being on 64 bit
> hardware means you can likely have much more shared buffer memory than
> on X86 hardware, where you're limited to ~2 gig.

Those this mean no more the ~2Gig total shared memory? Or each aplication?

> > Is the difference only at the OS level which is redhat or are there
> > impacts on the database ?
>
> Mostly the OS.  I know RedHat had dropped their Sparc line, but there
> is a project out there (can't recall the name, but you can google for
> it) that 'ports' RedHat's releases to Sparc hardware.

http://auroralinux.org/

> Debian maintains a Sparc port if you want to use debian.

Here we are starting to use Debian, but due to the fact that one of the 
Admins has switched to it. And you know how fundamentalists they are! :-)

Saludos... :-)

-- 
Porquï¿½ usar una base de datos relacional cualquiera,
si podï¿½s usar PostgreSQL?
-----------------------------------------------------------------
Martï¿½n Marquï¿½s                  |        mmarques@unl.edu.ar
Programador, Administrador, DBA |       Centro de Telematica
                       Universidad Nacional
                            del Litoral
-----------------------------------------------------------------


Sat, 24 May 2003 10:50:17 -0300
Martin Marques <martin@bugs.unl.edu.ar>
Re: Postgresql on SUN Server
On Sat, 24 May 2003, Martin Marques wrote:

> On Vie 23 May 2003 17:01, scott.marlowe wrote:
> >
> > None really.  You may as well set --enable-integer-datetimes when
> > compiling since there should be no great performance penalty for
> > running 64 bit values for datetime.
> >
> > Other than that, no great difference.  note that being on 64 bit
> > hardware means you can likely have much more shared buffer memory than
> > on X86 hardware, where you're limited to ~2 gig.
> 
> Those this mean no more the ~2Gig total shared memory? Or each aplication?

Correct.  The max shared memory segment on 64 bit hardware is larger than 
any amount of RAM currently installable.  I'm pretty sure the limit is 
so large that the overhead of handling a large segment would become a 
problem long before you'd be able to hit a hard limit.

> 
> > > Is the difference only at the OS level which is redhat or are there
> > > impacts on the database ?
> >
> > Mostly the OS.  I know RedHat had dropped their Sparc line, but there
> > is a project out there (can't recall the name, but you can google for
> > it) that 'ports' RedHat's releases to Sparc hardware.
> 
> http://auroralinux.org/

Thanks for the link, I was looking for it and couldn't find it just a day 
or two after seeing it.

> > Debian maintains a Sparc port if you want to use debian.
> 
> Here we are starting to use Debian, but due to the fact that one of the 
> Admins has switched to it. And you know how fundamentalists they are! :-)

Oh yes.  Right up there with some of the "Solaris on X86" folks I've met.



Tue, 27 May 2003 09:05:07 -0600 (MDT)
"scott.marlowe" <scott.marlowe@ihs.com>
Re: Postgresql on SUN Server
I am trying to divide the buffer pool into 5 parts and i call these
clusters (different from postgres db clusters). What i want to do is to
make a mapping from the relations to these clusters. One relation belongs
to one cluster and a cluster can obviously have more than one relations. I
use a hash table to do this similar to the buf_table.c file. Right now i
don't know how many relations there are in total. I have just initialized
it to 100. The key is relation and the data is the cluster information.
Can anyone see any problems in using this approach.
Feed back will be greatly appreciated.

PS i am aware that because of OS caching this may not cause any
improvements.

thanks
nailah



Tue, 27 May 2003 11:41:50 -0400 (EDT)
Nailah Ogeer <ogeer@cs.queensu.ca>
Relation hash table
On Tue, May 27, 2003 at 09:05:07AM -0600, scott.marlowe wrote:
> Correct.  The max shared memory segment on 64 bit hardware is larger than 
> any amount of RAM currently installable.  I'm pretty sure the limit is 
> so large that the overhead of handling a large segment would become a 
> problem long before you'd be able to hit a hard limit.

Given that, in my experience, 1 Gig of shared buffer space totally
tanked performance on Solaris 7, the limiti is already so large that
handling a large segment is a problem ;-)

A

----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M2P 2A8
                                         +1 416 646 3304 x110


Tue, 27 May 2003 13:07:10 -0400
Andrew Sullivan <andrew@libertyrms.info>
Re: Postgresql on SUN Server
On Tue, 27 May 2003, Andrew Sullivan wrote:

> On Tue, May 27, 2003 at 09:05:07AM -0600, scott.marlowe wrote:
> > Correct.  The max shared memory segment on 64 bit hardware is larger than 
> > any amount of RAM currently installable.  I'm pretty sure the limit is 
> > so large that the overhead of handling a large segment would become a 
> > problem long before you'd be able to hit a hard limit.
> 
> Given that, in my experience, 1 Gig of shared buffer space totally
> tanked performance on Solaris 7, the limiti is already so large that
> handling a large segment is a problem ;-)

I wonder if that's a performance issue with Solaris and shared memory that 
isn't a problem with BSD or Linux on Sparc Hardware?


Tue, 27 May 2003 12:07:06 -0600 (MDT)
"scott.marlowe" <scott.marlowe@ihs.com>
Re: Postgresql on SUN Server
Hi,
Having some problems. So i installed 7.3.2. I got up to running the
server in the background. I am not sure if what i am doing next is
corrext. I cd into the pgsql/bin folder and run createdb mydb. here's my
error message:

createdb mydb
ld.so.1: ./psql: fatal: libgcc_s.so.1: open failed: No such file or
directory
Killed
createdb: database creation failed

Can some one explain to me why it is doing this and what i can do to fix
it?
thanks



Tue, 27 May 2003 14:30:22 -0400 (EDT)
Nailah Ogeer <ogeer@cs.queensu.ca>
libgcc_s.so.1 not found
On Tue, May 27, 2003 at 12:07:06PM -0600, scott.marlowe wrote:
> I wonder if that's a performance issue with Solaris and shared memory that 
> isn't a problem with BSD or Linux on Sparc Hardware?

I wonder that, also.  I haven't had a chance to try it out.

The problem in our case is that we couldn't use Linux or BSD anyway,
because we need the 8- and 10-way scalability we have, and we need
the cleverness about disabling processors, &c., that's built into
Solaris.  So even if Solaris is the problem, we're stuck.

The file system buffers, on the other hand, are pretty fast, so it's
not too big a penalty.

One thing that is very interesting about all of this is that the
large shared buffers only exact their performance penalty over time. 
My hypothesis is that it has something to do with expiring buffers. 
In one test I performed, I set the buffer to 1G.  I then did a bunch
of work on a data set that was close to 1G.  Speedy.  But when I
finally went over 1G, everything slowed to a crawl.  This makes me
believe that the problem is in the way records are added to or
expired from the buffer.

It was only one test, mind: I didn't have time to repeat it.  So it's
just a bit of gossip and not a result.

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M2P 2A8
                                         +1 416 646 3304 x110


Tue, 27 May 2003 15:05:35 -0400
Andrew Sullivan <andrew@libertyrms.info>
Re: Postgresql on SUN Server
Looks as if your local or postgres user doesn't have a
$LD_LIBRARY_PATH that includes libgcc_s.so.1.

Find the library on your system, and modify the profile
of the user to make sure they have in in $LD_LIBRARY_PATH.

If you are running on the same system that you built postgresql
on, the library is there somewhere....

Nailah Ogeer wrote:
> Hi,
> Having some problems. So i installed 7.3.2. I got up to running the
> server in the background. I am not sure if what i am doing next is
> corrext. I cd into the pgsql/bin folder and run createdb mydb. here's my
> error message:
> 
> createdb mydb
> ld.so.1: ./psql: fatal: libgcc_s.so.1: open failed: No such file or
> directory
> Killed
> createdb: database creation failed

-- 
P. J. "Josh" Rovero                                 Sonalysts, Inc.
Email: rovero@sonalysts.com    www.sonalysts.com    215 Parkway North
Work: (860)326-3671 or 442-4355                     Waterford CT 06385
***********************************************************************


Tue, 27 May 2003 15:18:00 -0400
"P.J. \"Josh\" Rovero" <rovero@sonalysts.com>
Re: libgcc_s.so.1 not found
On Tue, 27 May 2003, Andrew Sullivan wrote:

> On Tue, May 27, 2003 at 12:07:06PM -0600, scott.marlowe wrote:
> > I wonder if that's a performance issue with Solaris and shared memory that 
> > isn't a problem with BSD or Linux on Sparc Hardware?
> 
> I wonder that, also.  I haven't had a chance to try it out.
> 
> The problem in our case is that we couldn't use Linux or BSD anyway,
> because we need the 8- and 10-way scalability we have, and we need
> the cleverness about disabling processors, &c., that's built into
> Solaris.  So even if Solaris is the problem, we're stuck.
> 
> The file system buffers, on the other hand, are pretty fast, so it's
> not too big a penalty.
> 
> One thing that is very interesting about all of this is that the
> large shared buffers only exact their performance penalty over time. 
> My hypothesis is that it has something to do with expiring buffers. 
> In one test I performed, I set the buffer to 1G.  I then did a bunch
> of work on a data set that was close to 1G.  Speedy.  But when I
> finally went over 1G, everything slowed to a crawl.  This makes me
> believe that the problem is in the way records are added to or
> expired from the buffer.
> 
> It was only one test, mind: I didn't have time to repeat it.  So it's
> just a bit of gossip and not a result.

Thanks for the gossip.  I tested Postgresql with ~1 gig of shared space 
under RH 7.2 and found that while it WAS slower than say with 512 Meg of 
ram, it was only slower when you weren't using more than 512Meg.  If I was 
doing something that was larger than 512Meg and smaller than 1 Gig, using 
1 gig shared was still faster, but not by much.  It didn't seem to slow 
down a lot going over the max shared_buffers memory, but we don't have any 
really huge datasets, so I didn't test all that thourougly at that 
setting, as the performance gain wasn't all that great for large sets, and 
noticeably slower for medium size datasets.

I just think SYSV shared memory isn't built for handling large amounts of 
memory.

I could stand out here at the fence and chat all day... :-)



Tue, 27 May 2003 14:08:12 -0600 (MDT)
"scott.marlowe" <scott.marlowe@ihs.com>
Re: Postgresql on SUN Server
* scott.marlowe (scott.marlowe@ihs.com) wrote:
> On Fri, 23 May 2003, Guillaume Houssay wrote:
> 
> Mostly the OS.  I know RedHat had dropped their Sparc line, but there is a 
> project out there (can't recall the name, but you can google for it) that 
> 'ports' RedHat's releases to Sparc hardware.
> 

Redhat sparc became aurora linux.  I'm currently running it on both 32
and 64bit systems without problems.

dan

Tue, 27 May 2003 14:35:27 -0600
dan radom <dan@radom.org>
Re: Postgresql on SUN Server
On Tue, May 27, 2003 at 02:08:12PM -0600, scott.marlowe wrote:

> I just think SYSV shared memory isn't built for handling large amounts of 
> memory.

That's sort of my feeling, too, and corresponds with something Tom
Lane said recently on -performance (where I guess this oughta move)
to the effect that, since OS guys have spent years and (in some
cases) millions of dollars optimising the filesystem buffer
algorithms; and since he tried one time to alter the PostgreSQL
buffer management algorithm, and that attempt was unsuccessful;
therefore there is bound to be some point of diminishing returns in
increasing the postmaster's shared buffers, and that point is likely
to show up sooner rather than later.

> I could stand out here at the fence and chat all day... :-)

Me, too, but the fields keep a-growin'.

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M2P 2A8
                                         +1 416 646 3304 x110


Tue, 27 May 2003 17:03:50 -0400
Andrew Sullivan <andrew@libertyrms.info>
Re: Postgresql on SUN Server
On 27 May 2003 at 15:05, Andrew Sullivan wrote:

> On Tue, May 27, 2003 at 12:07:06PM -0600, scott.marlowe wrote:
> > I wonder if that's a performance issue with Solaris and shared memory that 
> > isn't a problem with BSD or Linux on Sparc Hardware?
> 
> I wonder that, also.  I haven't had a chance to try it out.
> 
> The problem in our case is that we couldn't use Linux or BSD anyway,
> because we need the 8- and 10-way scalability we have, and we need
> the cleverness about disabling processors, &c., that's built into
> Solaris.  So even if Solaris is the problem, we're stuck.

I have no experience on solaris or SMP machines so just putting a hypothesis..

You may still run linux on a 8-10 way sparc. With O(1) patches available for 
2.4 series, it should scale much more gracefully than earlier. It may not touch 
solaris in scalability and fine grained resource control like disabling a 
processor, but all in all, might be faster in performance vis-a-vis solaris.

At least it doesn't hurt trying if you can spare time and resources. Many 
people say that linux outperform solaris on 1way/2way machines. If you could 
find out what happens at 8 way, it would be great..:-)

 
Bye
 Shridhar

--
H. L. Mencken's Law:	Those who can -- do.	Those who can't -- teach.Martin's 
Extension:	Those who cannot teach -- administrate.


Wed, 28 May 2003 11:59:48 +0530
"Shridhar Daithankar" <shridhar_daithankar@persistent.co.in>
Re: Postgresql on SUN Server
Andrew Sullivan wrote:

> One thing that is very interesting about all of this is that the
> large shared buffers only exact their performance penalty over time. 
> My hypothesis is that it has something to do with expiring buffers. 
> In one test I performed, I set the buffer to 1G.  I then did a bunch
> of work on a data set that was close to 1G.  Speedy.  But when I
> finally went over 1G, everything slowed to a crawl.  This makes me
> believe that the problem is in the way records are added to or
> expired from the buffer.
> 
> It was only one test, mind: I didn't have time to repeat it.  So it's
> just a bit of gossip and not a result.

Interesting. We encountered a similar issue, but on Red Hat Advanced 
Server 2.1.

Specs:
Linux 2.4.9-e.3smp (Red Hat's tweaks on Linux 2.4.9)
Dual P4 Xeon 2.4GHz
1.5 GB of RAM
shared_buffers = 32768 (about 256 Megs)
PostgreSQL 7.3.2 compiled from source.
Never used swap.

Performance seems speedy initially, but after, a few days or some large 
data migration and processing operations, things slowed to a crawl, esp. 
on INSERTs. Little disk or CPU activity. Did the usual dead chicken 
waving: VACUUM, ANALYZE, REINDEX, dump&restore, restart postgresql. No 
luck. Reboot, and everything's back to normal. Annoying.

It's a repeatable phenomenon, though we can't figure out the cause: the 
old-ish O.S., or the shared memory fragmentation(?) or just plain unlucky.

We've kept some vmstat and other details. Bug me if anyone's interested.

-- 
Linux homer 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386 
GNU/Linux
   2:59pm  up 153 days,  5:46, 11 users,  load average: 3.81, 4.73, 5.65
Wed, 28 May 2003 15:51:07 +0800
Ang Chin Han <angch@bytecraft.com.my>
Re: Postgresql on SUN Server