Re: regexp en pgsql

Hola Marco voy a revisar mis parámetros de acuerdo a los tuyos, de todas
maneras pego nuevamente la config de mi servidor con todos los archivos de
config.

Servidor dedicado únicamente como base de datos.

Server HP ML150 G6 (2 CPUS)
1.- XEON E5504 2.0GHz 4 cores
2.- XEON E5504 2.0GHz 4 cores
8GB de RAM KINGSTON 2GB KTH-PL313/2G Unbuffered Advanced ECC memory
Controlador STD HP Smart Array P410 controller w/ Zero Memory cache Raid
Controller (RAID 0,1, 0+1)
3 Discos HDD 146GB 15K SAS 3.5 DUAL PORT hot-swap - SAS - 15000 rpm
Tarjeta de memoria para la controladora - HP 256MBP-SERIESCACHEUPGRADE
Sistema operativo FreeBSD 8.2 64bits
PostgreSQL 9.0

Mi postgresql.conf

listen_addresses = '*'
port = 5432
max_connections = 100
temp_buffers = 8MB
cpu_tuple_cost = 0.0030
cpu_index_tuple_cost = 0.0010
cpu_operator_cost = 0.0005
fsync = off
checkpoint_timeout = 1h
maintenance_work_mem = 480MB
checkpoint_completion_target = 0.9
effective_cache_size = 5632MB
work_mem = 80MB
wal_buffers = 128
checkpoint_segments = 256
shared_buffers = 1920MB

/boot/loader.conf
vm.kmem_size_max="3096M"
vm.kmem_size="3096M"

kern.ipc.semmni=1024
kern.ipc.semmns=2048
kern.ipc.semmnu=1024

/etc/sysctl.conf
kern.ipc.shmall=654400
kern.ipc.shmmax=8228167680

net.inet.tcp.rfc1323=0
net.inet.tcp.sendbuf_auto=1
net.inet.tcp.sendbuf_inc=8192
net.inet.tcp.recvbuf_auto=1
net.inet.tcp.recvbuf_inc=16384
net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1
---

El 28 de junio de 2011 17:21, Marcos Ortiz <mlortiz(at)uci(dot)cu> escribió:

> **
>
>
> El 6/28/2011 4:41 PM, Gino Rojas Tillemann escribió:
>
> Mi hardware es el siguiente:
>
> Server HP ML150 G6 (2 CPUS)
> 1.- XEON E5504 2.0GHz 4 cores
> 2.- XEON E5504 2.0GHz 4 cores
> 8GB de RAM KINGSTON 2GB KTH-PL313/2G Unbuffered Advanced ECC memory
> Controlador STD HP Smart Array P410 controller w/ Zero Memory cache Raid
> Controller (RAID 0,1, 0+1)
> 3 Discos HDD 146GB 15K SAS 3.5 DUAL PORT hot-swap - SAS - 15000 rpm
> Tarjeta de memoria para la controladora - HP 256MBP-SERIESCACHEUPGRADE
> Sistema operativo FreeBSD 8.2
> PostgreSQL 9.0
>
> Mi postgresql.conf
>
> listen_addresses = '*'
> port = 5432
> max_connections = 100
> temp_buffers = 8MB
> cpu_tuple_cost = 0.0030
> cpu_index_tuple_cost = 0.0010
> cpu_operator_cost = 0.0005
> fsync = off
> checkpoint_timeout = 1h
> maintenance_work_mem = 480MB
> checkpoint_completion_target = 0.9
> effective_cache_size = 5632MB
> work_mem = 80MB
>
> A mi entender, lo veo muy alto
>
> wal_buffers = 128
> checkpoint_segments = 256
> shared_buffers = 1920MB
>
> Éste pudieras subir a 2048 Mb, en caso de que tu FreeBSD 8.2 sea de 64 bits
> (altamente recomendado)
> Recuerda también tunear el sistema operativo, si es un servidor dedicado a
> PostgreSQL.
> Algunas cosas de las que pudieras hacer (hazlas sólo si sabes lo que estás
> haciendo):
> en el /boot/loader.conf, necesitas incrementar el número de semáforos SysV
> IPC
> kern.ipc.semmni=512
> kern.ipc.semmns=1024
>
> Ahora, en el /etc/sysctl.conf, debes incrementar el valor de los tamaños de
> la memoria compartida:
> kern.ipc.shmmax=4089446400
> Éste es el máximo valor del tamaño de un segment de memoria compartida en
> bytes
>
> kern.pic.shmall=1050000
>
> Éste es el máximo valor de memoria permitido a ser usado como la memoria
> compartida de SysV, en páginas de 4 Kb
> En el caso de que la base de datos contenga muchos objetos (díganse tablas,
> índices, etc), debes incrementar el máximo
> número de archivos abiertos en memoria para la cache de la lista de
> directorios:
> kern.maxfiles=16384
> vfs.ufs.dirhash_maxmem=4194304 (en caso de que estés usando UFS como
> sistema de ficheros) Para bases de datos
> muchos recomiendan ZFS
> Puedes guiarte por la guia propuesta acá
> http://solarisinternals.com/ZFSforDatabases
>
>
>
> El 28 de junio de 2011 16:22, Juan <smalltalker(dot)marcelo(at)gmail(dot)com>escribió:
>
>> No sabria decirte.
>> proba copiar una cantidad menor de registros asi la variable cantidad de
>> registros desaparece.
>> Otra es como tenes configurado el postgres y en que fierro corre.
>> publica tu postgres.conf y la configuracion de hasrdware
>> Alvaro , y otros podran decirte q parametro de configuracion
>> no esta bueno
>> sal2
>>
>> mdc
>>
>> 2011/6/28 Gino Rojas Tillemann <gino(at)masnet(dot)cl>
>>
>>> lamentablemente la función hace lo que tiene que hacer y ya se ha
>>> optimizado bastante, aunque no sé si en regexp \d es mas rápido que [0-9],
>>> cosas como esas no las he probado.
>>>
>>> tal parece que no hay forma de optimizar eso desde el motor creo que
>>> tendré que asumir el tiempo de proceso de la función :(
>>>
>>> tendré el mismo problema si levanto una DB de pgsql en EC2 de amazon?
>>> mejorarán los procesos desde el cloud de amazon?
>>>
>>> gracias
>>>
>>> El 28 de junio de 2011 16:08, Juan <smalltalker(dot)marcelo(at)gmail(dot)com>escribió:
>>>
>>> Gino gente ,
>>>> Perdon se me escapo sin terminar el correo.
>>>> Fijate entonces como optimizar si es posible la expresion en si misma
>>>> sino podes crear expresiones q funcionen pero q sean lentas.
>>>> salu2
>>>> mdc
>>>>
>>>>
>>>> 2011/6/28 Juan <smalltalker(dot)marcelo(at)gmail(dot)com>
>>>>
>>>>> Gino
>>>>>
>>>>> Entonces y si las regexp estan compiladas en C no creo q haya manera de
>>>>>
>>>>> mejorar la velocidad.
>>>>> Las expresiones regulares la sintax es importante y existen muchas
>>>>> formas de
>>>>> mejorar la busqueda.
>>>>> Si no estas muy experto en ellas es posible construir expresiones
>>>>> regulares
>>>>> poco eficientes
>>>>>
>>>>>
>>>>> 2011/6/28 Gino Rojas Tillemann <gino(at)masnet(dot)cl>
>>>>>
>>>>>> el campo id ya esta indexado y no se trata de la cantidad de registros
>>>>>> que tenga la tabla, probé moviendo 10 mil registros a una tabla nueva y
>>>>>> demora lo mismo, solo cambia los tiempos de proceso cuando quito expresiones
>>>>>> regulares de la función, pero lamentablemente no puedo quitar esas regexp de
>>>>>> la fn, es por eso que busco que el proceso se haga mas rápido desde el
>>>>>> procesador, lamentablemente postgresql solo me entrega un core del CPU para
>>>>>> realizar este trabajo, si tan solo usara los 2 CPU y sus 8 nucleos sería
>>>>>> maravilloso :)
>>>>>>
>>>>>>
>>>>>>
>>>>>> El 28 de junio de 2011 15:56, Anthony <asotolongo(at)uci(dot)cu> escribió:
>>>>>>
>>>>>> On 28/06/11 15:48, Gino Rojas Tillemann wrote:
>>>>>>>
>>>>>>> Hola Juan, si hago eso tendría que crear 3.200 indices para esa
>>>>>>> tabla, ademas no necesariamente voy a actualizar el registros 1 al 10mil
>>>>>>> podría ser del 8mil al 15mil etc...
>>>>>>>
>>>>>>> ahora voy a crear la misma función en C para ver si así logro
>>>>>>> mejores resultados con el procesamiento del texto.
>>>>>>>
>>>>>>> alguna otra idea?
>>>>>>> sld2
>>>>>>>
>>>>>>> El 28 de junio de 2011 15:41, Juan <smalltalker(dot)marcelo(at)gmail(dot)com>escribió:
>>>>>>>
>>>>>>>> Hola gente
>>>>>>>> Gino por lo que veo en tu query te convendria tener un index en la
>>>>>>>> expresion where
>>>>>>>> o sea my_table tenga un index con where .
>>>>>>>> o mejor.
>>>>>>>>
>>>>>>>> create index my_nombre_de_index on mytable( id ) where id between 1
>>>>>>>> and 10000 ;
>>>>>>>> eso generalmente acelera las cosas.
>>>>>>>> salvo claro esta q ya lo tengas
>>>>>>>> salu2
>>>>>>>> mdc
>>>>>>>>
>>>>>>>>
>>>>>>>> 2011/6/28 Gino Rojas Tillemann <gino(at)masnet(dot)cl>
>>>>>>>>
>>>>>>>>> Hola a todos,
>>>>>>>>>
>>>>>>>>> hace un par de semanas estoy peleando con mi DB y las expresiones
>>>>>>>>> regulares, cada vez que proceso 10 mil registros de un universo de 32
>>>>>>>>> millones el motor demora 7 minutos pegados sin variación en procesar una
>>>>>>>>> cadena de texto por cada registro; para lograr esto creé una función en
>>>>>>>>> plpgsql con (de momento) 40 expresiones regulares (en algunos casos bastante
>>>>>>>>> complejas) y actualizo un campo de una tabla con el resultado del proceso,
>>>>>>>>> algo como esto:
>>>>>>>>>
>>>>>>>>> update my_table set campo_final=fn_regexp(campo1||campo2||campo3)
>>>>>>>>> where id between 1 and 10000
>>>>>>>>>
>>>>>>>>> la función "fn_regexp" contiene la lógica de las expresiones
>>>>>>>>> regulares y la tabla my_table es de 32 millones de registros
>>>>>>>>>
>>>>>>>>> si alguien tiene alguna idea de como optimizar la ejecución de
>>>>>>>>> las expresiones regulares será de gran ayuda, gracias..
>>>>>>>>>
>>>>>>>>> haaa y por fa no me sugieran crear varios threads con otro
>>>>>>>>> lenguaje ya que lo que busco es bajar mis actuales 7 minutos de proceso
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> saludos
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Gino Rojas Tillemann
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Gino Rojas Tillemann
>>>>>>>
>>>>>>> tienes algún criterio que te pueda servir para particionar la
>>>>>>> tabla? pues el particioamiento te puede ayudar.
>>>>>>> saludos
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Gino Rojas Tillemann
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Gino Rojas Tillemann
>>>
>>
>>
>
>
> --
> Gino Rojas Tillemann
>
>
> --
> Marcos Luís Ortíz Valmaseda
> Software Engineer (UCI)
> http://marcosluis2186.posterous.com
> http://twitter.com/marcosluis2186
>
>

--
Gino Rojas Tillemann