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 <[email protected]> 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 <[email protected]>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 <[email protected]> >> >>> 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 <[email protected]>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 <[email protected]> >>>> >>>>> 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 <[email protected]> >>>>> >>>>>> 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 <[email protected]> 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 >>>>>>> <[email protected]>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 <[email protected]> >>>>>>>> >>>>>>>>> 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
