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

Re: fatal out of shared memory postgres

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Rensi Arteaga Copari <rarteaga(at)ende(dot)bo>
Cc: Ayuda <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: fatal out of shared memory postgres
Date: 2010-09-27 17:38:37
Message-ID: 1285608949-sup-4542@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-es-ayuda
Excerpts from Rensi Arteaga Copari's message of lun sep 27 11:43:34 -0400 2010:
>   El 27/09/2010 11:19, Alvaro Herrera escribió:
> > Excerpts from Rensi Arteaga Copari's message of lun sep 27 10:35:22 -0400 2010:

> >> #deadlock_timeout = 1000                # in milliseconds
> >> *#max_locks_per_transaction = 64         # min 10*
> > Ok ... quizás podrías intentar aumentar ese valor un poco.
> 
> Cual es el valor que tiene
> 
> max_locks_per_transaction
> 
> por defecto ?  vien con el  mínimo 10 ??

64

> >>> ¿Por qué subiste tanto temp_buffers y work_mem?
> >> Como el servidor es grande y exclusivo para postgres buscamos aprovechar
> >> el hardware,
> >> en algún manual de tunning de postgres  leímos que podíamos ir subiendo
> >> estos valores
> > Dudo mucho que temp_buffers te esté ayudando mucho.  Te recomendaría
> > bajarlo al valor por omisión, si bien no tiene relación directa con tu
> > problema; pero ¿sabes lo que hace?  ¿Qué mediciones hiciste para
> > determinar que subirlo servía de algo?
> tengo entendido que es el máximo número de buffers temporales que
> una sesión puede usar, se usan para acceder a las tablas temporales  y
> para optimizar consultas que eran lentas en varios lugares usamos tablas 
> temporales

Ya, pero esa memoria podría usarse mejor por parte del sistema
operativo.

> Tengo una tabla particionada  físicamente con herencia
> t_registro_evento   es el padre
> y cada mes se crea una tabla con sufijo del mes
> 
> asi:   t_registro_evento_9_2010
>          t_Registro_evencto_8_2010
> 
> 
> tengo a la fecha 5 tablas con un total de 785204  registros

¿Es la única tabla particionada?  Es difícil ver por qué podría causarse
este problema con tan pocas particiones.  ¿Puedes aislar qué consulta es
la que causa el problema?

Para 785000 registros, no parece valer la pena el particionamiento.  Y
ciertamente no con una partición por mes.  Seguramente habría sido mejor
idea hacer particionamiento por año solamente.

-- 
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

pgsql-es-ayuda by date

Next:From: Guillermo VillanuevaDate: 2010-09-27 18:01:24
Subject: Re: COPY FROM
Previous:From: Mariano ReingartDate: 2010-09-27 17:24:36
Subject: Re: COPY FROM

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