Foro - Perl en Español

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.

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?