Foro - Perl en Español

Saludos a la comunidad...

Quiero que me den su opinión a un proyecto que tengo para que me digan si es factible en cuando a rendimiento...

ACTUALMENTE
se tiene un servidor (servidor1) donde está instalada una base de datos Oracle 10g y en la misma máquina están los procesos hechos en Perl que, a través de un crontab, rescatan datos desde otras maquinas, y las insertan dentro de la BD. A la vez tenemos el servidor web que muestra reportes online de cada 5 minutos; las consultas de los reportes están hechas en PHP. La BD y los procesos Perl hacen subir considerablemente la carga del servidor, y no hablar si algún cliente quiere rescatar una data histórica de miles de datos. Entonces esto nos ha traído problemas, ya que los datafiles de la BD están en la raíz del SO que es un Red Hat 5.5. Entonces, los dos compiten por los recursos del servidor, que éste no deja de ser malo: es un blade de 16 núcleos y 8 Gb de RAM. Además de eso tenemos otro servidor (servidor2) con otros procesos Perl que hace como lo mismo de lo que ya expliqué, solo que los reportes y las consultas las realizamos desde el servidor1 donde está instalado el Apache con PHP, pero esta vez cada 10 minutos. Entonces, debido a problemas que hemos tenido, se nos entregó otro servidor blade con 16 núcleos y 64 Gb de RAM y he pensado en esta solución.

FUTURO PRÓXIMO
Instalar en el nuevo servidor el SO Red Hat compatible con Oracle 11g y en la base de datos crear dos esquemas para las dos bases de datos que tenemos por separado, o sea, juntar las dos bases de datos en una.

Y en el servidor que tenemos actualmente (servidor1) COLOCAR TODOS LOS PROCESOS PERL DE AMBOS SERVIDORES para que trabaje en la extracción de los datos y los envíe a la BD de servidor nuevo y haga lo que tiene que hacer en ambos esquemas, además tener una BD instalada con un resumen de 2 días. Esto es si se nos cae el servidor nuevo, y así tener reportes en línea mientras se levanta el nuevo...

PREGUNTA
Bueno mi pregunta es, ¿como creen Uds. que trabajarían los procesos Perl todos juntos en un servidor aparte, o sea, tener como un servidor de procesos, para que haga el trabajo y ocupe recursos de ese servidor y así el servidor donde está la BD solo se preocupe de entregar recursos para el motor de la BD...?

Espero que me den su opinión a esta iniciativa, nunca he trabajado en un servidor de procesos, pero por lo que me he documentado, suena interesante...

¡Ah!, por si alguien se pregunta, la BD del servidor1 tiene 650 millones de datos (280GB) y la segunda 150 millones (60GB)...

Estaré atento a sus sugerencias...

Luis

De toda esa configuración, lo peor es el sistema operativo.

Usar Red Hat significa estabilidad (y soporte comercial), pero también significa tener que usar software muy viejo (a veces, de muchos años). Y el software viejo, a veces, tiene problemas.

Esto quedó patente hace años cuando se descubrió que Red Hat traía una versión de Perl con un sistema de gestión de memoria desastroso, que provocaba que los programas Perl fueran docenas de veces más lentos que si hubiéramos usado otra versión de Perl.

También tengo mis reticencias con Oracle. No dudo de que sea capaz de servir miles de peticiones por segundo a miles de clientes, y que sus sistemas de replicación den una buena seguridad, pero en la mayor parte de las ocasiones, otros motores de bases de datos dan mejores prestaciones, se tarda cincuenta veces menos tiempo en instalarlas, y cuestan menos de 10€.

Yo, lo primero que haría, sería compilar mi propia versión de Perl v5.14.2 sobre esas máquinas, y no usar el que viene por defecto. Las mejoras de velocidad en las expresiones regulares a partir de la v5.10, y del rendimiento en general, en las versión v5.12 y v5.14, son una gran diferencia con respecto a Perl v5.8.8.

Dices que las máquinas se saturan con los procesos Perl, y que compiten con la base de datos por el control de la CPU. Eso se puede resolver muy sencillamente con solo cambiar la prioridad de los procesos. Yo suelo decidir, en las máquinas que están justas de recursos, qué procesos son los más importantes, y darles más prioridad.

Naturalmente, si sabemos dónde está el cuello de botella, hay que estudiar si podemos hacerlo más grande. Si el problema son los procesos Perl, quizás haya que estudiarlos para encontrar una solución mejor.

En cuanto a la pregunta... Nosotros tenemos un servidor con 16 núcleos y 4Gb de memoria RAM, donde trabajan unas 200 personas de forma simultánea, leyendo y escribiendo correo electrónico, junto con un centenar de sitios web, y medio centenar de bases de datos, de tamaños muy distintos. Y la carga de la máquina, a lo largo del día, dificilmente supera el nivel 1 (de hecho, si lo hace, empezaríamos a preocuparnos).

Las máquinas que describes son muy grandes, pero no nos dices nada del número de procesos, peticiones por segundo, tiempo medio de resolución de una petición... Con la calculadora en la mano, se podría saber si están bien ajustadas o no (en teoría, que la práctica es luego otra cosa).

Quizás el parámetro de tiempo de resolución de una petición o el tiempo que tarda un proceso Perl en ejecutarse, son los más importantes. Pero si mueves todos los procesos Perl a una máquina, quizás estás desplazando el cuello de botella de los procesadores de una máquina, al sistema de red de todo el sistema, pues los procesos Perl necesitan escribir en la base de datos de otra máquina.

explorer... Muchas gracias por responder. Sobre el tema del Red Hat tienes toda la razón, tenemos la versión 5.8.8 de Perl y acabo de leer un articulo tuyo sobre "Descubierto fallo grave en el Perl de Red Hat y derivados" y quedé perplejo.

Sobre lo que me faltó por colocar el número de procesos por máquina, son 30, de los cuales 15 se demoran entre 1 a 3 minutos en ejecutarse, estos son online cada 5 minutos, pero ocupan mucha carga, es ahí donde se pierden reportes ya que a veces los procesos no alcanzan a terminar antes de los 5 minutos. Y los otros se moran entre 30 a 100 minutos y son diarios, estos nos colocamos a trabajar a horas donde no hay tanta demanda.

Y me gustaría saber si está bien que juntemos los procesos Perl de las dos máquinas en una, más la BD con 2 esquemas.

Lo de Red Had a mi tampoco me gusta mucho, ni Oracle por el tema de $$$$, pero la TI no soporta las máquinas si no tienen soporte comercial...

Saludos

Yo no veo que eso sea mucha carga... 30 procesos, aunque tarden mucho, son pocos procesos. En una máquina con cuatro núcleos puede haber más de 900 procesos, de los cuales unos 20 pueden estar necesitando procesador.

Me temo entonces que el tema está en saber qué es lo que hacen esos procesos que consumen tanto tiempo. El problema está en los procesos que no terminan antes de los cinco minutos. A priori, todo lo que sea dividir trabajo entre máquinas, es bueno (siempre y cuando TI se pueda permitir pagar las nuevas máquinas).

Conocí un caso parecido: una empresa de telecomunicaciones generaba una ingente cantidad de registros de actividad, tanto de Internet como de telefonía móvil. Y había que sacar estadísticas cada X minutos.

Hay varias soluciones. Una de ellas es la de no procesar todo el fichero de golpe cada 5 minutos, si no procesarlo cada menos tiempo. Y repartir el trabajo entre varios procesos, ya que contamos con varios núcleos. Por ejemplo, si tenemos que procesar 30 segundos, generamos 30 procesos y que cada uno se ocupe de sacar las estadísticas de un solo segundo.

Aún así, por muchas estrategias que se nos ocurran, el hardware siempre impondrá su límite, momento en el cual necesitaremos otra máquina para repartir el trabajo.

En cuanto al soporte comercial, si el departamento TI quiere soporte comercial, es porque no confía en sus informáticos, o porque ha contratado a gente no tan preparada como le gustaría (y por lo tanto, tampoco confía en ellos), o porque sabe que sus informáticos no durarán en la empresa más de un año (y por lo tanto, no confía en sus soluciones que, quizás, el siguiente informático, tire para atrás).

Supongamos que algo se tuerce. Haremos una llamada a Oracle o Red Hat. Primera respuesta: «reinicien el sistema operativo». Segunda respuesta: «si son usuarios premium, iremos allí a ver qué pasa, y como mucho, instalaremos una nueva versión de los programas, si acaso con algún parche de algún fallo recién descubierto, pero ni por asomo vamos a compilar una versión específica para ustedes (salvo que sean clientes de primer nivel, como la NASA o el ejército). Mientras tanto, les aconsejamos que visiten nuestra web para mantener sus sistemas actualizados».

La realidad es que muchas empresas dependen del soporte de la comunidad, y muchas más veces, ese soporte es incluso mejor que el comercial.

¿Cuánto vale mi soporte?

y es la pura y santa verdad, y de verdad te agradezco tu tiempo y el tiempo que le das a todos en esta comunidad...

Analizaré más profundamente el tema. Sí que me distes varias aristas a seguir, así que te agradezco por tu tiempo, de verdad...

Un saludo a la comunidad.

Y doy por cerrado el tema.

Saludos, explorer

PD: cuando termine este proyecto daré mi experiencia...