Обсуждение: several postgres installations on the same machine?

----- Original Message -----

From: Anoo Sivadasan Pillai

To: Zlatko Matić

Cc: pgsql-general@postgresql.org

Sent: Friday, July 20, 2007 8:40 AM

Subject: Re: [GENERAL] several postgres installations on the same machine?

If you mean multiple instances, Then it can be.

Have a look on Pauls personal Blog

 

http://people.planetpostgresql.org/paul/index.php?/archives/4-Running-a-Second-Instance-of-PostgreSQL-8.1.4-on-Windows-2003.html

 

Anoo S Pillai

---

From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Zlatko Matic
Sent: Friday, July 20, 2007 11:51 AM
To: pgsql-general@postgresql.org
Subject: [GENERAL] several postgres installations on the same machine?

 

Is it possible to have few independant PostgreSQL 8.2 installations on the same PC, WIndows XP?

Thanks,

 

Zlatko

Visit our Website at www.rmesi.co.in

This message is confidential. You should not copy it or disclose its contents to anyone. You may use and apply the information for the intended purpose only. Internet communications are not secure; therefore, RMESI does not accept legal responsibility for the contents of this message. Any views or opinions presented are those of the author only and not of RMESI. If this email has come to you in error, please delete it, along with any attachments. Please note that RMESI may intercept incoming and outgoing email communications.

Freedom of Information Act 2000
This email and any attachments may contain confidential information belonging to RMESI. Where the email and any attachments do contain information of a confidential nature, including without limitation information relating to trade secrets, special terms or prices these shall be deemed for the purpose of the Freedom of Information Act 2000 as information provided in confidence by RMESI and the disclosure of which would be prejudicial to RMESI's commercial interests.

This email has been scanned for viruses by Trend ScanMail.

Hello

PostgreSQL can run with more independent clusters. These clusters can
be related to one binary files or to more (different versions of
postgresql) files. Every cluster has own  configuration. Databases
from one cluster share users, locales, etc.

Windows installer build first cluster automatically. Second and others
clusters have to be created manually with statement initdb. These
clusters will share only dll files. If you wont absolutely independent
installations, then change paths and ports.

Regards
Pavel Stehule

2007/7/20, Zlatko Matić <zlatko.matic1@sb.t-com.hr>:
>
>
> Hi.
> If I understood correctly, this blog describes how to create second instance
> that is linked to first (the same service acount user)?
> But, I want to know whether it is possible to have second instance
> completely independent, not influencing each other?
> Regards,
>
> Zlatko
>
>
> ----- Original Message -----
> From: Anoo Sivadasan Pillai
> To: Zlatko Matić
> Cc: pgsql-general@postgresql.org
> Sent: Friday, July 20, 2007 8:40 AM
> Subject: Re: [GENERAL] several postgres installations on the same machine?
>
>
>
>
> If you mean multiple instances, Then it can be.
>
> Have a look on Pauls personal Blog
>
>
>
>
http://people.planetpostgresql.org/paul/index.php?/archives/4-Running-a-Second-Instance-of-PostgreSQL-8.1.4-on-Windows-2003.html
>
>
>
> Anoo S Pillai
>
>  ________________________________
>
>
> From: pgsql-general-owner@postgresql.org
> [mailto:pgsql-general-owner@postgresql.org] On Behalf Of
> Zlatko Matic
> Sent: Friday, July 20, 2007 11:51 AM
> To: pgsql-general@postgresql.org
> Subject: [GENERAL] several postgres installations on the same machine?
>
>
>
>
> Is it possible to have few independant PostgreSQL 8.2 installations on the
> same PC, WIndows XP?
>
>
> Thanks,
>
>
>
>
>
> Zlatko
>
>
> Visit our Website at www.rmesi.co.in
>
> This message is confidential. You should not copy it or disclose its
> contents to anyone. You may use and apply the information for the intended
> purpose only. Internet communications are not secure; therefore, RMESI does
> not accept legal responsibility for the contents of this message. Any views
> or opinions presented are those of the author only and not of RMESI. If this
> email has come to you in error, please delete it, along with any
> attachments. Please note that RMESI may intercept incoming and outgoing
> email communications.
>
> Freedom of Information Act 2000
> This email and any attachments may contain confidential information
> belonging to RMESI. Where the email and any attachments do contain
> information of a confidential nature, including without limitation
> information relating to trade secrets, special terms or prices these shall
> be deemed for the purpose of the Freedom of Information Act 2000 as
> information provided in confidence by RMESI and the disclosure of which
> would be prejudicial to RMESI's commercial interests.
>
> This email has been scanned for viruses by Trend ScanMail.

On Fri, Jul 20, 2007 at 09:24:05AM +0200, Zlatko Matić wrote:
> Hi.
> If I understood correctly, this blog describes how to create second instance that is linked to first (the same
serviceacount user)? 
> But, I want to know whether it is possible to have second instance completely independent, not influencing each
other?
> Regards,

It is, but you need to install it manually. The installer will only permit
one comlpete installation per version. (you can have multiple servers
running of course, but they share the binaries if installed by the
installer)

//Magnus

Zlatko Matić wrote:
> Hi. If I understood correctly, this blog describes how to create
> second instance that is linked to first (the same service acount
> user)? But, I want to know whether it is possible to have second
> instance completely independent, not influencing each other?

Yes, just make sure you give each it's own user account and run it on a
different port (typically default on 5432, next on 5433 etc).
They will of course all compete for resources on the machine, but
otherwise I don't see why Windows should be different from *nix.

Lots of people run multiple different versions on the various
Linux/BSD/Mac OS-X boxes they have, but there's no reason why they
couldn't be the same version.

--
   Richard Huxton
   Archonet Ltd

----- Original Message -----

From: Anoo Sivadasan Pillai

To: Zlatko Matić

Cc: pgsql-general@postgresql.org

Sent: Friday, July 20, 2007 8:40 AM

Subject: Re: [GENERAL] several postgres installations on the same machine?

If you mean multiple instances, Then it can be.

Have a look on Pauls personal Blog

 

http://people.planetpostgresql.org/paul/index.php?/archives/4-Running-a-Second-Instance-of-PostgreSQL-8.1.4-on-Windows-2003.html

 

Anoo S Pillai

---

From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Zlatko Matic
Sent: Friday, July 20, 2007 11:51 AM
To: pgsql-general@postgresql.org
Subject: [GENERAL] several postgres installations on the same machine?

 

Is it possible to have few independant PostgreSQL 8.2 installations on the same PC, WIndows XP?

Thanks,

 

Zlatko

Visit our Website at www.rmesi.co.in

This message is confidential. You should not copy it or disclose its contents to anyone. You may use and apply the information for the intended purpose only. Internet communications are not secure; therefore, RMESI does not accept legal responsibility for the contents of this message. Any views or opinions presented are those of the author only and not of RMESI. If this email has come to you in error, please delete it, along with any attachments. Please note that RMESI may intercept incoming and outgoing email communications.

Freedom of Information Act 2000
This email and any attachments may contain confidential information belonging to RMESI. Where the email and any attachments do contain information of a confidential nature, including without limitation information relating to trade secrets, special terms or prices these shall be deemed for the purpose of the Freedom of Information Act 2000 as information provided in confidence by RMESI and the disclosure of which would be prejudicial to RMESI's commercial interests.

This email has been scanned for viruses by Trend ScanMail.

Hi,

We're trying to figure out why we're getting poor query performance on a particular database running on a 64 bit
Solarisbox.  The info for the poor database is: 

Red Hat Enterprise Linux AS release 4 (Nahant Update 2) Linux vl-sfv40z-001 2.6.9-22.0.2.ELsmp #1 SMP Thu Jan 5
17:11:56EST 2006 x86_64 x86_64 x86_64 GNU/Linux 

16Gb ram.

Postgres version 8.1.2

Database size is about 7 Gigs.

Live lines in config:
----------------------------------------
max_connections = 500
shared_buffers = 21760
work_mem = 2048
max_fsm_pages = 50000
checkpoint_segments = 125
effective_cache_size = 262144  # =2GB typically 8KB each
redirect_stderr = on                    # Enable capturing of stderr into log
log_directory = '/var/log/pglogs'
log_truncate_on_rotation = on           # If on, any existing log file of the same
log_rotation_size = 10240
log_min_duration_statement = 4000
stats_command_string = on
lc_messages = 'en_US.UTF-8'                     # locale for system error message
lc_monetary = 'en_US.UTF-8'                     # locale for monetary formatting
lc_numeric = 'en_US.UTF-8'                      # locale for number formatting
lc_time = 'en_US.UTF-8'                         # locale for time formatting

We've already ruled out an I/O issue.  The disk is running FAST.

We know it's running poorly because when we put a copy of the database on a lesser hardware 32 bit server, it runs TEN
TIMESfaster. 

Here are the relevant issues with the FAST server:

Red Hat Enterprise Linux AS release 4 (Nahant Update 4) Linux vl-filesrv-001 2.6.9-42.0.8.ELsmp #1 SMP Tue Jan 23
13:01:26EST 2007 i686 i686 i386 GNU/Linux 

Dell dual CPU
4GB ram.


Postgres version: 8.2.3

live config lines:

max_connections = 100                   # (change requires restart)
shared_buffers = 24MB                   # min 128kB or max_connections*16kB
max_fsm_pages = 153600          # min max_fsm_relations*16, 6 bytes each
redirect_stderr = on                    # Enable capturing of stderr into log
log_directory = 'pg_log'                # Directory where log files are writtenlog_truncate_on_rotation = on
#If on, any existing log file of the same 
log_rotation_age = 1d                   # Automatic rotation of logfiles will
log_rotation_size = 0                   # Automatic rotation of logfiles will
datestyle = 'iso, mdy'
lc_messages = 'en_US.UTF-8'                     # locale for system error message
lc_monetary = 'en_US.UTF-8'                     # locale for monetary formatting
lc_numeric = 'en_US.UTF-8'                      # locale for number formatting
lc_time = 'en_US.UTF-8'                         # locale for time formatting
--- --- --- ---
I explain the characterization of fast and slow like this:  Slow is taking about ten times longer than fast to execute
thesame query. 

If there's any gotcha here that we're not seeing, please point it out.  I'm flummoxed.

In response to Brian Maguire <bmaguire@vantage.com>:

> Hi,
>
> We're trying to figure out why we're getting poor query performance on a particular database running on a 64 bit
Solarisbox.  The info for the poor database is: 
>
> Red Hat Enterprise Linux AS release 4 (Nahant Update 2) Linux vl-sfv40z-001 2.6.9-22.0.2.ELsmp #1 SMP Thu Jan 5
17:11:56EST 2006 x86_64 x86_64 x86_64 GNU/Linux 
>
> 16Gb ram.
>
> Postgres version 8.1.2

I don't know how you can expect older technology to run faster than
newer, more optimized technology.

>
> Database size is about 7 Gigs.
>
> Live lines in config:
> ----------------------------------------
> max_connections = 500
> shared_buffers = 21760
                   ^^^^^
With 16G of RAM, this is so small as to be laughable.

> work_mem = 2048

This as well.

There's a lot of detail missing, but I wouldn't even try to diagnose any
more until you've tuned those numbers closer to sanity.

Also, did you vacuum analyze prior to running the speed test?

> max_fsm_pages = 50000
> checkpoint_segments = 125
> effective_cache_size = 262144  # =2GB typically 8KB each
> redirect_stderr = on                    # Enable capturing of stderr into log
> log_directory = '/var/log/pglogs'
> log_truncate_on_rotation = on           # If on, any existing log file of the same
> log_rotation_size = 10240
> log_min_duration_statement = 4000
> stats_command_string = on
> lc_messages = 'en_US.UTF-8'                     # locale for system error message
> lc_monetary = 'en_US.UTF-8'                     # locale for monetary formatting
> lc_numeric = 'en_US.UTF-8'                      # locale for number formatting
> lc_time = 'en_US.UTF-8'                         # locale for time formatting
>
> We've already ruled out an I/O issue.  The disk is running FAST.
>
> We know it's running poorly because when we put a copy of the database on a lesser hardware 32 bit server, it runs
TENTIMES faster. 
>
> Here are the relevant issues with the FAST server:
>
> Red Hat Enterprise Linux AS release 4 (Nahant Update 4) Linux vl-filesrv-001 2.6.9-42.0.8.ELsmp #1 SMP Tue Jan 23
13:01:26EST 2007 i686 i686 i386 GNU/Linux 
>
> Dell dual CPU
> 4GB ram.
>
>
> Postgres version: 8.2.3
>
> live config lines:
>
> max_connections = 100                   # (change requires restart)
> shared_buffers = 24MB                   # min 128kB or max_connections*16kB
> max_fsm_pages = 153600          # min max_fsm_relations*16, 6 bytes each
> redirect_stderr = on                    # Enable capturing of stderr into log
> log_directory = 'pg_log'                # Directory where log files are writtenlog_truncate_on_rotation = on
# If on, any existing log file of the same 
> log_rotation_age = 1d                   # Automatic rotation of logfiles will
> log_rotation_size = 0                   # Automatic rotation of logfiles will
> datestyle = 'iso, mdy'
> lc_messages = 'en_US.UTF-8'                     # locale for system error message
> lc_monetary = 'en_US.UTF-8'                     # locale for monetary formatting
> lc_numeric = 'en_US.UTF-8'                      # locale for number formatting
> lc_time = 'en_US.UTF-8'                         # locale for time formatting
> --- --- --- ---
> I explain the characterization of fast and slow like this:  Slow is taking about ten times longer than fast to
executethe same query. 
>
> If there's any gotcha here that we're not seeing, please point it out.  I'm flummoxed.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
>                http://archives.postgresql.org/


--
Bill Moran
http://www.potentialtech.com