Blog

Gestión multiprocesador en Velneo II

Este artículo es el segundo de una serie de dos, en los que se aborda de manera muy básica, los conceptos de ejecución multihilo y multiprocesador, así como sus implicaciones en la programación en general, y en el rendimiento de las aplicaciones desarrolladas con tecnología Velneo en particular.

En esta segunda parte se comenta en qué consiste la ejecución multihilo, las problemáticas derivadas de la este tipo de programación, y como influye en la tecnología Velneo, así como diversas técnicas de optimización en Velneo del rendimiento para casos concretos.

Todo lo dicho hasta ahora nos permite asegurar que es claramente ventajoso tener un sistema multiprocesador en vez de uno monoprocesador, de hecho un sistema equipado con procesador «dual core» o con procesador con hyperthreading (en menor medida) también tendrán un mayor rendimiento que un sistema monoprocesador clásico. Pero, ¿qué tiene esto que ver con el rendimiento del servidor de aplicaciones de Velneo en una máquina con múltiples procesadores? La ejecución simultánea de varios hilos de un mismo proceso es tratada por el sistema operativo según el mismo esquema de multitarea: cada hilo es tratado como un proceso por el scheduler del sistema; en este caso la multitarea no sólo proporciona un aumento del rendimiento del sistema en general, sino también del proceso multihilo en concreto. Dicho esto la pregunta que surge inmediatamente es la siguiente: ¿por qué no son todas las aplicaciones multihilo? Hay varias razones por lo que esto no es siempre viable o recomendable:

Los hilos, a diferencia de los procesos, comparten entre ellos todos los datos que se deben acceder en memoria, puesto que se ejecutan en el mismo espacio. Esto tiene dos implicaciones importantes:

Desaparecen los mecanismos de protección que el propio sistema aplica entre procesos para evitar accesos indebidos a datos.

La coherencia de datos puede verse comprometida ante fallos en el sistema que alteren la secuencia normal de ejecución de los hilos.

Un proceso monohilo es automáticamente identificable por el sistema operativo como tal, y el scheduler asigna recursos de CPU al bloque entero del proceso/hilo; en un proceso que se desea que sea tratado por el scheduler en modo multihilo (de manera que varias tareas de ese mismo proceso puedan ser ejecutadas simultáneamente aumentando así el rendimiento) cada hilo necesita ser identificado mediante programación específica; el sistema operativo no es capaz de reconocer un hilo dentro de un proceso, ya que en parte su definición depende de la estructura y funcionalidad con que los programadores han dotado al proceso global.

La programación de hilos es compleja y requiere múltiples controles de sincronización (como el uso intensivo de mútex por ejemplo) que merman, en parte, las mejoras de rendimiento que se pueden obtener de la ejecución multihilo.

La consecuencia de todo esto es que se debe ser muy cuidadoso a la hora de implementar la programación multihilo y sobre todo de seleccionar dónde y cómo implementarla. La tecnología Velneo implementa programación multihilo, directa o indirectamente, en buena parte de su código. Como en la mayor parte de las aplicaciones, en Velneo aparentemente hay un único proceso (VMotor.exe) en ejecución, y por lo tanto este se ejecuta en un único procesador del sistema, pero hay numerosos hilos derivados de él brindando diversas funcionalidades directamente o a través de dlls de sistema (las cuales son multihilo a su vez). Sin embargo, y dada la problemática comentada antes relativa a la coherencia de datos en la gestión de múltiples hilos de un mismo proceso, hay ciertas partes del servidor de aplicaciones de Velneo que no se ejecutan en modo multihilo. El caso más evidente, y el que mayor impacto tiene sobre el rendimiento del motor, es el módulo denominado gestor de accesos a disco (no confundir con el servidor de disco), e indirectamente el gestor de transacciones (en la medida en que depende del anterior). Aunque hay múltiples operaciones en tecnología Velneo que pasan por el gestor de accesos a disco, son sólo unas pocas, de entre las que además también pasan por el gestor de transacciones, las que pueden llegar a provocar situaciones aparentemente inexplicables como las comentadas inicialmente.

Entre las operaciones que provocan este tipo de comportamientos, y a las que por lo tanto se les debe prestar especial atención al usarlas, cabe destacar las siguientes:

  • Tubos de lista de importación, exportación, e internos en tercer plano (ver nota al respecto publicada por Velneo: http://forum.velneo.com/es/viewtopic.php?t=11128).
  • Las actualizaciones a hermano contiguo.
  • Las funcionas remotas que transaccionan, especialmente las ejecutadas contra el mismo servidor (ver nota al respecto publicada por Velneo: http://forum.velneo.com/es/viewtopic.php?t=11088).
  • Importación y exportación de objetos del contenedor (texto, dibujo, binario, correo).
  • Las tareas programadas y demonios, ya que tienen mayor prioridad que el resto de procesos.
  • Deshacer transacciones.
  • Tareas de mantenimiento: regeneración de índices, copias de seguridad…

Como ya se ha dicho el comportamiento «no multihilo» del servidor de aplicaciones Velneo en este tipo de operaciones, es una condición de diseño tendente a la protección de la coherencia de los datos gestionados por Velneo; evidentemente se está trabajando constantemente en la mejora del rendimiento del servidor de aplicaciones Velneo, y este es uno de los puntos principales bajo análisis constante. Sin embargo existen una serie de medidas que los programadores que usan tecnología Velneo pueden tener en cuenta para mermar estos efectos adversos sobre el rendimiento. A continuación se comentan algunas:

  • Tener especial cuidado con el uso de las funciones remotas; deben ser cortas y efectuar un número reducido de operaciones; es mejor tener varias funciones remotas de pocas operaciones que una que haga muchas. Aconsejablemos revisar el Manual de optimización Cliente/Servidor.
  • Las transacciones con muchas operaciones, y que se preveé que puedan llegar a durar más de 5 minutos, o aquellas que implican actualizaciones a hermanos contiguos, deben segmentarse en transacciones más reducidas, de manera para que liberen al gestor de transacciones para dar entrada a otras que están en cola.

7 thoughts on “Gestión multiprocesador en Velneo II

  1. BTW, sería bueno habilitar algún sistema que nos permita saber cuándo hay un nuevo documento publicado en esta sección. Me conecto casi a diario, pero esta última temporada la publicación fue muy espaciada, y se hacía un poco pesado.

    En cuanto a este artículo, la idea con la que me he quedado (no sé si correcta) es que hay procesos en el servidor de aplicaciones que, por decisión de diseño, no son multi-hilo, y se dan las razones convenientes -que parecen bastante coherentes-.

    Si en otros procesos sí que se usa el multihilo, y realmente el rendimiento del servidor -salvo en los procesos monohilo- se ve beneficiado, no parece que vayamos a salir perdiendo. Es lógico que el diseñador «se guarde las espaldas». Además, los procesos que se manejan en aplicaciones de gestión no son del tipo que requieran un uso intensivo/continuo del procesador. Parece más importante que el vmotor sea capaz de manejar convenientemente las tareas de distintos usuarios/aplicaciones, y con eficiencia.

    De todos modos, creo que podría venir bien un resumen final, con las ideas más importantes de los dos artículos, para acabar con una síntesis clara del texto anterior.

  2. Actualmente las versiones beta disponibles estan en 32bits. Pero internamente mantenemos compilaciones de 64bits para mantener la compatibilidad permanentemente.

    Como puedes ver en los articulos sobre «Compilaciones radicales» se han compilado en arquitecturas de 64bits bastates diferentes a los Intel.

    Saludos

Dejar un comentario