Re: [pgsql-es-ayuda] Aumentar el desempeño del servidor

Martin,

Aqui está el resultado del Explain Analyse de la query:

"Subquery Scan vtempomaquinas (cost=100007145.19..100007420.69 rows=23
width=231)"
" -> Unique (cost=100007145.19..100007409.19 rows=23 width=159)"
" -> Sort (cost=100007145.19..100007167.19 rows=220 width=159)"
" Sort Key: rpc1."CDEMP_CDMAQ", rpc1."CDEMP", rpc1."CDMAQ",
(rpc1."DESCR_CDMAQ")::character varying, rpc1."DTLAV", rpc1."HRINI",
rpc1."HRFIN", round((((((substr((rpc1."HRFIN")::text, 1,
2))::integer)::double precision + ((substr((rpc1."HRFIN")::text, 4,
2))::real / 60::double precision)) - (((substr((rpc1."HRINI")::text, 1,
2))::integer)::double precision + ((substr((rpc1."HRINI")::text, 4,
2))::real / 60::double precision))))::numeric, 2), rpc1."PROGR", (subplan),
"fOSsEmDtLav"(rpc1."CDEMP_CDMAQ", rpc1."CDEMP", rpc1."CDMAQ", rpc1."DTLAV",
rpc1."HRINI", rpc1."HRFIN")"
" -> Index Scan using rpcproc3002 on "RPCPROC3" rpc1
(cost=0.00..6802.81 rows=220 width=159)"
" Index Cond: (("DTLAV" >= '2008-04-01'::date) AND
("DTLAV" <= '2008-04-02'::date))"
" Filter: (("HRINI" <> ''::bpchar) AND ("HRFIN" <>
''::bpchar))"
" SubPlan"
" -> Aggregate (cost=19.49..19.99 rows=1 width=9)"
" -> Index Scan using rpcproc3004 on "RPCPROC3"
rpc2 (cost=0.00..19.29 rows=1 width=9)"
" Index Cond: (($0 = "CDEMP_CDMAQ") AND ($1
= "CDEMP") AND ($2 = "CDMAQ") AND ($3 = "DTLAV") AND ($4 = "HRINI") AND ($5
= "HRFIN"))"

Cuando hice el test de la query en el servidor de la empresa, lo hice el
domingo, cuando no había nadie trabajando.

Atentamente,

Antonio Salas Mena

--------------------------------------------------
From: "Martin Marques" <martin(at)marquesminen(dot)com(dot)ar>
Sent: Monday, May 05, 2008 12:54 PM
To: "Antonio Salas Mena" <antoniosm1966(at)hotmail(dot)com>
Cc: <pgsql-es-ayuda(at)postgresql(dot)org>; <jonatha(at)bardusch(dot)com(dot)br>
Subject: Re: [pgsql-es-ayuda] Aumentar el desempeño del servidor

> Antonio Salas Mena escribió:
>> Martin,
>>
>> En general está lento, pero específicamente una consulta está me dando
>> una respuesta muy lenta. Esta consulta usa una función. Copié los datos
>> en mi portátil, donde tengo instalado el PostgreSql 8.2 con WinXp y la
>
> Pero no con 20 consultas concurrentes.
>
>> respuesta es super rápida y tambien está usando la misma función,
>> exactamente igual. Por eso creo que el problema sea algo en el
>> Postgres.conf.
>
> Podemos ver la salida de EXPLAIN ANALYZE tu_query?
>
>> Este servidor es usado como servidor de banco de datos Postgresql y
>> también como servidor de arquivos via Samba.
>
> Samba no es problemas. Preguntaba por si había alguna aplicación corriendo
> que demande mucha memoria.
>
>> La memória total del servidor es 5Gb. ¿Cuanto crees que deberia de ser la
>> memória compartida al motor?
>
> Yo para empezar lo subiría a 1Gb. Fijate como estas de memoria libre, y
> cuanto hay en cache. Igualmente esto esta muy atado a la cantidad de
> memoria en work_mem y como están trabajando las consultas.
>
> La idea es no tener que usar intercambio de memoria.
>
>> Pregunta: ¿el ProstgreSql usa los dos procesadores?
>
> No. Pero si tenes 20 consultas concurrentes, postgres levantará 20
> procesos (uno por cada sesión abierta) y el SO se encargará de balancear
> la carga entre los dos procesadores.
>
> O sea, en corto, PostgreSQL no hace threading, pero como siempre hay
> varios procesos, algunos estarán corriendo en un CPU y otros en el otro.
>
>> Son 140 usuaruios no concurrentes: creo que debe de llegar a unos 20
>> concurrentes.
>
> Esto no es mucho para esa maquina si las consultas están bien diseñadas. O
> sea, depende mucho de la aplicación.
>
>> Vacuum: todo domingo con option -f (full) . Ejemplo: vacuumdb -d SBU -f
>
> OK. Igualmente, si fuese un problema de vacuum mas a menudo, volaría el
> servidor los lunes, transformandose de a poco en una carreta con en correr
> de los días de la semana.
>