Re: Capas de abstracción (fue Re: Postgresql que se muere)
On Jul 15, 2010, at 4:59 PM, Franco Catrin L. wrote: El jue, 15-07-2010 a las 16:19 -0400, Aldrin Martoq escribió: Las capas de abstracción no son para protegernos de los errores, son para *solucionar un problema*. Esto implica que son buenas para cierto ámbito (no para todas) pues están diseñadas para hacer tal o cual cosa. Y deben hacerlo bien. En tu ejemplo del artículo, supongamos que es una biblioteca que le paso una lista y tiene una operación que hace algo con ella (por ejemplo, ordenarla). Siguiendo el ejemplo, tenemos un caso en que tiene la operación tiene muy mal rendimiento (por cómo está construida la biblioteca justo la mala suerte). La postura del artículo es que la biblioteca nos protege o facilita de lo complicado que es el mundo real (el problema de ordenar una lista), por eso a veces te toca bailar con la fea. Pero si cuando construimos la biblioteca, lo que se pidió era resolver el problema de ordenar una lista de manera rápida, entonces el problema es otro: se ignoró dicho requisito (puede ser ambas partes: quien usa la biblioteca como quien la construye, o ambos). El ejemplo va por otro lado. Como programadores asumimos que la memoria es lineal y cada celda tiene el mismo costo de acceso. Esa es la abstracción. La realidad es que la memoria puede estar fragmentada y además tienes sistemas de caché intermedios, por lo que no existe un costo de acceso igual para todos los casos. Sigo insistiendo que te estás enfocando en protegernos del mundo real... ¡las capas son para dar soluciones, no problemas! Cómo una biblioteca te puede proteger de eso si como programador necesitas por ejemplo un array bidimensional que vas a procesar por filas y por columnas indistintamente? Olvídate de los peros, que son excusas y para eso estamos nosotros. Si en cambio nos enfocamos en algún objetivo como: proveer el procesamiento mas rápido de un arreglo ahí los peros que me das desaparecen (indistintivamente del modo de acceso, eso es un problema particular de una implementación). Te olvidas del acceso de memoria, te olvidas incluso que hay CPU pues tenemos a alguien que hace muy bien este tipo de pegas que es la GPU. Es decir, una posible respuesta sería utilizar la GPU la cual tiene buses mucho mas anchos, tienen hasta cientos de Cores que pueden procesar en paralelo, etc. De hecho, hay bibliotecas que hacen este tipo de soluciones hoy en día: el tarro donde escribo lo hace vía OpenCL y gracias a LLVM puede enviar trabajos tanto a la GPU como a la CPU. http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/14 http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/15 Si el objetivo es otro (proveer procesamiento de un arreglo, pero en tiempo real que no sobrepase X tiempo), las soluciones son otras... y así. Es como si llevas el auto a un mecánico y te comienza a chamullar con miles de dramas (no, que ahora tuve este problema, no que ahora se quemó no se que cosa)... puras excusas, pues le pagas al mecánico para resolver tal problema. Si el mecánico no puede preveer este tipo de dramas, está dando un pésimo servicio; hay veces en que esto sucede, pero lo que debe pasar es que el te advierte antes. Algo similar sería que la biblioteca del ejemplo nunca fue declarada performante. De ahí el herramienta adecuada, ¿ves? Por el otro lado, si la biblioteca sí fue declarada como performante, esto es un bug... nada de andar chamullando con leaky abstractions o lo complicado que es la vida. En ese caso, si le pagas al mecánico por resolver un problema puntual, lo puede hacer perfectamente, otra cosa muy distinta es querer que te deje el auto andando. Bueno, yo le pago al mecánico para que me deje andando el auto... Es la clásica confusión entre el que define los requerimientos y el que los tiene que satisfacer. ¡Epa! Una luz de encuentro. La pregunta era entonces: ¿debiera postgresql dar mas información en el error de memoria? Hay millones de ejemplos en la vida real: ir al mecánico, que un doctor te opere de la vesícula, cuando haces un trámite en el banco... Que algo del mundo real falle no es excusa para dar un mal servicio, es lo mismo con una capa de software. Qué me dices del ejemplo en donde los sistemas de seguridad de un auto no ocultan la diferencia entre manejar con o sin lluvia? La capa no es para proteger (ni ocultar) los problemas del mundo real... si algo no está diseñado para manejar con lluvia (o su rendimiento degrada) no lo es y punto (y yo no salgo en moto cuando llueve). A esto me refiero con usar la herramienta adecuada. La capa de software o los servicios siempre tienen un límite en donde no pueden resolver los problemas por si mismos. Es ahí donde salta la excepción. Que estén o no declarados esos límites es otro problema muy distinto, y al final la elegancia con que se resuelven algunos casos puede ser inútil en la práctica, aumentando el costo para el 99%
Re: Postgresql que se muere
El Wed, 14 Jul 2010 17:08:24 -0400 Alvaro Herrera alvhe...@alvh.no-ip.org escribió: (¿Cuántos de aquí usan memoria ECC en sus servidores de datos?) En mi caso NO es asumible no tener ECC en casi ningún servidor productivo, por estúpido y sencillo que sea este. Usar servidores de datos sin ECC es de una cortedad de miras increíble (nunca se me ha dado el caso), y económicamente insignificante. Resumiendo, NUNCA he tenido servidores de datos sin ECC, y espero no tenerlos nunca. Saludos --- Angel
Re: Postgresql que se muere
Excerpts from AngelD's message of vie jul 16 05:37:27 -0400 2010: El Wed, 14 Jul 2010 17:08:24 -0400 Alvaro Herrera alvhe...@alvh.no-ip.org escribió: (¿Cuántos de aquí usan memoria ECC en sus servidores de datos?) En mi caso NO es asumible no tener ECC en casi ningún servidor productivo, por estúpido y sencillo que sea este. Usar servidores de datos sin ECC es de una cortedad de miras increíble (nunca se me ha dado el caso), y económicamente insignificante. En el tercer mundo los presupuestos son diferentes.
Re: Postgresql que se muere
El mié, 14-07-2010 a las 17:16 -0400, Aldrin Martoq escribió: On Jul 14, 2010, at 3:14 PM, Franco Catrin L. wrote: Eso es lo que se ve por fuera, pero el día en que inventen un SELECT que ocupe cero bytes está lejos aún. Lectura recomendada: http://www.joelonsoftware.com/articles/LeakyAbstractions.html Yo difiero de este pensamiento. La capa extra (en este caso, la base de datos) debe ser lo suficientemente robusta para no gotear errores inesperados, pues es quien tiene toda la información de saber qué paso realmente. Mi mirada al documento es respecto a cómo las abstracciones pueden jugar en contra cuando no sabes qué está pasando realmente por debajo, algo que queda claro al leer los comentarios en este thread. Un buen ejemplo que da el autor es cuando recorres una estructura de datos y perfectamente el programador puede recorrerla de una forma que el rendimiento se degrade. Las abstracciones que gotean no son un error, son un hecho. Saludos -- Franco Catrin L. http://www.tuxpan.com/fcatrin TUXPAN Software S.A.
Re: Postgresql que se muere
On Thu, 2010-07-15 at 10:03 -0400, Franco Catrin L. wrote: El mié, 14-07-2010 a las 17:16 -0400, Aldrin Martoq escribió: On Jul 14, 2010, at 3:14 PM, Franco Catrin L. wrote: Eso es lo que se ve por fuera, pero el día en que inventen un SELECT que ocupe cero bytes está lejos aún. Lectura recomendada: http://www.joelonsoftware.com/articles/LeakyAbstractions.html Yo difiero de este pensamiento. La capa extra (en este caso, la base de datos) debe ser lo suficientemente robusta para no gotear errores inesperados, pues es quien tiene toda la información de saber qué paso realmente. Mi mirada al documento es respecto a cómo las abstracciones pueden jugar en contra cuando no sabes qué está pasando realmente por debajo, algo que queda claro al leer los comentarios en este thread. Un buen ejemplo que da el autor es cuando recorres una estructura de datos y perfectamente el programador puede recorrerla de una forma que el rendimiento se degrade. Si quieres ver el otro lado de la moneda, siempre estaran los programadores que piensan que la BD es magica y que sin importar las sentencias SQL que usen, el rendimiento debe ser maximo o superior. Las abstracciones que gotean no son un error, son un hecho. Asi es. El punto es cuanto goteo es razonable o aceptable. Hay cosas que nigun motor puede hacer, como conseguir memoria donde no la hay, pero si puede administrar bien la que tenga. Por citar el mismo ejemplo de Oracle que tu mencionaste antes, hay casos en que una consulta puede ser extremadamente lenta, pero no entrega un error de falta de memoria. Saludos
Re: Postgresql que se muere
On Jul 15, 2010, at 10:03 AM, Franco Catrin L. wrote: El mié, 14-07-2010 a las 17:16 -0400, Aldrin Martoq escribió: On Jul 14, 2010, at 3:14 PM, Franco Catrin L. wrote: Eso es lo que se ve por fuera, pero el día en que inventen un SELECT que ocupe cero bytes está lejos aún. Lectura recomendada: http://www.joelonsoftware.com/articles/LeakyAbstractions.html Yo difiero de este pensamiento. La capa extra (en este caso, la base de datos) debe ser lo suficientemente robusta para no gotear errores inesperados, pues es quien tiene toda la información de saber qué paso realmente. Mi mirada al documento es respecto a cómo las abstracciones pueden jugar en contra cuando no sabes qué está pasando realmente por debajo, algo que queda claro al leer los comentarios en este thread. Un buen ejemplo que da el autor es cuando recorres una estructura de datos y perfectamente el programador puede recorrerla de una forma que el rendimiento se degrade. Las abstracciones que gotean no son un error, son un hecho. No, eso se llama usar la herramienta adecuada. Si estas usando un software para lo que no está hecho, obvio que te vas a topar con cosas para las cuales no estaba preparado. Si volvemos al tema original, el error de postgresql es algo que no espero de una base de datos (bueno, en realidad puede fallar pero el mensaje te deja de manos cruzadas). Y eso independiente de cómo este hecho por debajo. Aldrin Martoq http://aldrin.martoq.cl/
Re: Postgresql que se muere
El jue, 15-07-2010 a las 13:02 -0400, Aldrin Martoq escribió: On Jul 15, 2010, at 10:03 AM, Franco Catrin L. wrote: El mié, 14-07-2010 a las 17:16 -0400, Aldrin Martoq escribió: On Jul 14, 2010, at 3:14 PM, Franco Catrin L. wrote: Eso es lo que se ve por fuera, pero el día en que inventen un SELECT que ocupe cero bytes está lejos aún. Lectura recomendada: http://www.joelonsoftware.com/articles/LeakyAbstractions.html Yo difiero de este pensamiento. La capa extra (en este caso, la base de datos) debe ser lo suficientemente robusta para no gotear errores inesperados, pues es quien tiene toda la información de saber qué paso realmente. Mi mirada al documento es respecto a cómo las abstracciones pueden jugar en contra cuando no sabes qué está pasando realmente por debajo, algo que queda claro al leer los comentarios en este thread. Un buen ejemplo que da el autor es cuando recorres una estructura de datos y perfectamente el programador puede recorrerla de una forma que el rendimiento se degrade. Las abstracciones que gotean no son un error, son un hecho. No, eso se llama usar la herramienta adecuada. Si estas usando un software para lo que no está hecho, obvio que te vas a topar con cosas para las cuales no estaba preparado. No entiendo la relación? Leíste el artículo completo? Si volvemos al tema original, el error de postgresql es algo que no espero de una base de datos (bueno, en realidad puede fallar pero el mensaje te deja de manos cruzadas). Y eso independiente de cómo este hecho por debajo. Por qué no? Es una situación de excepción, al igual que cuando el cliente te avisa que no se puede conectar a la base de datos. Si te fijas, el error dice que no pudo obtener la memoria que necesitaba para realizar la operación, algo que siempre puede suceder. En este caso es claro que no se justifica y el motor se confundió al estimar el tamaño, pero en el normal de los casos sí debería retornar una excepción cuando no puede hacer lo qué le estás pidiendo. ERROR: invalid memory alloc request size 1818585462 Puesto de otra forma, qué hubieras esperado que te informara el servidor si no hay suficiente memoria para realizar la operación? Datos inventados? Saludos -- Franco Catrin L. http://www.tuxpan.com/fcatrin TUXPAN Software S.A.
Capas de abstracción (fue Re: Postgresql que se muere)
On Jul 15, 2010, at 3:15 PM, Franco Catrin L. wrote: El jue, 15-07-2010 a las 13:02 -0400, Aldrin Martoq escribió: On Jul 15, 2010, at 10:03 AM, Franco Catrin L. wrote: Mi mirada al documento es respecto a cómo las abstracciones pueden jugar en contra cuando no sabes qué está pasando realmente por debajo, algo que queda claro al leer los comentarios en este thread. Un buen ejemplo que da el autor es cuando recorres una estructura de datos y perfectamente el programador puede recorrerla de una forma que el rendimiento se degrade. Las abstracciones que gotean no son un error, son un hecho. No, eso se llama usar la herramienta adecuada. Si estas usando un software para lo que no está hecho, obvio que te vas a topar con cosas para las cuales no estaba preparado. No entiendo la relación? Leíste el artículo completo? Si volvemos al tema original, el error de postgresql es algo que no espero de una base de datos (bueno, en realidad puede fallar pero el mensaje te deja de manos cruzadas). Y eso independiente de cómo este hecho por debajo. Las capas de abstracción no son para protegernos de los errores, son para *solucionar un problema*. Esto implica que son buenas para cierto ámbito (no para todas) pues están diseñadas para hacer tal o cual cosa. Y deben hacerlo bien. En tu ejemplo del artículo, supongamos que es una biblioteca que le paso una lista y tiene una operación que hace algo con ella (por ejemplo, ordenarla). Siguiendo el ejemplo, tenemos un caso en que tiene la operación tiene muy mal rendimiento (por cómo está construida la biblioteca justo la mala suerte). La postura del artículo es que la biblioteca nos protege o facilita de lo complicado que es el mundo real (el problema de ordenar una lista), por eso a veces te toca bailar con la fea. Pero si cuando construimos la biblioteca, lo que se pidió era resolver el problema de ordenar una lista de manera rápida, entonces el problema es otro: se ignoró dicho requisito (puede ser ambas partes: quien usa la biblioteca como quien la construye, o ambos). Es como si llevas el auto a un mecánico y te comienza a chamullar con miles de dramas (no, que ahora tuve este problema, no que ahora se quemó no se que cosa)... puras excusas, pues le pagas al mecánico para resolver tal problema. Si el mecánico no puede preveer este tipo de dramas, está dando un pésimo servicio; hay veces en que esto sucede, pero lo que debe pasar es que el te advierte antes. Algo similar sería que la biblioteca del ejemplo nunca fue declarada performante. De ahí el herramienta adecuada, ¿ves? Por el otro lado, si la biblioteca sí fue declarada como performante, esto es un bug... nada de andar chamullando con leaky abstractions o lo complicado que es la vida. Hay millones de ejemplos en la vida real: ir al mecánico, que un doctor te opere de la vesícula, cuando haces un trámite en el banco... Que algo del mundo real falle no es excusa para dar un mal servicio, es lo mismo con una capa de software. Por qué no? Es una situación de excepción, al igual que cuando el cliente te avisa que no se puede conectar a la base de datos. Si te fijas, el error dice que no pudo obtener la memoria que necesitaba para realizar la operación, algo que siempre puede suceder. En este caso es claro que no se justifica y el motor se confundió al estimar el tamaño, pero en el normal de los casos sí debería retornar una excepción cuando no puede hacer lo qué le estás pidiendo. ERROR: invalid memory alloc request size 1818585462 Puesto de otra forma, qué hubieras esperado que te informara el servidor si no hay suficiente memoria para realizar la operación? Datos inventados? Es todo lo contrario: nosotros estamos inventando (como tu bien dices) qué fue lo que paso. En cambio, postgresql (o nuestra capa de abstracción) está en la fuente del error... tiene toda la información a mano que puede perfectamente desplegar; el ejemplo claro es que si es el campo de un índice cuyo tamaño se fue a las pailas, podría dar el nombre del desdichado. ¡Si para eso le pago al mecánico! Y de hecho, una vez que comienzas a ver mas seguido estaría mas claro el siguiente problema: por qué se corrompen los índices y/o cómo evitarlo... Aldrin Martoq http://aldrin.martoq.cl/
Re: Capas de abstracción (fue Re: Postgresql que se muere)
El jue, 15-07-2010 a las 16:19 -0400, Aldrin Martoq escribió: On Jul 15, 2010, at 3:15 PM, Franco Catrin L. wrote: El jue, 15-07-2010 a las 13:02 -0400, Aldrin Martoq escribió: On Jul 15, 2010, at 10:03 AM, Franco Catrin L. wrote: Mi mirada al documento es respecto a cómo las abstracciones pueden jugar en contra cuando no sabes qué está pasando realmente por debajo, algo que queda claro al leer los comentarios en este thread. Un buen ejemplo que da el autor es cuando recorres una estructura de datos y perfectamente el programador puede recorrerla de una forma que el rendimiento se degrade. Las abstracciones que gotean no son un error, son un hecho. No, eso se llama usar la herramienta adecuada. Si estas usando un software para lo que no está hecho, obvio que te vas a topar con cosas para las cuales no estaba preparado. No entiendo la relación? Leíste el artículo completo? Si volvemos al tema original, el error de postgresql es algo que no espero de una base de datos (bueno, en realidad puede fallar pero el mensaje te deja de manos cruzadas). Y eso independiente de cómo este hecho por debajo. Las capas de abstracción no son para protegernos de los errores, son para *solucionar un problema*. Esto implica que son buenas para cierto ámbito (no para todas) pues están diseñadas para hacer tal o cual cosa. Y deben hacerlo bien. En tu ejemplo del artículo, supongamos que es una biblioteca que le paso una lista y tiene una operación que hace algo con ella (por ejemplo, ordenarla). Siguiendo el ejemplo, tenemos un caso en que tiene la operación tiene muy mal rendimiento (por cómo está construida la biblioteca justo la mala suerte). La postura del artículo es que la biblioteca nos protege o facilita de lo complicado que es el mundo real (el problema de ordenar una lista), por eso a veces te toca bailar con la fea. Pero si cuando construimos la biblioteca, lo que se pidió era resolver el problema de ordenar una lista de manera rápida, entonces el problema es otro: se ignoró dicho requisito (puede ser ambas partes: quien usa la biblioteca como quien la construye, o ambos). El ejemplo va por otro lado. Como programadores asumimos que la memoria es lineal y cada celda tiene el mismo costo de acceso. Esa es la abstracción. La realidad es que la memoria puede estar fragmentada y además tienes sistemas de caché intermedios, por lo que no existe un costo de acceso igual para todos los casos. Cómo una biblioteca te puede proteger de eso si como programador necesitas por ejemplo un array bidimensional que vas a procesar por filas y por columnas indistintamente? Es como si llevas el auto a un mecánico y te comienza a chamullar con miles de dramas (no, que ahora tuve este problema, no que ahora se quemó no se que cosa)... puras excusas, pues le pagas al mecánico para resolver tal problema. Si el mecánico no puede preveer este tipo de dramas, está dando un pésimo servicio; hay veces en que esto sucede, pero lo que debe pasar es que el te advierte antes. Algo similar sería que la biblioteca del ejemplo nunca fue declarada performante. De ahí el herramienta adecuada, ¿ves? Por el otro lado, si la biblioteca sí fue declarada como performante, esto es un bug... nada de andar chamullando con leaky abstractions o lo complicado que es la vida. En ese caso, si le pagas al mecánico por resolver un problema puntual, lo puede hacer perfectamente, otra cosa muy distinta es querer que te deje el auto andando. Es la clásica confusión entre el que define los requerimientos y el que los tiene que satisfacer. Hay millones de ejemplos en la vida real: ir al mecánico, que un doctor te opere de la vesícula, cuando haces un trámite en el banco... Que algo del mundo real falle no es excusa para dar un mal servicio, es lo mismo con una capa de software. Qué me dices del ejemplo en donde los sistemas de seguridad de un auto no ocultan la diferencia entre manejar con o sin lluvia? La capa de software o los servicios siempre tienen un límite en donde no pueden resolver los problemas por si mismos. Es ahí donde salta la excepción. Que estén o no declarados esos límites es otro problema muy distinto, y al final la elegancia con que se resuelven algunos casos puede ser inútil en la práctica, aumentando el costo para el 99% de los casos sólo por el 1% de los casos (o menos). En mi opinión la perfección tiene un costo que tiende a infinito. Por qué no? Es una situación de excepción, al igual que cuando el cliente te avisa que no se puede conectar a la base de datos. Si te fijas, el error dice que no pudo obtener la memoria que necesitaba para realizar la operación, algo que siempre puede suceder. En este caso es claro que no se justifica y el motor se confundió al estimar el tamaño, pero en el normal de los casos sí debería retornar una excepción cuando no puede hacer lo qué le estás pidiendo. ERROR: invalid memory alloc request
Re: Postgresql que se muere
Excerpts from Ricardo Munoz's message of mar jul 13 16:51:29 -0400 2010: da para pensar como tanta gente hizo la pega (buscar en Google) del autor del primer mail y/o respondieron a la rapida y mal. cualquier usuario de un motor de base de datos debe saber que - el resultado de un SELECT nunca puede ser un mensaje de error de memoria Te equivocas, sí puede darse este caso. En Postgres, posibles motivos hay varios (de menos a más probable): - el SELECT invoca alguna función con efectos secundarios que ocupa mucha memoria. Normalmente las funciones que uno pone en un SELECT no tienen efectos secundarios. Esto es hipotético; yo no lo he visto nunca en el mundo real. - un plan de ejecución resulta más caro en memoria de lo que el optimizador determinó. Esto es raro pero se ve; la causa más frecuente es que tienes un valor de work_mem demasiado grande. La mayoría de los nodos de ejecución sólo ocupan work_mem de memoria como máximo, y por lo tanto en un sistema bien configurado no debería pasar. La única excepción es agregación usando hash (HashAggregate), que el optimizador puede *estimar* que va a necesitar X memoria (y lo limita a work_mem), pero si la estimación de la cantidad de valores distintos (es decir, tamaño de la tabla de hash) es mala por cualquier motivo, entonces puede terminar ocupando más memoria. - El proceso tiene un límite de memoria (ulimit) menor al que el optimizador quiere ocupar. - Existe otro proceso que está ocupando memoria, y el servidor se queda corto de memoria física y swap. (Creo que tienes que tener overcommit deshabilitado para que esto se reporte; de lo contrario lo que sucede es que entra en acción el OOM-killer, y los síntomas son muy diferentes). Por ej. si tienes uno o más procesos vacuum corriendo y tu maintenance_work_mem es muy alto. Esto es medianamente frecuente (hay como un reporte cada dos o tres meses en las listas pgsql) Y finalmente, la causa más probable ya la mencioné en una respuesta anterior: - Existen datos corruptos que hacen que el sistema intente emplazar una cantidad ridícula de memoria; particularmente un puntero TOAST corrupto. Los punteros TOAST incluyen el tamaño total del dato almacenado; si esto está corrupto, el resultado es que el software puede intentar hacer malloc() de cualquier valor (hasta 2^32-1 si mal no recuerdo). - el resultado de un servicio mal optimizado nunca puede ser un mensaje de error de memoria durante su operacion (instruccion SELECT), sino solo al momento de subir el servicio Hmm, no necesariamente ... por lo tanto, la unica explicacion logica al problema es que - se trata de un bug de Postgres, donde la solucion es actualizar ojala usando el metodo ofrecido por la distro de Linux - se trata de un error de hardware (memoria o disco), donde la solucion es reemplazar el hardware malo o cambiar el servicio a otra maquina También puede ser un error de configuración; por ejemplo si los discos tienen cache de escritura activo y ocurre una caída, puede resultar que una de las últimas escrituras no haya alcanzado a grabarse. Esto no sucede en un sistema bien configurado. (Alternativamente, si quieres tener muy buen rendimiento, puedes poner un controlador RAID con cache respaldado por baterías, para protegerte en caso de corte abrupto de energía).
Re: Postgresql que se muere
On Tue, 2010-07-13 at 17:46 -0400, Franco Catrin L. wrote: hmm... insisto que ningun motor de base de datos decente deberia retornar un mensaje de error de memoria como resultado de un SELECT Por qué no? A mi me parece razonable que el motor tire un error de falta de memoria... cuando le falta memoria para procesar el select. Al contrario. Esto indica que tu BD no es confiable; y si ya con select se cae, ¿Que podrias esperar al hacer un insert/update? En este caso, habria que revisar si se trata del fierro, o en caso contrario actualizar lo mas rapido posible. Saludos -- Marcos Ramirez mramir...@armada.cl Documento Publico
Re: Postgresql que se muere
El 14 de julio de 2010 15:14, Franco Catrin L. fcat...@tuxpan.comescribió: El mar, 13-07-2010 a las 18:14 -0400, Ricardo Munoz escribió: El 13 de julio de 2010 17:46, Franco Catrin L. fcat...@tuxpan.com escribió: El mar, 13-07-2010 a las 17:28 -0400, Ricardo Munoz escribió: [...] hmm... insisto que ningun motor de base de datos decente deberia retornar un mensaje de error de memoria como resultado de un SELECT Por qué no? A mi me parece razonable que el motor tire un error de falta de memoria... cuando le falta memoria para procesar el select. eso quiere decir que tendrias que poner mas memoria a tu servidor por cada n-cantidad de nuevos registros que le agregas a la base de datos? eso no tiene sentido... y fijate que el error se produjo con un simple SELECT COUNT()... Eso es lo que se ve por fuera, pero el día en que inventen un SELECT que ocupe cero bytes está lejos aún. Lectura recomendada: http://www.joelonsoftware.com/articles/LeakyAbstractions.html ... y por supuesto, la explicación detallada de Alvaro sobre lo que sucede behind the scenes. -- Franco Catrin L. http://www.tuxpan.com/fcatrin TUXPAN Software S.A. Si un SELECT no pudiera retornar errores de memoria, ¿para que diablos habrán inventado el sistema de excepciones en postgresql? Cabe recordar que un SP se puede programar varios lenguajes ajenos. -- ~~~ Atentamente, Gonzalo Díaz Cruz Estudiante Ingeniería de Ejecución en Computación e Informática Universidad de Santiago de Chile ~~~ http://blog.gon.cl/ http://twitter.com/sir_gon http://flickr.com/photos/sir_gon
Re: Postgresql que se muere
Hola! 2010/7/14 Gonzalo Diaz m...@gon.cl Si un SELECT no pudiera retornar errores de memoria, ¿para que diablos habrán inventado el sistema de excepciones en postgresql? Las excepciones van dentro del codigo de PL/SQL. En este caso especifico, el motor de DB es el que esta teniendo el problema. Recomendado? Leer un buen libro de PL/SQL de pasadita para entender las excepciones ;-) Cabe recordar que un SP se puede programar varios lenguajes ajenos. Tecnicamente, si. Aqui no estamos hablando de procedimientos almacenados, sino un problema dado en una consulta que se ve inocente. Puede ser incluso que el dise~o de la tabla este medio malena. Pero bueh, eso ya queda para el que quiera dentrar a cepillar. Saludos! -- Juan C. Inostroza j...@codemonkey.cl
Re: Postgresql que se muere
El mié, 14-07-2010 a las 15:31 -0400, Gonzalo Diaz escribió: El 14 de julio de 2010 15:14, Franco Catrin L. fcat...@tuxpan.comescribió: El mar, 13-07-2010 a las 18:14 -0400, Ricardo Munoz escribió: El 13 de julio de 2010 17:46, Franco Catrin L. fcat...@tuxpan.com escribió: El mar, 13-07-2010 a las 17:28 -0400, Ricardo Munoz escribió: [...] hmm... insisto que ningun motor de base de datos decente deberia retornar un mensaje de error de memoria como resultado de un SELECT Por qué no? A mi me parece razonable que el motor tire un error de falta de memoria... cuando le falta memoria para procesar el select. eso quiere decir que tendrias que poner mas memoria a tu servidor por cada n-cantidad de nuevos registros que le agregas a la base de datos? eso no tiene sentido... y fijate que el error se produjo con un simple SELECT COUNT()... Eso es lo que se ve por fuera, pero el día en que inventen un SELECT que ocupe cero bytes está lejos aún. Lectura recomendada: http://www.joelonsoftware.com/articles/LeakyAbstractions.html ... y por supuesto, la explicación detallada de Alvaro sobre lo que sucede behind the scenes. Si un SELECT no pudiera retornar errores de memoria, ¿para que diablos habrán inventado el sistema de excepciones en postgresql? Cabe recordar que un SP se puede programar varios lenguajes ajenos. Eso es lo que se ve por fuera, pero el día en que inventen un sistema de excepciones que ocupe cero bytes está lejos aún. Lectura recomendada: http://www.joelonsoftware.com/articles/LeakyAbstractions.html BTW: Creo que me haré un template para responder estos correos. -- Franco Catrin L. http://www.tuxpan.com/fcatrin TUXPAN Software S.A.
Re: Postgresql que se muere
On Wed, 2010-07-14 at 15:45 -0400, Franco Catrin L. wrote: El mié, 14-07-2010 a las 15:31 -0400, Gonzalo Diaz escribió: eso quiere decir que tendrias que poner mas memoria a tu servidor por cada n-cantidad de nuevos registros que le agregas a la base de datos? eso no tiene sentido... y fijate que el error se produjo con un simple SELECT COUNT()... Eso es lo que se ve por fuera, pero el día en que inventen un SELECT que ocupe cero bytes está lejos aún. Lectura recomendada: http://www.joelonsoftware.com/articles/LeakyAbstractions.html ... y por supuesto, la explicación detallada de Alvaro sobre lo que sucede behind the scenes. Si un SELECT no pudiera retornar errores de memoria, ¿para que diablos habrán inventado el sistema de excepciones en postgresql? Cabe recordar que un SP se puede programar varios lenguajes ajenos. Eso es lo que se ve por fuera, pero el día en que inventen un sistema de excepciones que ocupe cero bytes está lejos aún. Estas perdiendo el punto. No se trata de cuantos bytes ocupe el select/procedimiento o de si un procedimiento puede o no arrojar una excepcion; sino que el motor no traspase errores que son inmanejables a nivel de aplicacion. Por seguir tu linea: si se considera aceptable que el motor entregue un error al hacer un [simple] select, ¿que deberia hacer la aplicacion? ¿reintentar hasta que funcione, reemplazar la funcionalidad del motor por una propia, otra? Si yo estuviera frente a esa disyuntiva, me deshago del motor, o lo cambio por otro mas confiable. O simplemente que la aplicacion maneje los archivos directamente. Distinto es el caso cuando hay un problema subyacente, como error de memoria, disco corrupto o similar, en cuyo caso, se cambia la maquina. Saludos -- Marcos Ramirez mramir...@armada.cl Documento PUBLICO
Re: Postgresql que se muere
Excerpts from Franco Catrin L.'s message of mié jul 14 15:45:15 -0400 2010: El mié, 14-07-2010 a las 15:31 -0400, Gonzalo Diaz escribió: Si un SELECT no pudiera retornar errores de memoria, ¿para que diablos habrán inventado el sistema de excepciones en postgresql? Cabe recordar que un SP se puede programar varios lenguajes ajenos. Eso es lo que se ve por fuera, pero el día en que inventen un sistema de excepciones que ocupe cero bytes está lejos aún. Lectura recomendada: http://www.joelonsoftware.com/articles/LeakyAbstractions.html El código de manejo de errores en Postgres tiene un poco de memoria reservada de antemano, de manera que cuando el sistema se queda sin memoria, el error se pueda reportar correctamente. No ocupa cero bytes, pero no importa porque lo tiene contemplado ...
Re: Postgresql que se muere
El 14 de julio de 2010 15:57, Marcos Ramirez mramir...@armada.cl escribió: On Wed, 2010-07-14 at 15:45 -0400, Franco Catrin L. wrote: El mié, 14-07-2010 a las 15:31 -0400, Gonzalo Diaz escribió: eso quiere decir que tendrias que poner mas memoria a tu servidor por cada n-cantidad de nuevos registros que le agregas a la base de datos? eso no tiene sentido... y fijate que el error se produjo con un simple SELECT COUNT()... Eso es lo que se ve por fuera, pero el día en que inventen un SELECT que ocupe cero bytes está lejos aún. Lectura recomendada: http://www.joelonsoftware.com/articles/LeakyAbstractions.html ... y por supuesto, la explicación detallada de Alvaro sobre lo que sucede behind the scenes. Si un SELECT no pudiera retornar errores de memoria, ¿para que diablos habrán inventado el sistema de excepciones en postgresql? Cabe recordar que un SP se puede programar varios lenguajes ajenos. Eso es lo que se ve por fuera, pero el día en que inventen un sistema de excepciones que ocupe cero bytes está lejos aún. Estas perdiendo el punto. No se trata de cuantos bytes ocupe el select/procedimiento o de si un procedimiento puede o no arrojar una excepcion; sino que el motor no traspase errores que son inmanejables a nivel de aplicacion. Por seguir tu linea: si se considera aceptable que el motor entregue un error al hacer un [simple] select, ¿que deberia hacer la aplicacion? ¿reintentar hasta que funcione, reemplazar la funcionalidad del motor por una propia, otra? Si yo estuviera frente a esa disyuntiva, me deshago del motor, o lo cambio por otro mas confiable. O simplemente que la aplicacion maneje los archivos directamente. exactamente ese era mi punto cuando puse que un SELECT no deberia retornar un error de memoria... de que sirve el motor de base de datos si no me asegura un correcto funcionamiento bajo condiciones normales (hw sin problemas)? y si el sysadmin se condorea con los distintos parametros de configuracion, el servicio simplemente no deberia activarse a menos que pueda asegurar un correcto funcionamiento (lento pero seguro). Distinto es el caso cuando hay un problema subyacente, como error de memoria, disco corrupto o similar, en cuyo caso, se cambia la maquina. exacto. -- Ricardo Mun~oz A. http://www.tux.cl
Re: Postgresql que se muere
El mié, 14-07-2010 a las 15:57 -0400, Marcos Ramirez escribió: On Wed, 2010-07-14 at 15:45 -0400, Franco Catrin L. wrote: El mié, 14-07-2010 a las 15:31 -0400, Gonzalo Diaz escribió: eso quiere decir que tendrias que poner mas memoria a tu servidor por cada n-cantidad de nuevos registros que le agregas a la base de datos? eso no tiene sentido... y fijate que el error se produjo con un simple SELECT COUNT()... Eso es lo que se ve por fuera, pero el día en que inventen un SELECT que ocupe cero bytes está lejos aún. Lectura recomendada: http://www.joelonsoftware.com/articles/LeakyAbstractions.html ... y por supuesto, la explicación detallada de Alvaro sobre lo que sucede behind the scenes. Si un SELECT no pudiera retornar errores de memoria, ¿para que diablos habrán inventado el sistema de excepciones en postgresql? Cabe recordar que un SP se puede programar varios lenguajes ajenos. Eso es lo que se ve por fuera, pero el día en que inventen un sistema de excepciones que ocupe cero bytes está lejos aún. Estas perdiendo el punto. No se trata de cuantos bytes ocupe el select/procedimiento o de si un procedimiento puede o no arrojar una excepcion; sino que el motor no traspase errores que son inmanejables a nivel de aplicacion. Por seguir tu linea: si se considera aceptable que el motor entregue un error al hacer un [simple] select, ¿que deberia hacer la aplicacion? ¿reintentar hasta que funcione, reemplazar la funcionalidad del motor por una propia, otra? Si yo estuviera frente a esa disyuntiva, me deshago del motor, o lo cambio por otro mas confiable. O simplemente que la aplicacion maneje los archivos directamente. Distinto es el caso cuando hay un problema subyacente, como error de memoria, disco corrupto o similar, en cuyo caso, se cambia la maquina. Parece que todos perdimos el punto hace rato. Viendo el error que aparece en el post original, no me es evidente que PostgreSQL se haya ido al suelo, también puede ser un error reportado por el sistema de excepciones. Sólo se ve un copy/paste de una sesión de terminal, pero no sabemos como si el motor reportó o no el mensaje que muestra el terminal. En oracle diría ORA-04030 para reportar el mismo problema. Saludos -- Franco Catrin L. http://www.tuxpan.com/fcatrin TUXPAN Software S.A.
Re: Postgresql que se muere
Excerpts from Ricardo Munoz's message of mié jul 14 16:51:26 -0400 2010: El 14 de julio de 2010 15:57, Marcos Ramirez mramir...@armada.cl escribió: Por seguir tu linea: si se considera aceptable que el motor entregue un error al hacer un [simple] select, ¿que deberia hacer la aplicacion? ¿reintentar hasta que funcione, reemplazar la funcionalidad del motor por una propia, otra? Si yo estuviera frente a esa disyuntiva, me deshago del motor, o lo cambio por otro mas confiable. O simplemente que la aplicacion maneje los archivos directamente. exactamente ese era mi punto cuando puse que un SELECT no deberia retornar un error de memoria... de que sirve el motor de base de datos si no me asegura un correcto funcionamiento bajo condiciones normales (hw sin problemas)? Huh. Lo correcto es que la aplicación registre el error, le de un mensaje al usuario lo siento, no podemos atenderlo en este momento, intente de nuevo más tarde, y le mande un mensaje al admin para que le eche una mirada. Si es un bug en la aplicación, se corrige; si es un problema en los datos, se agrega una nueva restricción (constraint). Si es un problema de hardware, se cambia el servidor. Y así. Pero es totalmente responsabilidad de la aplicación asegurarse que actúa sano en casos inesperados. Me acuerdo que en un proyecto en que trabajaba en una empresa, el módulo que recibía el código SQL para ejecutar mandaba cualquier excepción por correo. Recibimos dos o tres correos durante el período de producción en que yo estuve en la empresa (obviamente cientos de ellos durante el desarrollo y la marcha blanca), si mal no recuerdo uno de ellos era un problema corregible y los restantes eran mala suerte, cosas de la vida o eventos totalmente inesperados. y si el sysadmin se condorea con los distintos parametros de configuracion, el servicio simplemente no deberia activarse a menos que pueda asegurar un correcto funcionamiento (lento pero seguro). Las fallas siempre ocurren. No estar preparado para ellas es síntoma de mala ingeniería. Aún cuando tengas el mejor hardware del mundo y el sistema mejor afinado del mundo, te pueden caer rayos cósmicos en cualquier momento en una celda de la RAM y cambiarte un bit en los datos. (¿Cuántos de aquí usan memoria ECC en sus servidores de datos?)
Re: Postgresql que se muere
Excerpts from Franco Catrin L.'s message of mié jul 14 17:05:43 -0400 2010: Parece que todos perdimos el punto hace rato. Viendo el error que aparece en el post original, no me es evidente que PostgreSQL se haya ido al suelo, también puede ser un error reportado por el sistema de excepciones. Huh, claramente *es* un error reportado por el “sistema de excepciones” (de Postgres), y lo más probable es que ese mismo error haya aparecido de una u otra forma en la aplicación. Postgres no se “fue al suelo”, sólo fue incapaz de contestar una consulta en particular. Respecto del problema subyacente, le eché un cable a Andrés en privado a ver si puede sacar algo en limpio.
Re: Postgresql que se muere
On Jul 14, 2010, at 3:14 PM, Franco Catrin L. wrote: Eso es lo que se ve por fuera, pero el día en que inventen un SELECT que ocupe cero bytes está lejos aún. Lectura recomendada: http://www.joelonsoftware.com/articles/LeakyAbstractions.html Yo difiero de este pensamiento. La capa extra (en este caso, la base de datos) debe ser lo suficientemente robusta para no gotear errores inesperados, pues es quien tiene toda la información de saber qué paso realmente. ... y por supuesto, la explicación detallada de Alvaro sobre lo que sucede behind the scenes. Yo también insisto que es un bug de postgresql. Para este ejemplo en particular, la base de datos puede hacer un montón de cosas como dado que es un problema de memoría reportar qué cosa generó el error (en particular, el índice TOAST que se fue a las pailas). Aunque postgresql lo está haciendo bien (manejar el error), le falta avanzar al siguiente nivel y esto es algo mejorable y por ende, un bug. Aldrin Martoq http://aldrin.martoq.cl/
Re: Postgresql que se muere
Excerpts from Aldrin Martoq's message of mié jul 14 17:16:51 -0400 2010: Yo también insisto que es un bug de postgresql. Para este ejemplo en particular, la base de datos puede hacer un montón de cosas como dado que es un problema de memoría reportar qué cosa generó el error (en particular, el índice TOAST que se fue a las pailas). No es un error de memoria. Ese es sólo el síntoma. El problema es que los datos están corruptos.
Re: Postgresql que se muere
On Wed, 2010-07-14 at 17:05 -0400, Franco Catrin L. wrote: Parece que todos perdimos el punto hace rato. Me recuerda los dias mas brillantes de esta lista :) Viendo el error que aparece en el post original, no me es evidente que PostgreSQL se haya ido al suelo, también puede ser un error reportado por el sistema de excepciones. Sólo se ve un copy/paste de una sesión de terminal, pero no sabemos como si el motor reportó o no el mensaje que muestra el terminal. Como toda discusion, esta evoluciono hacia partes que no eran el sentido original. Tienes razon que el error por si mismo puede tener varias causas/origenes. Mi punto es que no en todos esos casos es aceptable quie el motor te entregue un error. Y si te encuentras con tal motor, lo mejor es desecharlo porque no esta cumpliendo su tarea. En las causas que si son aceptables (fierro principalmente) se agredece que el motor haga lo mejor posible para no terminar con datos corruptos o inconsistentes. En oracle diría ORA-04030 para reportar el mismo problema. Ojo que este error es consecuencia directa de un problema de configuracion de Oracle (PGA / parametros del kernel / sort area, entre otros). Una BD configurada correctamente no debiera darte este error. Hasta este punto, ni siquiera estamos hablando de si la respuesta es rapida o no (eso ya es tema del tuning). Saludos
Re: Postgresql que se muere
On Jul 14, 2010, at 5:20 PM, Alvaro Herrera wrote: Excerpts from Aldrin Martoq's message of mié jul 14 17:16:51 -0400 2010: Yo también insisto que es un bug de postgresql. Para este ejemplo en particular, la base de datos puede hacer un montón de cosas como dado que es un problema de memoría reportar qué cosa generó el error (en particular, el índice TOAST que se fue a las pailas). No es un error de memoria. Ese es sólo el síntoma. El problema es que los datos están corruptos. Si es un error de memoria, el sistema lo dice clarito :) La causa puede ser cualquier cosa, desde datos corruptos a problemas de hardware más los otros posibles que diste. Lo que falta es que el error dé indicaciones de dónde ocurrió el problema. Aldrin Martoq http://aldrin.martoq.cl/
Re: Postgresql que se muere
Para volver a la discusión original, lo que yo haría: 1.- Probar la memoria con memtest86+ o similar 2.- Actualizar a las últimas versiones de PostgreSQL servidor y cliente, de ser posible 3.- Investigar si existe un bug relacionado Suerte 2010/7/14 Aldrin Martoq amar...@dcc.uchile.cl On Jul 14, 2010, at 5:20 PM, Alvaro Herrera wrote: Excerpts from Aldrin Martoq's message of mié jul 14 17:16:51 -0400 2010: Yo también insisto que es un bug de postgresql. Para este ejemplo en particular, la base de datos puede hacer un montón de cosas como dado que es un problema de memoría reportar qué cosa generó el error (en particular, el índice TOAST que se fue a las pailas). No es un error de memoria. Ese es sólo el síntoma. El problema es que los datos están corruptos. Si es un error de memoria, el sistema lo dice clarito :) La causa puede ser cualquier cosa, desde datos corruptos a problemas de hardware más los otros posibles que diste. Lo que falta es que el error dé indicaciones de dónde ocurrió el problema. Aldrin Martoq http://aldrin.martoq.cl/ -- Atte, Juan Cristóbal Olivares חואנכרי == Renovarse o morir: Mi PC de los sesenta tenía veinte mil militantes. Y mi PC del siglo XXI tiene cuarenta gigabytes.
Re: Postgresql que se muere
quizas posgtres no esta consumiendo toda la memoria, sino la que queda disponible... y ese es su limite.. 2010/7/14 Juan C. Olivares juan...@juancri.com Para volver a la discusión original, lo que yo haría: 1.- Probar la memoria con memtest86+ o similar 2.- Actualizar a las últimas versiones de PostgreSQL servidor y cliente, de ser posible 3.- Investigar si existe un bug relacionado Suerte 2010/7/14 Aldrin Martoq amar...@dcc.uchile.cl On Jul 14, 2010, at 5:20 PM, Alvaro Herrera wrote: Excerpts from Aldrin Martoq's message of mié jul 14 17:16:51 -0400 2010: Yo también insisto que es un bug de postgresql. Para este ejemplo en particular, la base de datos puede hacer un montón de cosas como dado que es un problema de memoría reportar qué cosa generó el error (en particular, el índice TOAST que se fue a las pailas). No es un error de memoria. Ese es sólo el síntoma. El problema es que los datos están corruptos. Si es un error de memoria, el sistema lo dice clarito :) La causa puede ser cualquier cosa, desde datos corruptos a problemas de hardware más los otros posibles que diste. Lo que falta es que el error dé indicaciones de dónde ocurrió el problema. Aldrin Martoq http://aldrin.martoq.cl/ -- Atte, Juan Cristóbal Olivares חואנכרי == Renovarse o morir: Mi PC de los sesenta tenía veinte mil militantes. Y mi PC del siglo XXI tiene cuarenta gigabytes. -- Eduardo Silva http://edsiper.linuxchile.cl http://www.monkey-project.com
Re: Postgresql que se muere
On 13/07/10 02:21, Andres Junge wrote: Hola Tenemos un servidor con Asterisk el cual registra todas las llamadas que pasan por el en un servidor postgresql. Todo andaba bien hasta que derrepente el postgresql dejo de atender algunas consultas. Por ejemplo si le envio: asterisk= SELECT COUNT(*) AS count FROM uso_detalle_anexo WHERE dst = '98263186' AND anexo = '117' AND anyo = '2008' AND mes = '12'; ERROR: invalid memory alloc request size 1818585462 Que podra ser. Por donde buscamos? buscando en google por ERROR: invalid memory alloc request size me dio esto(traducido se entiende mejor): http://mobile.osnews.com/staff/permalink.php/4062/tracking_down_database_corruption_with_psql.html http://mobile.osnews.com/staff/index.php/tag/postgres http://thoughts.j-davis.com/2009/11/29/linux-oom-killer/ http://www.redhat.com/docs//manuals/database/RHDB-7.1.3-Manual/admin_user/kernel-resources.html tienen respaldo de la base? tiene pinta a corrupción de tablas Saludos Andres
Re: Postgresql que se muere
On 13/07/10 02:21, Andres Junge wrote: Hola Tenemos un servidor con Asterisk el cual registra todas las llamadas que pasan por el en un servidor postgresql. Todo andaba bien hasta que derrepente el postgresql dejo de atender algunas consultas. Por ejemplo si le envio: asterisk= SELECT COUNT(*) AS count FROM uso_detalle_anexo WHERE dst = '98263186' AND anexo = '117' AND anyo = '2008' AND mes = '12'; ERROR: invalid memory alloc request size 1818585462 Que podra ser. Por donde buscamos? buscando en google por ERROR: invalid memory alloc request size me dio esto(traducido se entiende mejor): http://mobile.osnews.com/staff/permalink.php/4062/tracking_down_database_corruption_with_psql.html http://mobile.osnews.com/staff/index.php/tag/postgres http://thoughts.j-davis.com/2009/11/29/linux-oom-killer/ http://www.redhat.com/docs//manuals/database/RHDB-7.1.3-Manual/admin_user/kernel-resources.html tienen respaldo de la base? tiene pinta a corrupción de tablas Si no calculo mal, eso es app 1.7G, tiene sentido que malloc() falle.. Saludos Andres -- Eduardo Silva http://edsiper.linuxchile.cl http://www.monkey-project.com
Re: Postgresql que se muere
On 14/07/10 18:29, Eduardo Silva wrote: On 13/07/10 02:21, Andres Junge wrote: Hola Tenemos un servidor con Asterisk el cual registra todas las llamadas que pasan por el en un servidor postgresql. Todo andaba bien hasta que derrepente el postgresql dejo de atender algunas consultas. Por ejemplo si le envio: asterisk= SELECT COUNT(*) AS count FROM uso_detalle_anexo WHERE dst = '98263186' AND anexo = '117' AND anyo = '2008' AND mes = '12'; ERROR: invalid memory alloc request size 1818585462 Que podra ser. Por donde buscamos? buscando en google por ERROR: invalid memory alloc request size me dio esto(traducido se entiende mejor): http://mobile.osnews.com/staff/permalink.php/4062/tracking_down_database_corruption_with_psql.html http://mobile.osnews.com/staff/index.php/tag/postgres http://thoughts.j-davis.com/2009/11/29/linux-oom-killer/ http://www.redhat.com/docs//manuals/database/RHDB-7.1.3-Manual/admin_user/kernel-resources.html tienen respaldo de la base? tiene pinta a corrupción de tablas Si no calculo mal, eso es app 1.7G, tiene sentido que malloc() falle.. revisar tuning de S.O. vs postgresql Saludos Andres
Re: Postgresql que se muere
El 14 de julio de 2010 18:32, Enrique Herrera Noya quique...@gmail.comescribió: On 14/07/10 18:29, Eduardo Silva wrote: On 13/07/10 02:21, Andres Junge wrote: Hola Tenemos un servidor con Asterisk el cual registra todas las llamadas que pasan por el en un servidor postgresql. Todo andaba bien hasta que derrepente el postgresql dejo de atender algunas consultas. Por ejemplo si le envio: asterisk= SELECT COUNT(*) AS count FROM uso_detalle_anexo WHERE dst = '98263186' AND anexo = '117' AND anyo = '2008' AND mes = '12'; ERROR: invalid memory alloc request size 1818585462 Que podra ser. Por donde buscamos? buscando en google por ERROR: invalid memory alloc request size me dio esto(traducido se entiende mejor): http://mobile.osnews.com/staff/permalink.php/4062/tracking_down_database_corruption_with_psql.html http://mobile.osnews.com/staff/index.php/tag/postgres http://thoughts.j-davis.com/2009/11/29/linux-oom-killer/ http://www.redhat.com/docs//manuals/database/RHDB-7.1.3-Manual/admin_user/kernel-resources.html tienen respaldo de la base? tiene pinta a corrupción de tablas Si no calculo mal, eso es app 1.7G, tiene sentido que malloc() falle.. revisar tuning de S.O. vs postgresql Saludos Andres A propos... independiente del problema original, si un SELECT no debiera retornar errores, ¿entonces como la aplicación debiera detectar que hubo un problema en la consulta? Por eso citaba el sistema de excepciones de postgres. Igual se agradecen los textos enviados, cuando tenga un tiempo les daré un repaso, y no faltará quien tenga dudas similares. -- ~~~ Atentamente, Gonzalo Díaz Cruz Estudiante Ingeniería de Ejecución en Computación e Informática Universidad de Santiago de Chile ~~~ http://blog.gon.cl/ http://twitter.com/sir_gon http://flickr.com/photos/sir_gon
Re: Postgresql que se muere
El 14 de julio de 2010 21:25, Ricardo Munoz rmu...@tux.cl escribió: El 14 de julio de 2010 21:01, Gonzalo Diaz m...@gon.cl escribió: [...] A propos... independiente del problema original, si un SELECT no debiera retornar errores, ¿entonces como la aplicación debiera detectar que hubo un problema en la consulta? el punto era que en teoria un SELECT no deberia retornar un error de memoria si el servicio esta corriendo normalmente ya que si el servicio esta arriba es porque tiene la capacidad para servir, en otras palabras, hacer su pega! (podria estar lento pero no caerse) imaginate un bus del Transantiago que se detenga en plena Alameda (entre dos paraderos) solo porque ya no quedan asientos... el bus debe seguir andando hasta el proximo paradero, a menos que haya un desperfecto de hardware (pinchazo, falla en motor, etc.) algo que no podria ser previsto. tampoco el bus debe partir si su conductor considera que no puede llegar hasta el proximo paradero... -- Ricardo Mun~oz A. http://www.tux.cl Entiendo la analogía, pero la considero un poco rara. Desde el punto de vista de como informar la micro va llena al usuario, porque al final el resultado es que no podrá subir, pero si la micro no informa (visualmente en este caso a través de la ventana de la micro) que está llena, el usuario nunca va a saber porque no pudo subir a la micro. Más raro me parecería tener la certeza que mis tablas están llenas de datos y mi SELECT retorne cero tuplas sin informar de un error. Y rayaría en lo esotérico encontrar el error de memoria. -- ~~~ Atentamente, Gonzalo Díaz Cruz Estudiante Ingeniería de Ejecución en Computación e Informática Universidad de Santiago de Chile ~~~ http://blog.gon.cl/ http://twitter.com/sir_gon http://flickr.com/photos/sir_gon
Re: Postgresql que se muere
El mié, 14-07-2010 a las 21:25 -0400, Ricardo Munoz escribió: El 14 de julio de 2010 21:01, Gonzalo Diaz m...@gon.cl escribió: [...] A propos... independiente del problema original, si un SELECT no debiera retornar errores, ¿entonces como la aplicación debiera detectar que hubo un problema en la consulta? el punto era que en teoria un SELECT no deberia retornar un error de memoria si el servicio esta corriendo normalmente ya que si el servicio esta arriba es porque tiene la capacidad para servir, en otras palabras, hacer su pega! (podria estar lento pero no caerse) Sí puede retornar un error por falta de memoria. Basta que la memoria necesaria para resolver ese select no sea suficiente. imaginate un bus del Transantiago que se detenga en plena Alameda (entre dos paraderos) solo porque ya no quedan asientos... el bus debe seguir andando hasta el proximo paradero, a menos que haya un desperfecto de hardware (pinchazo, falla en motor, etc.) algo que no podria ser previsto. tampoco el bus debe partir si su conductor considera que no puede llegar hasta el proximo paradero... Si el bus tiene un problema que no puede resolver por si mismo, no podrá seguir operando y de alguna forma informará a los usuarios, independiente de que un usuario diga pero si yo sólo quiero viajar -- Franco Catrin L. TUXPAN Software http://www.tuxpan.com/fcatrin
Re: Postgresql que se muere
Andres, creo que es tiempo de realizar un tunning a tu servidor (sistema operativo) y tambien a la configuración de postgresql en postgresql.conf según los recursos de hardware que tengas. 2010/7/13 Andres Junge aju...@totexa.cl: Hola Tenemos un servidor con Asterisk el cual registra todas las llamadas que pasan por el en un servidor postgresql. Todo andaba bien hasta que derrepente el postgresql dejo de atender algunas consultas. Por ejemplo si le envio: asterisk= SELECT COUNT(*) AS count FROM uso_detalle_anexo WHERE dst = '98263186' AND anexo = '117' AND anyo = '2008' AND mes = '12'; ERROR: invalid memory alloc request size 1818585462 Que podra ser. Por donde buscamos? Saludos Andres -- Atentamente, Moisés Alberto Lindo Gutarra Asesor - Desarrollador Java / Open Source Linux Registered User #431131 - http://counter.li.org/ Cel: (511) 995081720 MSN: mli...@tumisolutions.com
Re: Postgresql que se muere
2010/7/13 Andres Junge aju...@totexa.cl Hola Tenemos un servidor con Asterisk el cual registra todas las llamadas que pasan por el en un servidor postgresql. Todo andaba bien hasta que derrepente el postgresql dejo de atender algunas consultas. Por ejemplo si le envio: asterisk= SELECT COUNT(*) AS count FROM uso_detalle_anexo WHERE dst = '98263186' AND anexo = '117' AND anyo = '2008' AND mes = '12'; ERROR: invalid memory alloc request size 1818585462 Que podra ser. Por donde buscamos? podria ser un bug de Postgres o datos corruptos... recomiendo enviar un mail, indicando el sistema operativo + version de Postgres, a la lista de correo en http://archives.postgresql.org/pgsql-es-ayuda/ -- Ricardo Mun~oz A. http://www.tux.cl
Re: Postgresql que se muere
Hola Gracias por contestar. Que cosas podria tunear por ejemplo? Saludos Andres El mar, 13-07-2010 a las 12:07 -0500, Moises Alberto Lindo Gutarra escribió: Andres, creo que es tiempo de realizar un tunning a tu servidor (sistema operativo) y tambien a la configuración de postgresql en postgresql.conf según los recursos de hardware que tengas. 2010/7/13 Andres Junge aju...@totexa.cl: Hola Tenemos un servidor con Asterisk el cual registra todas las llamadas que pasan por el en un servidor postgresql. Todo andaba bien hasta que derrepente el postgresql dejo de atender algunas consultas. Por ejemplo si le envio: asterisk= SELECT COUNT(*) AS count FROM uso_detalle_anexo WHERE dst = '98263186' AND anexo = '117' AND anyo = '2008' AND mes = '12'; ERROR: invalid memory alloc request size 1818585462 Que podra ser. Por donde buscamos? Saludos Andres signature.asc Description: Esto es una parte de mensaje firmado digitalmente
Re: Postgresql que se muere
El mar, 13-07-2010 a las 13:20 -0400, Ricardo Munoz escribió: 2010/7/13 Andres Junge aju...@totexa.cl Hola Tenemos un servidor con Asterisk el cual registra todas las llamadas que pasan por el en un servidor postgresql. Todo andaba bien hasta que derrepente el postgresql dejo de atender algunas consultas. Por ejemplo si le envio: asterisk= SELECT COUNT(*) AS count FROM uso_detalle_anexo WHERE dst = '98263186' AND anexo = '117' AND anyo = '2008' AND mes = '12'; ERROR: invalid memory alloc request size 1818585462 Que podra ser. Por donde buscamos? podria ser un bug de Postgres o datos corruptos... recomiendo enviar un mail, indicando el sistema operativo + version de Postgres, a la lista de correo en http://archives.postgresql.org/pgsql-es-ayuda/ Ok. Vere como nos va. Salu2 An3 signature.asc Description: Esto es una parte de mensaje firmado digitalmente
Re: Postgresql que se muere
El Tue, 13-07-2010 a las 14:27 -0400, Andres Junge escribió: Hola Gracias por contestar. Que cosas podria tunear por ejemplo? Parte testeando la memoria de la maquina :) Saludos Andres El mar, 13-07-2010 a las 12:07 -0500, Moises Alberto Lindo Gutarra escribió: Andres, creo que es tiempo de realizar un tunning a tu servidor (sistema operativo) y tambien a la configuración de postgresql en postgresql.conf según los recursos de hardware que tengas. 2010/7/13 Andres Junge aju...@totexa.cl: Hola Tenemos un servidor con Asterisk el cual registra todas las llamadas que pasan por el en un servidor postgresql. Todo andaba bien hasta que derrepente el postgresql dejo de atender algunas consultas. Por ejemplo si le envio: asterisk= SELECT COUNT(*) AS count FROM uso_detalle_anexo WHERE dst = '98263186' AND anexo = '117' AND anyo = '2008' AND mes = '12'; ERROR: invalid memory alloc request size 1818585462 Que podra ser. Por donde buscamos? Saludos Andres -- Marcelo Espinosa Alliende Jefe Depto de Servicios Computacionales Dirección de Informática Universidad del Bío-Bio fono: +56 41 2731531, http://marcelo.ubb.cl
Re: Postgresql que se muere
2010/7/13 Marcelo Espinosa Alliende marc...@ubiobio.cl El Tue, 13-07-2010 a las 14:27 -0400, Andres Junge escribió: Hola Gracias por contestar. Que cosas podria tunear por ejemplo? Parte testeando la memoria de la maquina :) Habia un truquito usando el valor de maintenance_work_mem y work_mem. Prueba moviendo esos valores. Saludos! (nota : mi cuenta de correo is alive :D ) -- Juan C. Inostroza j...@codemonkey.cl
Re: Postgresql que se muere
2010/7/13 Andres Junge aju...@totexa.cl: Hola Tenemos un servidor con Asterisk el cual registra todas las llamadas que pasan por el en un servidor postgresql. Todo andaba bien hasta que derrepente el postgresql dejo de atender algunas consultas. Por ejemplo si le envio: asterisk= SELECT COUNT(*) AS count FROM uso_detalle_anexo WHERE dst = '98263186' AND anexo = '117' AND anyo = '2008' AND mes = '12'; ERROR: invalid memory alloc request size 1818585462 Que podra ser. Por donde buscamos? Saludos Andres Es un servidor dedicado solo al motor de datos?, es Asterisk lo tienes en realtime..? Pero como ya te han mencionado vería algún tunning revisando cuantas consultas tienes concurrentes... el espacio en disco, memoria, cpu, y versión de tu PostgreSQL. -- Rodrigo Ramírez Norambuena http://decipher.blackhole.cl
Re: Postgresql que se muere
On Jul 13, 2010, at 3:24 PM, Rodrigo Ramirez Norambuena wrote: 2010/7/13 Andres Junge aju...@totexa.cl: Tenemos un servidor con Asterisk el cual registra todas las llamadas que pasan por el en un servidor postgresql. Todo andaba bien hasta que derrepente el postgresql dejo de atender algunas consultas. Por ejemplo si le envio: asterisk= SELECT COUNT(*) AS count FROM uso_detalle_anexo WHERE dst = '98263186' AND anexo = '117' AND anyo = '2008' AND mes = '12'; ERROR: invalid memory alloc request size 1818585462 Que podra ser. Por donde buscamos? Es un servidor dedicado solo al motor de datos?, es Asterisk lo tienes en realtime..? Pero como ya te han mencionado vería algún tunning revisando cuantas consultas tienes concurrentes... el espacio en disco, memoria, cpu, y versión de tu PostgreSQL. El error no parece ser problema de mala configuración... es posible que lo arregles cambiando la configuración, pero en realidad estas ocultando un bug que te puedes topar en otro lado. Yo veo dos posibilidades: error de hardware o error de postgresql. Para la primera, corre memtest86 y revisa errores de disco con smartctl. Para la segunda, habría que preguntar en las listas/bugtracking de postgresql; buscando en google hay un bug relacionado... Lo otro seria copiar la base de datos y montarla en una versión mas nueva de postgresql, a ver como te va. Aldrin Martoq http://aldrin.martoq.cl/
Re: Postgresql que se muere
El Tue, 13 Jul 2010 02:21:00 -0400 Andres Junge aju...@totexa.cl escribió: Hola Tenemos un servidor con Asterisk el cual registra todas las llamadas que pasan por el en un servidor postgresql. Todo andaba bien hasta que derrepente el postgresql dejo de atender algunas consultas. Por ejemplo si le envio: asterisk= SELECT COUNT(*) AS count FROM uso_detalle_anexo WHERE dst = '98263186' AND anexo = '117' AND anyo = '2008' AND mes = '12'; ERROR: invalid memory alloc request size 1818585462 Que podra ser. Por donde buscamos? Me imagino que habrás mirado, pero si la versión es un poco vieja, puede que esté afectada por [1]este problema. Saludos --- Angel [1]http://archives.postgresql.org/pgsql-bugs/2006-03/msg00193.php
Re: Postgresql que se muere
El 13 de julio de 2010 16:24, AngelD ang...@froga.net escribió: El Tue, 13 Jul 2010 02:21:00 -0400 Andres Junge aju...@totexa.cl escribió: Hola Tenemos un servidor con Asterisk el cual registra todas las llamadas que pasan por el en un servidor postgresql. Todo andaba bien hasta que derrepente el postgresql dejo de atender algunas consultas. Por ejemplo si le envio: asterisk= SELECT COUNT(*) AS count FROM uso_detalle_anexo WHERE dst = '98263186' AND anexo = '117' AND anyo = '2008' AND mes = '12'; ERROR: invalid memory alloc request size 1818585462 Que podra ser. Por donde buscamos? Me imagino que habrás mirado, pero si la versión es un poco vieja, puede que esté afectada por [1]este problema. Saludos --- Angel [1]http://archives.postgresql.org/pgsql-bugs/2006-03/msg00193.php da para pensar como tanta gente hizo la pega (buscar en Google) del autor del primer mail y/o respondieron a la rapida y mal. cualquier usuario de un motor de base de datos debe saber que - el resultado de un SELECT nunca puede ser un mensaje de error de memoria - el resultado de un servicio mal optimizado nunca puede ser un mensaje de error de memoria durante su operacion (instruccion SELECT), sino solo al momento de subir el servicio por lo tanto, la unica explicacion logica al problema es que - se trata de un bug de Postgres, donde la solucion es actualizar ojala usando el metodo ofrecido por la distro de Linux - se trata de un error de hardware (memoria o disco), donde la solucion es reemplazar el hardware malo o cambiar el servicio a otra maquina -- Ricardo Mun~oz A. http://www.tux.cl
Re: Postgresql que se muere
Hola! 2010/7/13 Ricardo Munoz rmu...@tux.cl da para pensar como tanta gente hizo la pega (buscar en Google) del autor del primer mail y/o respondieron a la rapida y mal. cualquier usuario de un motor de base de datos debe saber que ... - el resultado de un SELECT nunca puede ser un mensaje de error de memoria - el resultado de un servicio mal optimizado nunca puede ser un mensaje de error de memoria durante su operacion (instruccion SELECT), sino solo al momento de subir el servicio por lo tanto, la unica explicacion logica al problema es que - se trata de un bug de Postgres, donde la solucion es actualizar ojala usando el metodo ofrecido por la distro de Linux No necesariamente. Hay algunos problemillas que he pillado ultimamente en MySQL que a veces tiran a hacer consumo excesivo de memoria (como algunos subselects). Y tecnicamente, se arreglan haciendo algunos ajustes al mismo query. - se trata de un error de hardware (memoria o disco), donde la solucion es reemplazar el hardware malo o cambiar el servicio a otra maquina Me gustaria ver los valores de los parametros que mande antes. Quizas podrian decir, o bien que es el mismo bug (un rapido googleo) o bien que la tabla ni siquiera esta optimizada. Saludos! -- Juan C. Inostroza j...@codemonkey.cl
Re: Postgresql que se muere
El mar, 13-07-2010 a las 17:28 -0400, Ricardo Munoz escribió: [...] hmm... insisto que ningun motor de base de datos decente deberia retornar un mensaje de error de memoria como resultado de un SELECT Por qué no? A mi me parece razonable que el motor tire un error de falta de memoria... cuando le falta memoria para procesar el select. -- Franco Catrin L. http://www.tuxpan.com/fcatrin TUXPAN Software S.A.
Re: Postgresql que se muere
El 13 de julio de 2010 17:46, Franco Catrin L. fcat...@tuxpan.comescribió: El mar, 13-07-2010 a las 17:28 -0400, Ricardo Munoz escribió: [...] hmm... insisto que ningun motor de base de datos decente deberia retornar un mensaje de error de memoria como resultado de un SELECT Por qué no? A mi me parece razonable que el motor tire un error de falta de memoria... cuando le falta memoria para procesar el select. eso quiere decir que tendrias que poner mas memoria a tu servidor por cada n-cantidad de nuevos registros que le agregas a la base de datos? eso no tiene sentido... y fijate que el error se produjo con un simple SELECT COUNT()... -- Ricardo Mun~oz A. http://www.tux.cl
Re: Postgresql que se muere
Hola! 2010/7/13 Ricardo Munoz rmu...@tux.cl eso quiere decir que tendrias que poner mas memoria a tu servidor por cada n-cantidad de nuevos registros que le agregas a la base de datos? eso no tiene sentido... y fijate que el error se produjo con un simple SELECT COUNT()... Como dije, puede sonar muy inocente la query. Pero no siempre puede ser problema de memoria. 1.- Concuerdo contigo que puede ser un bug de la aplicacion. Pero... 2.- Hay parametros para ajustar los valores de trabajo cuando se ejecuta un query. Tambien... 3.- El mismo kernel instruyendo al proceso que deje de comer cpu/memoria/wharenes. Tambien se le puede echar la culpa al host :-) Tengo por ahi una query hecha sobre 4000*230 registros en MySQL que la deja pensando por un buen rato y en algunas maquinas es capaz de irse de ozzy. Curiosamente, la misma query en una version anterior, anda como avion... Saludos! -- Juan C. Inostroza j...@codemonkey.cl
Re: Postgresql que se muere
On Tue, 2010-07-13 at 16:51 -0400, Ricardo Munoz wrote: From: Ricardo Munoz rmu...@tux.cl Reply-to: Discusion de Linux en Castellano linux@listas.inf.utfsm.cl To: Discusion de Linux en Castellano linux@listas.inf.utfsm.cl Subject: Re: Postgresql que se muere Date: 13/07/2010 13:51 El 13 de julio de 2010 16:24, AngelD ang...@froga.net escribió: El Tue, 13 Jul 2010 02:21:00 -0400 Andres Junge aju...@totexa.cl escribió: Hola Tenemos un servidor con Asterisk el cual registra todas las llamadas que pasan por el en un servidor postgresql. Todo andaba bien hasta que derrepente el postgresql dejo de atender algunas consultas. Por ejemplo si le envio: asterisk= SELECT COUNT(*) AS count FROM uso_detalle_anexo WHERE dst = '98263186' AND anexo = '117' AND anyo = '2008' AND mes = '12'; ERROR: invalid memory alloc request size 1818585462 Que podra ser. Por donde buscamos? Me imagino que habrás mirado, pero si la versión es un poco vieja, puede que esté afectada por [1]este problema. Saludos --- Angel [1]http://archives.postgresql.org/pgsql-bugs/2006-03/msg00193.php da para pensar como tanta gente hizo la pega (buscar en Google) del autor del primer mail y/o respondieron a la rapida y mal. cualquier usuario de un motor de base de datos debe saber que - el resultado de un SELECT nunca puede ser un mensaje de error de memoria - el resultado de un servicio mal optimizado nunca puede ser un mensaje de error de memoria durante su operacion (instruccion SELECT), sino solo al momento de subir el servicio por lo tanto, la unica explicacion logica al problema es que - se trata de un bug de Postgres, donde la solucion es actualizar ojala usando el metodo ofrecido por la distro de Linux - se trata de un error de hardware (memoria o disco), donde la solucion es reemplazar el hardware malo o cambiar el servicio a otra maquina El que sea problema de memoria no pasa necesariamente por una falla en el hardware. Por ejemplo, es posible que le hayan dicho a Postgres que dispone más memoria para algunas tareas de las que realmente tiene. Si antes no dio problemas, puede ser porque nunca tuvo que pasar el umbral. Una alternativa es levantar un servidor Postgresql en otra máquina y realizar las pruebas. Si el problema persiste, entonces se puede descartar el hardware (aunque podría ser que la mala cueva este persiguiendo a Andrés y dicho hw también esté malo ;-) -- Germán Póo-Caamaño http://www.calcifer.org/
Re: Postgresql que se muere
Excerpts from Andres Junge's message of mar jul 13 02:21:00 -0400 2010: Hola Tenemos un servidor con Asterisk el cual registra todas las llamadas que pasan por el en un servidor postgresql. Todo andaba bien hasta que derrepente el postgresql dejo de atender algunas consultas. Por ejemplo si le envio: asterisk= SELECT COUNT(*) AS count FROM uso_detalle_anexo WHERE dst = '98263186' AND anexo = '117' AND anyo = '2008' AND mes = '12'; ERROR: invalid memory alloc request size 1818585462 Parece un error típico de un puntero TOAST corrupto. Tengo un trozo de código que escribí para encontrar estos datos; lo voy a publicar para que puedas encontrar donde está el dato corrupto y puedas eliminarlo.
