Обсуждение: Memory on 32bit machine
Hi, i have the option to upgrade to a new dedicated database server with 8 GB Ram i want to run on debian linux 32bit because i had some trouble the last time i used 64bit with iptables which did not work (i guess it was a year ago...) 8GB are addressable as far as i know with a bigmem kernel. Does it make sense to run a dedicated postgresql server with 32bit linux and 8GB RAM? Or would you rather vote for 64bit because there are no problems anymore and postgresql runs fine on 64bit debian. So assuming i could choose between 4 GB RAM and 8 GB RAM and 32bit debian and 64bit debian. Which option would you choose? If you recommend 64bit (and obvisiouly 8GB), are there any pitfalls or hints? kind regards, janning
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/ > Those who make peaceful revolution impossible will make violent revolution inevitable. > -- John F Kennedy
Вложения
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 > > -- > * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD > > ---------------------------(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 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