Cómo limitar el efecto de las modificaciones de los clientes a los sistemas de producción

Question

Nuestra tienda ha desarrollado una solución pocos WEB / SMS / DB para una docena instalaciones del cliente. Las aplicaciones tienen algunos requisitos de rendimiento en tiempo real, y son sólo lo suficientemente bueno para que funcione correctamente. El problema es que los clientes (propietarios de los servidores de producción) están utilizando el mismo servidor / base de datos para las personalizaciones que están causando problemas con el rendimiento de las aplicaciones que hemos creado y desplegado.

Algunos ejemplos de personalizaciones de los clientes:

• Añadir tablas grandes con muchos tipos de datos de texto para las columnas que quedan emitidos para otros tipos de datos en las consultas
• No hay claves principales, índices, restricciones o FK
• El uso de scripts externos que utilizan count(*) from table where id = x, en un bucle desde el guión, para determinar cómo construir consultas más adelante en el mismo guión. (No hay acciones masivas que el planificador puede optimizar o simplemente hacer todo en un solo paso)
• Se crean nuevos Todos los archivos de código en el servidor / propiedad de raíz, con permisos 0777

Los clientes no se llevan bien sugerencias / críticas. Si nos limitamos a seguir adelante y tratar al puerto / cambiar los guiones de nosotros mismos, el viejo código puede volver, clobbering cualquier cambio que hagamos! O con conocimiento limitado fuera de sus casos de uso, partimos funcionalidad al tratar de optimizar sus cambios.

Mi pregunta es la siguiente: ¿cómo podemos limitar los recursos para consultas / solicitudes otra que lo que crear e implementar? ¿Hay alguna opción pragmáticos en escenarios como éste? Nos enorgullecido de tener una solución OSS, pero parece que se ha convertido en un pasivo.

Utilizamos PG 8.3 que se ejecuta en un rango en Linux Distos. Los clientes prefieren php, pero los scripts de shell, Perl, Python, y plpgsql todos se utilizan en el sistema de una forma u otra.

Answer 1

Este problema comenzó aproximadamente dos minutos después de que el primer cliente se le dio acceso completo al primer equipo, y que no ha desaparecido desde entonces. Cada vez que alguien cuyas prioridades están consiguiendo trabajo orientado a los negocios hacer rápidamente van a ser descuidados en ello y arruinar las cosas para todos. Así es como funcionan las cosas, porque el diseño y la correcta aplicación son más duros que los cortes baratos. Usted no va a resolver este problema, lo único que puede hacer es encontrar la manera de hacer más fácil para el cliente para trabajar con ustedes de en su contra. Si lo haces bien, que se verá como un excelente servicio en lugar de regañar.

En primer lugar, el lado de la base de datos. Ahora hay manera de controlar los recursos de consulta en PostgreSQL. La principal dificultad es que las herramientas como "agradable" controlar el uso de la CPU, pero si la base de datos no cabe en la memoria RAM que puede muy bien ser I / O el uso que le está matando. Ver este mensaje de desarrollador que resume las cuestiones aquí

Ahora bien, si de hecho es la CPU los clientes están quemando a través, se pueden utilizar dos técnicas para mejorar esa situación:

• Instalar una función C que cambia la prioridad del proceso ( ejemplo 1 , ejemplo 2 ) y asegúrese de que cada vez que se ejecutan algo que se llama primero ( tal vez sea puesto en su archivo de configuración psql, hay otras maneras).
• Escribir un script que busca procesos del administrador de correo generados por su ID de usuario y renice ellos, lo hacen a menudo corren en cron o como un demonio.

Parece que su problema no son los procesos de consulta en particular que publican, sino más bien otras modificaciones que están haciendo a la estructura más grande. Sólo hay una manera de hacer frente a eso: hay que tratar al cliente como si fueran un intruso y el uso de los enfoques de esa parte del campo de la seguridad informática para detectar cuando enredar las cosas. ¡Seriamente! Instalar un sistema de detección de intrusos como Tripwire en el servidor (hay mejores herramientas, eso es sólo el ejemplo clásico), y hacer que le avise cuando tocan nada. Nuevo archivo que es 0777? Debe saltar a la derecha de un informe adecuado IDS.

En el lado de la base de datos, no se puede detectar directamente la base de datos está modificando de manera útil. Usted debe hacer un pg_dump del esquema de todos los días en un archivo ( pg_dumpall -g y pg_dump -s , entonces diff que contra el último que se suministre y otra vez que le avise cuando que ha cambiado. Si logra que esta bien, el contacto con el cliente se convierte en "nos dimos cuenta de que ha cambiado en el servidor ... ¿qué es lo que estamos tratando de lograr con eso?", que te hace ver como si estuvieras realmente prestar atención a ellos. Eso puede convertirse en una oportunidad de venta, y pueden dejar de tocar el violín con cosas como mucho el hecho de saber que vas a coger inmediatamente.

La otra cosa que debe empezar a hacer de inmediato es instalar tanto el software de control de versiones como sea posible en cada caja cliente. Usted debe ser capaz de iniciar sesión en cada sistema, ejecute la herramienta de estado / diff apropiado para la instalación, y ver lo que ha cambiado. Consigue que la enviada por correo regular también. Una vez más, esto funciona mejor si se combina con algo que vuelca el esquema como un componente para lo que gestiona. No hay suficientes personas utilizan enfoques serios de control de versiones en el código que vive en la base de datos.

Ese es el principal conjunto de enfoques técnicos útiles aquí. El resto de lo que tienes es un problema de gestión de clientes de consultoría clásico que es mucho más de un problema de la gente que una sola computadora. Anímate, que podría ser peor - FSM que ayuda si se les da acceso ODBC y XXey descubren que pueden escribir sus propias consultas en Access o algo tan simple como eso.