Re: [pgsql-es-ayuda] Valor del parametro max_locks_per_transaction

[Emanuel Calvo]

El 2 de agosto de 2016, 18:26, Alvaro Herrera
 escribió:
>
> Alvaro Herrera escribió:
>
> > Se aumenta más o menos en 302 bytes por cada unidad que aumentas en
> > max_locks_per_transaction (ver LockShmemSize).  O sea en vez de usar
> > ~19kB vas a usar ~240kB.  No creo que te afecte en nada.
>
> En realidad este cálculo está mal, porque falta multiplicar por
> NLOCKENTS que es MaxBackends+max_prepared_xacts.  Si alguien sabe usar
> una calculadora, ¡help! ;-)  Pero sigue siendo un número relativamente
> pequeño.
>

Iba a preguntar si los custom workers contaban en los backends, pero
luego encontré
el InitializeMaxBackends en postinit:

MaxBackends = MaxConnections + autovacuum_max_workers + _the extra
unit accounts for the autovacuum launcher_ + max_worker_processes;

_the extra unit accounts for the autovacuum launcher_ = 1


Suponiendo los valores por defecto, serían 112 backends, 0 prep xacts.
~240kb * 112 ~= ~26MB.

Gracias por esa info!

-- 
--
Emanuel Calvo
 3manuek.com

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: [pgsql-es-ayuda] Valor del parametro max_locks_per_transaction

[Sergio Sinuco]

Muchas gracias por la ayuda.

Aumentare el parametro y cambiare los update. Les cuento como me va.

El 2 de agosto de 2016, 16:26, Alvaro Herrera 
escribió:

> Alvaro Herrera escribió:
>
> > Se aumenta más o menos en 302 bytes por cada unidad que aumentas en
> > max_locks_per_transaction (ver LockShmemSize).  O sea en vez de usar
> > ~19kB vas a usar ~240kB.  No creo que te afecte en nada.
>
> En realidad este cálculo está mal, porque falta multiplicar por
> NLOCKENTS que es MaxBackends+max_prepared_xacts.  Si alguien sabe usar
> una calculadora, ¡help! ;-)  Pero sigue siendo un número relativamente
> pequeño.
>
> --
> Álvaro Herrerahttp://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>



-- 
Sergio E. Sinuco Leon
Arquitecto de desarrollo
Datatraffic S.A.S.
Móvil: (57) 310 884 26 50
Fijo (+571) 7426160 Ext 115
Carrera 47 A No 91 - 91
Bogotá, Colombia.
www.datatraffic.com.co

Re: [pgsql-es-ayuda] Valor del parametro max_locks_per_transaction

[Alvaro Herrera]

Alvaro Herrera escribió:

> Se aumenta más o menos en 302 bytes por cada unidad que aumentas en
> max_locks_per_transaction (ver LockShmemSize).  O sea en vez de usar
> ~19kB vas a usar ~240kB.  No creo que te afecte en nada.

En realidad este cálculo está mal, porque falta multiplicar por
NLOCKENTS que es MaxBackends+max_prepared_xacts.  Si alguien sabe usar
una calculadora, ¡help! ;-)  Pero sigue siendo un número relativamente
pequeño.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: [pgsql-es-ayuda] Valor del parametro max_locks_per_transaction

[Jaime Casanova]

2016-08-02 15:46 GMT-05:00 Sergio Sinuco :
> Jaime solo hay un trigger en esta tabla, CREATE TRIGGER es el siguiente:
>
> CREATE TRIGGER ins_trama
>   BEFORE INSERT
>   ON parseo.trama_1
>   FOR EACH ROW
>   EXECUTE PROCEDURE parseo.ins_trama();
>
> El 2 de agosto de 2016, 15:44, Jaime Casanova
>  escribió:
>>
>> 2016-08-02 14:22 GMT-05:00 Sergio Sinuco
>> :
>> >
>> > Lo que si estoy viendo es que despues de insertar el registro se hace
>> > actualiza en la tabla padre usando la llave primaria.
>> >
>> > UPDATE parseo.trama_1 SET ejecutada=true WHERE id=idtramain;
>> >
>>

Si el trigger es BEFORE INSERT y termina con RETURN NULL, el registro
nunca toca la tabla padre sino solo la tabla hija.
por lo que ese UPDATE busca en las 200 hijas el registro que debe
actualizar (solo eliminaría particiones si el constraint check
incluyera el campo id pero ese usa el campo fecha) por lo que ahi
tienes 201 tablas.

Deja de ejecutar ese UPDATE que no te sirve y si ese id es el mismo
que acabas de insertar solo modifica el registro antes de insertarlo
(NEW.ejecutada = true) en el trigger.

Y lo que Álvaro dice...

-- 
Jaime Casanova  www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: [pgsql-es-ayuda] Valor del parametro max_locks_per_transaction

[Alvaro Herrera]

Sergio Sinuco escribió:
> Hola.
> 
> Este es el valor actual de los parametros que me mencionaron. Basicamente
> estan los valores por defecto.
> 
> constraint_exclusion = partition
> max_locks_per_transaction =  64
> max_connections = 100
> max_prepared_transactions = 0
> 
> Tenemos 4 tablas padre. Cada una de ellas con mas o menos 200 hijas. Creo
> que podríamos reducir las hijas a 50.

Yo creo que lo más sencillo sería simplemente incrementar el
max_locks_per_transaction a unos 800 o 1000 sólo para estar seguro.
Esto implica que el servidor va a usar una cantidad menor de memoria
compartida extra, pero para alguien que tiene una tabla con 200
particiones no debería significar ningún inconveniente.

Se aumenta más o menos en 302 bytes por cada unidad que aumentas en
max_locks_per_transaction (ver LockShmemSize).  O sea en vez de usar
~19kB vas a usar ~240kB.  No creo que te afecte en nada.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: [pgsql-es-ayuda] Valor del parametro max_locks_per_transaction

[Sergio Sinuco]

Jaime solo hay un trigger en esta tabla, CREATE TRIGGER es el siguiente:

CREATE TRIGGER ins_trama
  BEFORE INSERT
  ON parseo.trama_1
  FOR EACH ROW
  EXECUTE PROCEDURE parseo.ins_trama();

El 2 de agosto de 2016, 15:44, Jaime Casanova <
jaime.casan...@2ndquadrant.com> escribió:

> 2016-08-02 14:22 GMT-05:00 Sergio Sinuco  >:
> >
> > Lo que si estoy viendo es que despues de insertar el registro se hace
> > actualiza en la tabla padre usando la llave primaria.
> >
> > UPDATE parseo.trama_1 SET ejecutada=true WHERE id=idtramain;
> >
>
> y el CREATE TRIGGER? hay más de un trigger o sólo uno?
>
> --
> Jaime Casanova  www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>



-- 
Sergio E. Sinuco Leon
Arquitecto de desarrollo
Datatraffic S.A.S.
Móvil: (57) 310 884 26 50
Fijo (+571) 7426160 Ext 115
Carrera 47 A No 91 - 91
Bogotá, Colombia.
www.datatraffic.com.co

Re: [pgsql-es-ayuda] Valor del parametro max_locks_per_transaction

[Jaime Casanova]

2016-08-02 14:22 GMT-05:00 Sergio Sinuco :
>
> Lo que si estoy viendo es que despues de insertar el registro se hace
> actualiza en la tabla padre usando la llave primaria.
>
> UPDATE parseo.trama_1 SET ejecutada=true WHERE id=idtramain;
>

y el CREATE TRIGGER? hay más de un trigger o sólo uno?

-- 
Jaime Casanova  www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: [pgsql-es-ayuda] Valor del parametro max_locks_per_transaction

[Sergio Sinuco]

Hola.

Este es el valor actual de los parametros que me mencionaron. Basicamente
estan los valores por defecto.

constraint_exclusion = partition
max_locks_per_transaction =  64
max_connections = 100
max_prepared_transactions = 0

Tenemos 4 tablas padre. Cada una de ellas con mas o menos 200 hijas. Creo
que podríamos reducir las hijas a 50.

La definicion de una tabla padre es:

CREATE TABLE parseo.trama_1

(

  id bigint NOT NULL DEFAULT nextval('parseo.trama_id_seq'::regclass),

  texto character varying,

  fecha timestamp without time zone NOT NULL DEFAULT now(),
  ejecutada boolean DEFAULT true,

  CONSTRAINT trama_1_pkey3 PRIMARY KEY (id)

)

WITH (

  OIDS=FALSE

);


Hacemos una particion por numero de la semana:

CREATE TABLE parseo.trama_10_2012

(

-- Inherited from table parseo.trama_1:  id bigint NOT NULL DEFAULT
nextval('parseo.trama_id_seq'::regclass),

-- Inherited from table parseo.trama_1:  texto character varying,

-- Inherited from table parseo.trama_1:  fecha timestamp without time zone
NOT NULL DEFAULT now(),
-- Inherited from table parseo.trama_1:  ejecutada boolean DEFAULT true,

  CONSTRAINT pk_trama_10_2012 PRIMARY KEY (id),

  CONSTRAINT trama_10_2012_fecha_check CHECK (fecha >= '2012-03-04
00:00:00'::timestamp without time zone AND fecha < '2012-03-11
00:00:00'::timestamp without time zone)

)

INHERITS (parseo.trama_1)

WITH (

  OIDS=FALSE

);


El trigger que tenemos calcula el numero de la semana del año del registro
y lo inserta en la tabla correspondiente

CREATE OR REPLACE FUNCTION parseo.ins_trama()

  RETURNS trigger AS

$BODY$

DECLARE

i integer;

anovar integer;

BEGIN

anovar = EXTRACT(YEAR FROM NEW.fecha);

i = ceil(extract(doy from NEW.fecha)/7);


--Insertar el registro en la tabla correspondiente

PERFORM 1 FROM pg_tables WHERE tablename = 'trama_'||i||'_'||anovar;

IF(FOUND) THEN

EXECUTE 'INSERT INTO '||'parseo.trama_'||i||'_'||anovar

|| ' SELECT ($1).*'

USING NEW;

ELSE

RAISE EXCEPTION 'No existe la tabla para esta semana y anio trama_%_% en
fecha %',i,anovar,NEW.fecha;

END IF;


RETURN NULL;

END;

$BODY$

  LANGUAGE plpgsql VOLATILE

  COST 100;


Lo que si estoy viendo es que despues de insertar el registro se hace
actualiza en la tabla padre usando la llave primaria.

UPDATE parseo.trama_1 SET ejecutada=true WHERE id=idtramain;


Supongo que esta actualizacion es la que hace que se haga lock en todas las
llaves primarias de las hijas. Alguien me podria aclarar como funciona esta
actualizacion? Intentaria actualizar el registro en todas las hijas?


El 2 de agosto de 2016, 12:59, Jaime Casanova <
jaime.casan...@2ndquadrant.com> escribió:

> 2016-08-02 10:22 GMT-05:00 Sergio Sinuco  >:
> > Hola a todos.
> >
> > En la base de datos que tenemos en produccion tenemos el siguiente error
> en
> > el log
> >
> > 2016-08-01 14:26:34 COT 30621 ERROR:  out of shared memory
> > 2016-08-01 14:26:34 COT 30621 HINT:  You might need to increase
> > max_locks_per_transaction.
> >
>
> Que valores tienes definidos en:
>
> max_locks_per_transaction
> max_connections
> max_prepared_transactions
>
> Cuantas hijas tiene la tabla particionada?
> Puedes mostrar la definición de alguna de las hijas?
>
> y si, si subes max_locks_per_transaction a 600 puedes bloquear hasta
> 600 objetos distintos por transacción (considera las tablas hijas,
> indices, tablas toast, indices de las tablas toast, secuencias?,
> catalogos y sus repectivos objetos dependientes y asi)
>
> --
> Jaime Casanova  www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>



-- 
Sergio E. Sinuco Leon
Arquitecto de desarrollo
Datatraffic S.A.S.
Móvil: (57) 310 884 26 50
Fijo (+571) 7426160 Ext 115
Carrera 47 A No 91 - 91
Bogotá, Colombia.
www.datatraffic.com.co

Re: [pgsql-es-ayuda] Valor del parametro max_locks_per_transaction

[Jaime Casanova]

2016-08-02 10:22 GMT-05:00 Sergio Sinuco :
> Hola a todos.
>
> En la base de datos que tenemos en produccion tenemos el siguiente error en
> el log
>
> 2016-08-01 14:26:34 COT 30621 ERROR:  out of shared memory
> 2016-08-01 14:26:34 COT 30621 HINT:  You might need to increase
> max_locks_per_transaction.
>

Que valores tienes definidos en:

max_locks_per_transaction
max_connections
max_prepared_transactions

Cuantas hijas tiene la tabla particionada?
Puedes mostrar la definición de alguna de las hijas?

y si, si subes max_locks_per_transaction a 600 puedes bloquear hasta
600 objetos distintos por transacción (considera las tablas hijas,
indices, tablas toast, indices de las tablas toast, secuencias?,
catalogos y sus repectivos objetos dependientes y asi)

-- 
Jaime Casanova  www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: [pgsql-es-ayuda] Valor del parametro max_locks_per_transaction

[Emanuel Calvo]

El 2 de agosto de 2016, 12:22, Sergio Sinuco <
sergiosin...@datatraffic.com.co> escribió:

Hola a todos.
>
> En la base de datos que tenemos en produccion tenemos el siguiente error
> en el log
>
> 2016-08-01 14:26:34 COT 30621 ERROR:  out of shared memory
> 2016-08-01 14:26:34 COT 30621 HINT:  You might need to increase
> max_locks_per_transaction.
>
> Una transaccion tipica del sistema ejecuta la funcion *procesamiento*().
> Para verificar el numero de locks que realiza esta transaccion hice lo
> siguiente en una consola de psql
>
> BEGIN;
> SELECT procesamiento();
>
> Verificando entonces en pg_locks y pg_stat_activity encontre que esta
> transaccion realiza 1921 locks de 3 tipos RowExclusiveLock, AccessShareLock
> y RowShareLock.
>
> Tengo varias dudas y agradeceria el consejo que me puedan dar:
>
>- Ahora estamos usando el particionamiento de tablas para dividir
>informacion. Hay una tabla padre y varias tablas hijas. Las tablas hijas
>heredan de la tabla padre y en la tabla padre hay un trigger que decide a
>que hija insertar. Cada tabla hija tiene una llave primaria definida y
>varios indices. Veo que a que pesar de que en teoria solo se inserta en un
>tabla, se hace un lock de tipo RowExclusiveLock en todas las llaves
>primarias de las tablas hijas. Esto deberia ser asi?
>
> Cual es el valor del *constraint_exclusion* ? Puedes compartir el código
del trigger?
Como verificas en que tabla está el dato?


>-
>- Vamos a reducir el numero de tablas hijas. Creo que podriamos
>reducir el numero de locks a aproximadamente 600. Esto quiere decir que el
>parametro max_locks_per_transaction se debe configurar a 600?
>
> No creo que ese sea el problema, claramente el procesamiento está haciendo
más locks de los que debería.
Aumentar en este caso el *max_locks_per_transaction*, solo solucionaría uno
de tus posibles problemas.

Muchas gracias.
>
> --
> Sergio E. Sinuco Leon
> Arquitecto de desarrollo
> Datatraffic S.A.S.
> Móvil: (57) 310 884 26 50
> Fijo (+571) 7426160 Ext 115
> Carrera 47 A No 91 - 91
> Bogotá, Colombia.
> www.datatraffic.com.co
>
> ​
-- 
--
Emanuel Calvo
 3manuek.com

[pgsql-es-ayuda] Valor del parametro max_locks_per_transaction

[Sergio Sinuco]

Hola a todos.

En la base de datos que tenemos en produccion tenemos el siguiente error en
el log

2016-08-01 14:26:34 COT 30621 ERROR:  out of shared memory
2016-08-01 14:26:34 COT 30621 HINT:  You might need to increase
max_locks_per_transaction.

Una transaccion tipica del sistema ejecuta la funcion *procesamiento*().
Para verificar el numero de locks que realiza esta transaccion hice lo
siguiente en una consola de psql

BEGIN;
SELECT procesamiento();

Verificando entonces en pg_locks y pg_stat_activity encontre que esta
transaccion realiza 1921 locks de 3 tipos RowExclusiveLock, AccessShareLock
y RowShareLock.

Tengo varias dudas y agradeceria el consejo que me puedan dar:

   - Ahora estamos usando el particionamiento de tablas para dividir
   informacion. Hay una tabla padre y varias tablas hijas. Las tablas hijas
   heredan de la tabla padre y en la tabla padre hay un trigger que decide a
   que hija insertar. Cada tabla hija tiene una llave primaria definida y
   varios indices. Veo que a que pesar de que en teoria solo se inserta en un
   tabla, se hace un lock de tipo RowExclusiveLock en todas las llaves
   primarias de las tablas hijas. Esto deberia ser asi?
   - Vamos a reducir el numero de tablas hijas. Creo que podriamos reducir
   el numero de locks a aproximadamente 600. Esto quiere decir que el
   parametro max_locks_per_transaction se debe configurar a 600?

Muchas gracias.

-- 
Sergio E. Sinuco Leon
Arquitecto de desarrollo
Datatraffic S.A.S.
Móvil: (57) 310 884 26 50
Fijo (+571) 7426160 Ext 115
Carrera 47 A No 91 - 91
Bogotá, Colombia.
www.datatraffic.com.co