|
Una carga exageradamente lenta... Hola a todos, cómo van?? Pues resulta que estoy desarrollando un sistema de información para una empresa, la verdad no es tan complejo... la tabla en este momento que mas tiene registros es una que se llama "aforo" 12.200 registros aprox. Otra tabla tiene 11.100 aprox. Las demás al rededor de los 500, 700 registros. En ese sistema, hay un módulo que se llama "hoja de ruta", lo que hace ese módulo es llevar el "curso" del todo proceso que se le hace a los elemento(vallas, pendones, cajas de lux, los de la tabla aforo). Para resumir y no extenderme tanto, lo que lleva ese seguimiento es: 1. El estado al producir el elemento (si ya se está produciendo o no, osea, creándolo) 2. el estado de operaciones (si ya se montó o no para mostrarlo al público, lo que muchos llámamos "pautar") 3. El reporte fotográfico, es un módulito dentro de la "hoja de ruta" donde se suben imágenes para comprobar que ya esté finalizado el proceso. 4. Pueden agragar observaciones para cada estado, osea, si produjeron, puden escribir observaciones dentro de la hoja, si pautaron pueden escribir observaciones. Estos son los 4 procesos mas importantes de esa módulo, además de esto, maneja estados, fechas, inserciones, modificaciones, consultas, eliminaciones de casi toda la DB, puesto que esta modulo es el que integra y recopila toda la info en él. Todo este preámbulo lo hice para que me ayuden en una cosa, ese módulo está exageradamente lento, la carga de registros, el momento de realizar una actualización, el momento de insertar un registro... Especialmente la carga... todo, todo ese módulo está relentísimo:'(:'(:neurotico De lo que he leido por ahí es que tengo que indexar los campos para las búsquedas, no utilizar "select * ...." Ustedes que mas piensan que puedo hacer para optimizar las consultas y la carga de esa página.. realmente está demasiado lenta(se demora aprox. 20, 22 segundos en cargar). Aclaro que ese módulo "hoja de ruta" no es una tabla de la DB, es un módulo que consulta en los demás tablas y hace joins entre ellas para traer los datos. Espero me puedan ayudar y dar sugerencias...:borracho: Saludos a todos:adios: |
Respuesta: Una carga exageradamente lenta... Si el problema realmente está en la BD, indexa las consultas más lentas, puedes estudiar el plan de ejecución con un EXPLAIN ANALYZE consulta; Hoja de ruta, es buena candidata a ser una vista! Salu2 |
Respuesta: Una carga exageradamente lenta... Ponle índices a los campos que involucres en las consultas (Olvidate del select *), no olvides de hacerles vacuum a las tablas involucradas manualmente si es que postgresql no lo hace automaticamente |
Respuesta: Una carga exageradamente lenta... Sergestux, seyko muchas gracias por sus sugerencias y recomendaciones, mañana me pondré a la tarea de optimizar ese módulo:neurotico:neurotico Sergestux, la verdad no es que sepa mucho de postgres, sé hacer lo básico, insert, update, delete, select pero mas allá de eso, ni idea jeje. Me podrás explicar eso del "vacum"??? Saludos a todos:adios: |
Respuesta: Una carga exageradamente lenta... Cuando borras un registro, en realidad ese espacio fisico no se borra se marca como libre. VACUUM se encarga de "arreglar" esta situación, puedes bajar el intervalo de autovacuum en postgresql.conf. VACUUM ANALYZE actualiza las estadisticas de la tabla, en base a dichas estadisticas, se define el plan de ejecución de las consultas. Más info: http://www.postgresql.org/docs/8.3/i...ql-vacuum.html PD: No uses VACUUM FULL. Salu2 |
Respuesta: Una carga exageradamente lenta... Hola seyko, cómo vas? Tengo muchas cosas pendientes por hacer a esa hoja de ruta:borracho::borracho: Estuve leyendo el link que me dejaste, y me dices que no use VACUMM FULL, dice que es mas lento pero "compacta" y recupera mas espacio libre... Cúal es ese punto a tener en cuenta para no usarlo?? Saludos, de nuevo gracias:arriba::adios: |
Respuesta: Una carga exageradamente lenta... VACUUM FULL libera de verdad todo el espacio marcado como libre y mueve tuplas, es similar a una "defragmentación" de un disco duro, Es lento y bloquea la tabla que procesa! Salu2 |
Respuesta: Una carga exageradamente lenta... Seyko de nuevo gracias!! Me queda claro:arriba: |
Respuesta: Una carga exageradamente lenta... Hola de nuevo, cómo van?? Pues bien, estos días he estado en la tarea de optimizar la "hoja_de_ruta"... Tengo unas dudas respecto a la manera de como lo estoy haciendo... No sé si es posible que me aclaren si lo estoy o no haciendo bien.... En ese link verán lo que intento hacer al momento de "optmizar", aparece, la consulta original y la consulta "optmizada", en "optimizada" dejo una breve explicación de lo que intento... Si quizás no entienden lo que hago.. por fa me preguntan para aclararle, como dije antes, lo que necesito es que me digan si lo que estoy haciendo lo ven bien o se debe hacer de otra manera.... Gracias de antemano:si: Saludos:adios: |
Respuesta: Una carga exageradamente lenta... prueba creando indices en las FK y en los campos que intervengan en el where, por ejemplo: Código: where novedades.usuario_id=usuarios.usuario_id and novedades.cliente_id=clientes.cliente_id and nov_estado=1 and nov_aprobacion=1 and nov_anulada<>1 and nov_subtipo<>4 and nov_subtipo<>8 and nov_fecha between '2006-07-30' and '2008-07-30';A tener en cuenta que el planificador no siempre utilizará un indice, si "cree" que es mejor no usarlo no lo hará, se puede forzar el uso de indices, pero no es muy recomendable. Salu2 |
Respuesta: Una carga exageradamente lenta... Hola seyko, gracias por tu respuesta... intentaré hacer lo que me dices... igual ya tengo en esa consulta que me muestras, dos índices, nov_fecha y nov_estado:neurotico Quiero hacerte un par de consultas: 1. Cuántos índices son recomendables crear en una tabla y/o consulta?? 2. Resulta que un colega me dijo que se puede utilizar dos campos de la tabla como un índice... supón, nov_fecha y nov_subtipo hagan un solo índice... Código: CREATE INDEX estado_fecha_novedad ON novedades USING btree (nov_estado,nov_fecha)Gracias man,:-D:arriba: Saludos:adios: |
Respuesta: Una carga exageradamente lenta... Cita:
Cita:
Tener indices que no se utilicen es contraproducente. Cita:
Es recomendable? Depende! Cada cosa en su sitio, son buenos por ejemplo para PKs de más de un campo, para temas de GIS, etc. Para más info como siempre: http://www.postgresql.org/docs/8.3/i...e/indexes.html Salu2 |
| La zona horaria es GMT -6. Ahora son las 01:26. |
Desarrollado por vBulletin® Versión 3.8.7
Derechos de Autor ©2000 - 2026, Jelsoft Enterprises Ltd.