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

Re: tuning

From: "Mario Soto" <mario_soto(at)venezolanadeavaluos(dot)com>
To: <marcelo(at)ubiobio(dot)cl>
Cc: <mario_soto(at)venezolanadeavaluos(dot)com>,<alejandro(dot)casanova(at)telintel(dot)net>, <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: tuning
Date: 2004-06-10 18:17:06
Message-ID: 51421.200.35.66.77.1086891426.squirrel@mail.venezolanadeavaluos.com (view raw or flat)
Thread:
Lists: pgsql-es-ayuda
Lo que dices es correcto, pero si necesitas referencia de integridad en
los datos, no puedes eliminar los indices que apuntan a las FK.
ya que podrías ingresar datos inconsistentes.

Saludos


> Ojo... al hacer inserciones masivas de cientos de registros es
> recomendable eliminar los índices y después volver a recrearlos, por que
> de lo contrario el proceso de inserción va a ser muy lento dado que el
> motor se tiene que preocupar de actualizar los índices, inserciones,
> balanceos,etc...
>
> esto ocurre en cualquier motor.
>
>
> On Thu, 2004-06-10 at 13:52, Mario Soto wrote:
>> Los inserts dependiando de la cantidad o si es masivo o no ocupan
>> disco. Y esto hace que la maquina se ponga lenta sobre todo en
>> ingresos masivos , pero en terminos generales eso es normal, sobre
>> todo cuando realizas una carga masiva de datos.
>>
>> Al hacer esa carga de datos, lo hiciste en forma transsaccional????
>> como tienes configurado en el postgresql.con lo relacionado con commit
>> y checkpoints
>>
>> checkpoint_segments = 3         # in logfile segments, min 1, 16MB
>> each checkpoint_timeout = 300        # range 30-3600, in seconds
>> checkpoint_warning = 30         # 0 is off, in seconds
>> commit_delay = 0                # range 0-100000, in microseconds
>> commit_siblings = 5             # range 1-1000
>>
>> Tus discos son SCSI
>>
>> después de ese hecho hicistes un
>> vacuumdb -z -a ???
>>
>> Saludos
>>
>>
>>
>> > ok si, esta bien... pero me preocupa una cosa... hay ocaciones en el
>> que el rendimiento de la maquina se me va abajo y no se porque
>> razon. Hace poco tuve que montar una archivo de cerca de 750Mb que
>> contiene lienas de instrucciones INSERT, al hacerlo el rendimiento
>> de la maquina se fue abajo despues de algun tiempo, aunque cancele
>> el proceso y me asegure de que no estaba corriendo ni zombie el
>> rendimiento de la maquina continuó abajo, fue necesario reiniciar
>> postgres y otros servicios para que recuperara el funcionamiento.
>> Acerca de esto que me puedes recomendar? que otra cosa debo
>> revisar?.
>> >
>> > En realidad agradezco mucho la ayuda que me estas dando.
>> >
>> > On Thu, 2004-06-10 at 12:17, Alvaro Herrera wrote:
>> >> On Thu, Jun 10, 2004 at 11:32:57AM -0500, Alejandro Casanova wrote:
>> >>
>> >> > el server tine 4 gigas de ram , y solamente tiene 19megas de
>> memoria
>> >> libre  bajo postgresql y la memoria solo sube unpoco , reviso los
>> procesos corriendo y no hay ninguno que tome tanta memoria memoria
>> ,
>> >>
>> >> >
>> >> > pregunta como minitoreo eso ? , lo monitoreo con top y ps pero no
>> me
>> >> muestra quien tiene esa memoria.
>> >>
>> >> Supongo que estas consciente de que en (casi?) cualquier Unix, el
>> kernel no libera la memoria de inmediato sino que queda en forma de
>> "cache" o "buffers".  Ejecuta free (en un shell).  Aca dice:
>> >>
>> >> $ free
>> >>              total       used       free     shared    buffers
>> cached
>> >> Mem:        450792     194240     256552          0      62008
>> 74076 -/+ buffers/cache:      58156     392636
>> >> Swap:            0          0
>> >>
>> >>
>> >> observa que la cantidad de memoria libre en la practica es de
>> 256MB, _mas_ los 62 MB en buffers y los 74 MB en cache (Esos son
>> los 392 MB que salen en la fila de abajo).
>> >>
>> >> (Acabo de encender el computador, por eso sale tanta memoria libre
>> -- en un par de horas mas seguramente free dira unos 4 o 10 MB ...
>> pero en buffers y cache va a haber mucha memoria)
>> >>
>> >> En resumen, no te preocupes.
>> >
>> >
>> > ---------------------------(end of
>> broadcast)--------------------------- TIP 5: ¿Has leído nuestro
>> extenso FAQ?
>> >
>> >                http://www.postgresql.org/docs/faqs/FAQ.html
>>
>>
>>
>>
>> ---------------------------(end of
>> broadcast)--------------------------- TIP 2: puedes desuscribirte de
>> todas las listas simultáneamente
>>     (envíe "unregister SuDirecciónDeCorreo" a
>> majordomo(at)postgresql(dot)org)
> --
> Marcelo Espinosa Alliende,  mailto:marcelo(at)ubiobio(dot)cl
> Depto de Servicios Computacionales
> Dirección de Informática
> fono: +56 41 73154,  http://www.ubiobio.cl/marcelo
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: No hagas 'kill -9' a postmaster




In response to

  • Re: tuning at 2004-06-10 18:09:08 from Marcelo Espinosa Alliende

Responses

  • Re: tuning at 2004-06-22 12:30:16 from Alejandro Casanova

pgsql-es-ayuda by date

Next:From: Alvaro HerreraDate: 2004-06-10 18:18:15
Subject: Re: PostgreSQL 7.4.2
Previous:From: Marcelo Espinosa AlliendeDate: 2004-06-10 18:09:08
Subject: Re: tuning

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