Memory on 32bit machine

On Mon, Jan 07, 2008 at 10:32:26AM +0100, mljv@planwerk6.de wrote:

So assuming i could choose between 4 GB RAM and 8 GB RAM and 32bit debian and
64bit debian. Which option would you choose?

Always go for more RAM, whether you use 64 or 32-bit is really
orthoginal to that, whatever memory you have left you will be
profitably used as diskcache. Postgres does not need to be able to
access the memory directly to be able to use it...

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

Am Montag, 7. Januar 2008 11:48 schrieb Martijn van Oosterhout:

On Mon, Jan 07, 2008 at 10:32:26AM +0100, mljv@planwerk6.de wrote:

So assuming i could choose between 4 GB RAM and 8 GB RAM and 32bit debian
and 64bit debian. Which option would you choose?

Always go for more RAM, whether you use 64 or 32-bit is really
orthoginal to that, whatever memory you have left you will be
profitably used as diskcache. Postgres does not need to be able to
access the memory directly to be able to use it...

thanks a lot for this immediate reply and crystal clear answer. I will go for
more RAM now.

kind regards,
janning

Or would you rather vote for 64bit because there are no problems
anymore and postgresql runs fine on 64bit debian.

We haven't run into any trouble with iptables on Debian etch, running
on amd64 hardware. But we use only fairly standard iptables
functionality.

--
Florian Weimer <fweimer@bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

Am Montag, 7. Januar 2008 12:56 schrieb Florian Weimer:

Or would you rather vote for 64bit because there are no problems
anymore and postgresql runs fine on 64bit debian.

We haven't run into any trouble with iptables on Debian etch, running
on amd64 hardware. But we use only fairly standard iptables
functionality.

ok, thanks for this information. It was sarge when i used iptables with 64bit
kernel and it even failed to start up.so i'll might give 64bit another try.

Are there any other recommendations whether to use 64bit or 32bit OS with
postgresql? I just want to use 64bit if it as stable as 32bit.

kind regards,
janning

mljv@planwerk6.de wrote:

Am Montag, 7. Januar 2008 12:56 schrieb Florian Weimer:

Or would you rather vote for 64bit because there are no problems
anymore and postgresql runs fine on 64bit debian.

We haven't run into any trouble with iptables on Debian etch, running
on amd64 hardware. But we use only fairly standard iptables
functionality.

ok, thanks for this information. It was sarge when i used iptables with 64bit
kernel and it even failed to start up.so i'll might give 64bit another try.

Are there any other recommendations whether to use 64bit or 32bit OS with
postgresql? I just want to use 64bit if it as stable as 32bit.

I'm curious as to why you would run iptables on a database server. My
expectation would be that your database machine would be behind a
dedicated firewall.

--
Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin

Geoffrey wrote:

mljv@planwerk6.de wrote:

Am Montag, 7. Januar 2008 12:56 schrieb Florian Weimer:

Or would you rather vote for 64bit because there are no problems
anymore and postgresql runs fine on 64bit debian.

We haven't run into any trouble with iptables on Debian etch, running
on amd64 hardware. But we use only fairly standard iptables
functionality.

ok, thanks for this information. It was sarge when i used iptables
with 64bit kernel and it even failed to start up.so i'll might give
64bit another try.

Are there any other recommendations whether to use 64bit or 32bit OS
with postgresql? I just want to use 64bit if it as stable as 32bit.

I'm curious as to why you would run iptables on a database server. My
expectation would be that your database machine would be behind a
dedicated firewall.

Why not? Security in layers and all that. :)

--
Postgresql & php tutorials
http://www.designmagick.com/

Chris wrote:

Are there any other recommendations whether to use 64bit or 32bit OS
with postgresql? I just want to use 64bit if it as stable as 32bit.

I'm curious as to why you would run iptables on a database server. My
expectation would be that your database machine would be behind a
dedicated firewall.

Why not? Security in layers and all that. :)

Certainly and iptables gives you some flexibility in connection
availability "before" it hits the actual database but without having to
jimmy the production firewall.

Joshua D. Drake

On Mon, 7 Jan 2008, Joshua D. Drake wrote:

Certainly and iptables gives you some flexibility in connection availability
"before" it hits the actual database but without having to jimmy the
production firewall.

It's worth emphasizing that in many environments, it's far more likely one
will have root access to configure the local firewall on a database server
than access to the main company firewall. It's not unusual for DBAs to
have root on their servers, but nobody wants a DBA making Cisco IOS
changes. If you've got a recipe cookbook of common firewall requirements
it's reasonable for a DBA to handle some of that maintenance without
having to go to another department or otherwise call something else in.

There are a bunch of other reasons why you might use a local firewall like
iptables on top of both a firewall and the PostgreSQL security:

1) Securing against other sections of the internal LAN, which may not be
completely trusted for your database application even though they're on
your company's network. Anybody who gets a system plugged in behind the
firewall is a potential attacker, and you can't expect the firewall to do
all the securing for you.

2) Providing some homogenous connection security to what's done on other
systems instead of or addition to the restrictions you can put into
pg_hba.conf. If you've got a security auditer who knows iptables because
it's used on all the Linux machines, but not PostgreSQL, they're much more
likely to give you a thumbs-up if it's obvious the system is secured on
the network level before they even consider the database security.

3) The OS kernel will be more efficient in blocking unwanted packets than
the database server can be, making it less like you'll be victim to a
denial of service against the database from a host that shouldn't be
allowed to connect anyway.

4) Funky tricks with things like port forwarding and filtering that you
can't do with PostgreSQL alone, and that need to be active for people in
the internal LAN. I recall this one time where I needed the database port
to be different based on which of the local subnets the connection was
coming through (it was a version migration thing). Those were some fun
ipchains rules (yeah, that long ago) and I'd have been hard pressed to do
that on the firewall instead without a major contortion to the network.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

Greg Smith wrote:

On Mon, 7 Jan 2008, Joshua D. Drake wrote:

Certainly and iptables gives you some flexibility in connection
availability "before" it hits the actual database but without having
to jimmy the production firewall.

4) Funky tricks with things like port forwarding and filtering that you
can't do with PostgreSQL alone, and that need to be active for people in
the internal LAN. I recall this one time where I needed the database
port to be different based on which of the local subnets the connection
was coming through (it was a version migration thing). Those were some
fun ipchains rules (yeah, that long ago) and I'd have been hard pressed
to do that on the firewall instead without a major contortion to the
network.

Some people won't like this but... packet shaping and bandwidth control
as well.

Joshua D. Drake

On Mon, 07 Jan 2008 20:56:49 -0800
"Joshua D. Drake" <jd@commandprompt.com> wrote:

Some people won't like this but... packet shaping and bandwidth
control as well.

Isn't there a native way to allocate postgresql resources accordingly
to the user?
Won't traffic shaping place "on hold" things that are already
finished in stand by slowing the whole system?
I know you can limit requests and let responses run free, but what if
they are asking back 1M record with a simple query?

thx

--
Ivan Sergio Borgonovo
http://www.webthatworks.it