Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

Re: Performance y tunning postgres


  • From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
  • To: Patricio Cifuentes Ithal <pcifuentes(at)siigsa(dot)cl>
  • Cc: pgsql-es-ayuda(at)postgresql(dot)org
  • Subject: Re: Performance y tunning postgres
  • Date: Fri, 29 Jun 2007 16:07:26 -0400
  • Message-id: <20070629200726(dot)GK10563(at)alvh(dot)no-ip(dot)org>

Patricio Cifuentes Ithal escribió:
> Max_connection				| 300
> > share_buffer				| 262164
> > > checkpoint_segments            | 16
> > > effective_cache_size           | 692674
> > >  enable_seqscan                 | true
> > >  max_fsm_pages                  | 1048576
> > >  max_fsm_relations              | 32768
> > >  sort_mem                       | 32384
> > > vacuum_mem                     | 16384
> > > cpu_tuple_cost			| 0.5
> > > cpu_index_tuple_cost		| 0.1
> > > cpu_operator_cost			| 0.5
> 
> Ok asi la deje ahora, estará bien?, tomando en cuenta q es de dos
> procesadores de doble núcleo y 4 GB en RAM quiero dejarle el 40% de la RAM,
> indiferentemente la versión , es verdad q entre mas share_buffer se vuelve
> mas lento?

No es indiferente de la version; en 8.0 y anteriores si era cierto, en
las mas nuevas no es cierto.  Los algoritmos de shared_buffers son
muchisimo mejores desde 8.1.  En 7.4, no es buena idea subirlo mucho.
Quizas aqui lo dejaste demasiado alto.

sort_mem me sigue pareciendo muy alto, pero depende de que tanta
concurrencia tengas.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.



Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group