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

Re: ayuda-configuracion-mem-postgresql

From: tgutierrez(at)unipamplona(dot)edu(dot)co
To: "Alvaro Herrera" <alvherre(at)dcc(dot)uchile(dot)cl>
Cc: tgutierrez(at)unipamplona(dot)edu(dot)co,"AyudaPostgres" <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: ayuda-configuracion-mem-postgresql
Date: 2004-09-01 00:52:09
Message-ID: 46954.64.76.58.174.1093999929.squirrel@correo.unipamplona.edu.co (view raw or flat)
Thread:
Lists: pgsql-es-ayuda
Gracias
GRAAAAAACIAS Alvaro
Muchisimas gracias.
Att,
Tania Gutierrez

> On Tue, Aug 31, 2004 at 04:21:25PM -0500, tgutierrez(at)unipamplona(dot)edu(dot)co
> wrote:
>
>> hola Amigos de postgreSQL.
>>
>> Tengo para asignar de memoria cache 700 MB
>> y configure las variables de esta forma:
>> echo 268435456 > /proc/sys/kernel/shmall
>> echo 268435456 > /proc/sys/kernel/shmmax
>>  y el en archivo  vi /etc/sysctl.conf
>> agregue:
>>
>> kernel.shmall=268435456
>> kernel.shmmax=268435456
>
> Perfecto.
>
>> quiero asignarle:
>>
>> 1. numero de conexiones: -N 200
>
> Olvidate de usar switches en la invocacion de postmaster.  Mejor pon la
> configuracion en el archivo de configuracion postgresql.conf.  En este
> caso,
>
> max_backends = 200
>
>> 2. Memoria Compartida Usada como cache de consultas: -B 700 MB ?
>> ¿Cuanto le asignaria en megas de memoria compartida: 572MB? tengo
>> disponible en memoria total de ram y cache: 700 MB.
>
> Pesima idea.  Deja unos 80 megas para shared_buffers como maximo, y que
> el resto sea usado por el sistema operativo para cache.  O sea,
>
> shared_buffers = 10000
>
> Si te pasas de eso el rendimiento empieza a empeorar.  Si hubieras hecho
> mediciones como te dije hace harto tiempo te habrias dado cuenta de
> esto.
>
>
>> 3. Aumentar la memoria del procesamiento de queries, para que quepa
>> todos
>> los datos que se estan procesando en esa memosria y los queries sean
>> procesados mas ràpidos.
>
> Estas confundiendo las cosas.  Puedes aumentar sort_mem y ganar bastante
> en las clausulas que usen ordenamiento, pero algunas consultas pueden
> usar mas de un paso de ordenamiento, y tendras estas areas de
> ordenamiento por cada consulta que se este ejecutando concurrentemente.
>
> Ej. si tienes una consulta SELECT * FROM ... ORDER BY ... donde no hay
> un indice, hay que hacer un paso de ordenamiento.  Si le pones 50 megas
> a sort_mem, vas a usar 50 megas en esta consulta.  Si lanzas dos de
> estas consultas simultaneamente, ocuparas 100 mb.
>
> Asi, pon un numero donde ojala quepa la consulta completa, pero no
> demasiado grande.  Si te pasas del total de memoria, se ira a swap y eso
> es muchisimo peor.
>
> sort_mem = 1000      # valor en kilobytes.  Quizas 1 MB sea poco, pero
>                      # __mide__ antes de hacer cambios.
>
> Luego de todo esto, lanzas postmaster sin parametros.
>
> Para effective_cache_size, pon un valor cualquiera.  Luego lanza el
> servidor y ten corriendo tu aplicacion por un par de horas.  Luego,
> ejecuta el comando free.  La primera linea dice
>
> $ free
>              total       used       free     shared    buffers cached
> Mem:        451260     447848       3412          0      10828 224596
>
> Mi "effective cache size" aqui es de 224596.  En Postgres se mide en
> numero de bloques, que es 8 kb, o sea yo pondria
>
> effective_cache_size = 28074
>
> (Mi maquina tiene 440 MB). Ojo, esto no es memoria ocupada, sino
> lo siguiente:
>
> "Sets  the  planner's  assumption  about the effective size of the disk
> cache (that is, the portion of the kernel's disk cache that will be used
> for PostgreSQL data files). This is measured in disk pages, which are
> normally 8192 bytes each.  The default is 1000."
>
> --
> Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
> "Los dioses no protegen a los insensatos.  Éstos reciben protección de
> otros insensatos mejor dotados" (Luis Wu, Mundo Anillo)
>


In response to

pgsql-es-ayuda by date

Next:From: Fernando RomoDate: 2004-09-01 02:55:58
Subject: Re: Query Lento
Previous:From: Alvaro HerreraDate: 2004-09-01 00:09:10
Subject: Re: Query Lento

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group