El 12 de octubre de 2014, 22:22, Emanuel Calvo<[email protected] > escribió:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > > > El 11/10/14 a las 14:27, Eduardo Arenas C. escibió: > > Jaime, > > > > Esto entrego el pg_xlogfile = "0000000100000C5B000000F3" > > > > luego de 30 min "0000000100000C5B000000F3" , ahora está full > > carga de datos. > > > > No es una base muy activa, es un sistema de BI que refresca datos > > durante la noche (aprox 20GB , aprox 50 Millones de registros) , y > > el fin de semana hace un refresco completo de aprox 100GB. > > En ese caso, creo que deberías cambiar la táctica de configuración. > Más que nada para poder mejorar los tiempos de inserción sacrificando > algo de durabilidad. Esto es, si la pérdida de datos en esta instancia > no representa peligro (es decir, que no la lies). También si los > tiempos de recuperación son buenos. > ¿a que te refieres con eso? como se hace??? > > > > > Durante el día no mas de una decena de personas lo consultas sql > > directo y tenemos algunos reportes y cubos en pentaho BI que se > > consulta en el portal web de pentaho. > > Ahora que comentas esto, quizás el principal problema es que > seguramente esa carga de datos masiva nocturna puede estar > "colisionando"con algún reporte o cron que hace consultas u otro > trabajo en la base. > > En el caso que así fuera, deberías corroborar de que la carga de datos > esté libre de uso de recursos pr parte de otros procesos. > > El separar la pg_Xlog en este particular caso no beneficiaría las > consultas normales de los reportes :) > Dos cosas, si probablemente hay colisiones, pero no con consultas, mas bien de cargas simultaneas, como estoy haciendo cargas con Pentaho Data Integration (ex kettle ETL), y estas se hacen por JDBC, sin un poco lentas lo que me obliga a tirar varias cosas al mismo tiempo, esto lo hago en forma nocturna, y como esto termina antes de que empiece la operación no hay problema, pero estoy pensando en una carga mas eficiencia secuencial por medio de un COPY o un fdw no se si fdw pueda ser mas rapido que el JDBC de kettle. Lo otro, esto está en una virtualización y la unidad de disco del equipo, finalmente es un LUN de un storage, las particiones son volúmenes lógicos (VL)... dado que comentas que no sería productivo separar el pg_xlog con esto de los volúmenes lógicos, imagino que será mucho menos performante :( > > - -- > - -- > Emanuel Calvo http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services > Bs. As., Argentina (GMT-3) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBCgAGBQJUOzd+AAoJEIBeI/HMagHmD+gQAKFkQIbbDSqTk8XAtBJBKKxY > IWDdW4fQaaSd9V8W6SetYdlUJ5wYoDaKId1CKsVTS6Mw8CMiaLNHWdsdxqgcse/3 > UWHSXMktro9erRmYQzwhGMMJrScrfQlhniAuOCJ6ZQ0gY5S5rrOeT6imZZUZFsyM > TbwYZj194E0yF7IFUHY28/EtgD3h4suCdoZQRwPpf5+moVClc/k5Otrfb5zwVxel > x95aD74pxbJ1SBGxDEn2EX5gVsixizWZgfDnbzLuwF6/XhklTJDMlpHi0zmi/vc+ > mrtqtC8rjOh6nsLN/TzZkywHrATdGMpTi4WQISHgDK+SJXyKfoqddeUnceMrHEJY > B3e0FWwJUfXSJsPLYjBLisFOftvIyqSSoDhSK6HJbyp1/e4jwutQxOjdoDkRbO0n > 6X4wJps7j/McikxdPACFWeeVRGKylm/kDGP9gMaSeknO23djIy9tNWstUC3NvvwM > z1FTWNnUyX2zfUsIwzUR/ChYiFUz419MXmsntXkntTvY6EnzS8XoUXogqp9ys+VF > ZXlPO/PWJAHpAFqggoii9yKhCFSq6qt68kAP4mjWTtIMn9W1hKRjD/oY83tJc58A > tdH1H7SjK5kBKkPdelkNA3D5P795xXeayKfQYZGeTJjPSvlZPX4TNSqm+xZnTfLB > xPlpCplvxht2cH+hukY2 > =o4zA > -----END PGP SIGNATURE----- > -- Eduardo Arenas C. Jefe de Unidad de Gestión de Información Ancora UC +56 0 9 6629 1618 +56 0 22 944 9098
