Conoce los límites
Límites de tablas y de instancias
Hay un límite de 65.535 tablas por instancia, en definitiva, por proyecto.
Hay un límite total de tablas de 2.147.483.648 en el servidor.
Con los datos anteriores, podemos calcular el número máximo de instancias que podrá soportar Velneo vServer, si hay un límite total de 2.147.483.648 tablas y podemos tener 65.535 tablas por instancia, entonces el máximo de instancias máximo será de 32.768 instancias.
Dimensionamiento de Velneo vServer y limitaciones por sistema operativo
Introducción
En este documento vamos a ver dónde están los límites de Velneo vServer de cara a poner en marcha un nuevo proyecto tanto en cloud como en local.
Descripción
Velneo vServer se encarga de cargar en memoria todas las instancias declaradas cuando arrancamos el servicio vatp.
Esas instancias ocupan un espacio en memoria y además hay que sumar cierto espacio que consumen las cabeceras de cada una de las tablas de cada instancia.
Esto nos da una suma total de memoria mínimo consumida por instancia.
¿Cómo calcularlo?
Para calcular ese número no existe una fórmula matemática, pero sí se puede hacer una aproximación. Para ello debemos seguir los siguientes pasos:
Preferiblemente en una máquina con el mismo sistema operativo que va a tener finalmente el Velneo vServer en producción, iniciar el vServer y comprobar la memoria total utilizada por ese proceso, con las soluciones instaladas. En Windows se puede hacer usando el administrador de tareas y en linux con top, mirando la columna VIRT. A este valor en megabytes lo vamos a llamar N.
Crear una única instancia para la solución que vamos a poner en producción.
Cargamos y mostramos en rejilla los registros de al menos 3 tablas principales, con el número de registros que se estima van a manejar, y nos aseguramos que son cargados en la caché del cliente al menos un 5% de los datos de la tabla, por ejemplo presentando un Informe.
Volvemos a mirar la memoria usada por el proceso vServer. A la diferencia le sumamos un 20% aproximadamente que el vServer necesita para otras gestiones para esa instancia. A este valor en megabytes vamos a llamarlo M. Cuantas más instancias realicemos, más aproximado será el valor que consigamos de M.
¿Dónde está el límite?
Depende de si Velneo vServer es de 32 o de 64 bits.
En el caso de Velneo vServer 32 bits
Al tratarse de una aplicación 32 bits, hay que tener en cuenta que Velneo vServer tiene un límite de uso de memoria de 2Gb en Windows 32/64 bits, y Linux 32 bits, y de casi 4 Gb en Linux de 64 bits, aunque establecemos uno prudencial de 1,5Gb y 3,0Gb respectivamente. Este será el tamaño S que especifica la memoria que determinamos disponible para instancias y que varía en función del sistema operativo.
Para calcular cuántas instancias como máximo podemos crear en un Velneo vServer podremos hacer el siguiente cálculo aproximativo:
numero instancias = \(S - N\) / M
Por ejemplo, una máquina Windows, que instalada tiene un valor para N de 150 MB y que la instanciación da un valor M de 5 MB, la fórmula sería la siguiente:
Número de instancias = \( 1500 - 150 \) / 5 = 270
En el caso de Velneo vServer 64 bits
El límite lo marca el sistema operativo, así que conviene saber en qué consume memoria un Velneo vServer.
Velneo vServer consume memoria en:
Soluciones instaladas.
Instancias:
Configuración de la instancia.
Proyectos de aplicación y datos.
Cabeceras de todos los ficheros en disco correspondientes a cada tabla y variables en disco.
dat, idx, cni, cnd, var.
Memoria correspondiente a procesos en 3º y 4º plano:
Variables, campos, listas, parámetros, etc.
Operaciones de la base de datos: alta, baja, modificación, actualizaciones, triggers y gestión de transacciones en memoria.
Tablas en memoria.
Empaquetado de aplicaciones para el cliente.
Tareas:
Procesos.
Creación de copias de seguridad.
Creación de ficheros instalables.
Enganches en curso.
Regeneraciones de índices y BigKey.
Configuración de usuarios, grupos, instancias, carpetas compartidas, etc.
Información de transacciones en curso e histórico temporal.
Carpetas compartidas para servidor de disco.
Librerías, librerías externas.
Sockets en curso o recién cerrados.
Hilos en curso.
Ficheros abiertos.
Caché de disco.
Debemos tener en cuenta que los ficheros que guardan la información de los proyectos en disco están serializados de forma comprimida, con lo que su carga en memoria supone un tamaño mucho mayor del que se observa en disco. Dependiendo del contenido, puede llegar a ocupar memoria hasta 8 veces o más que el tamaño que muestran en disco.
Aunque en todo caso, el consumo es variable, la parte principal inicial que varía está claro que está directamente relacionada con las soluciones e instancias, y en función del número y tamaño de éstas, el consumo del servidor será mayor o menor.
En segundo lugar, los procesos y transacciones, hacen uso directo de memoria durante la ejecución de un proceso, y hasta la finalización del proceso se almacena la información correspondiente a la transacción, estado anterior del registro, etc. Cuando implican gran número de operaciones, ésta puede ser una razón para consumir gran cantidad de memoria y llegar a ocupar toda la memoria disponible del sistema, de ahí nuestra recomendación de realizar la ejecución de estos procesos por lotes, con un número de operaciones controlado.
Así, donde la fórmula era:
( S - N ) / M = nº de instancias
Podemos calcular lo que consume una instalación en estimación:
( nº * M ) + N = S
S el consumo de memoria estimado.
Por ejemplo para vERP, con 10 instancias:
10 instancias * 25 MB por instancia + 150 MB = 400 MB
A esto hay que sumar el margen para procesos, etc., y que es al menos de medio giga, 1 por cada 4GB utilizados.
Además, ciertas operaciones como el reinicio de instancias, la regeneración de índices, reconstrucción de tablas, pueden requerir más memoria, también en función del tamaño de los proyectos, del número de registros y/o tamaño de las tablas.
En el caso de reinicio de soluciones, el valor de memoria requerida puede crecer en gran medida, dependiendo de las soluciones reiniciadas. Debemos tener en cuenta que cuando reiniciamos una solución, reiniciamos cada una de las instancias asociadas, cuantas más instancias tengamos, más memoria necesitará.
En el caso de regeneraciones de índices con y sin BigKey, reconstrucciones, etc., hará uso de toda la memoria disponible hasta 80% de la memoria física total disponible.
Recomendaciones
Debido a que Velneo vServer necesita más memoria para determinadas labores (tablas en memoria, regeneración de índices, información del servidor, transacciones, enganches, envío de proyectos al cliente etc.), no es conveniente llegar hasta el número máximo de instancias.
No olvides consultar los requerimientos del sistema para establecer los valores mínimos, y estima la carga de tu servidor, con el fin de parametrizar tu instalación de la mejor forma, preferentemente en Velneo Cloud donde te puedes olvidar del hardware. Si es en local, no olvides configurar tu sistema operativo para que obtenga el máximo rendimiento del procesador. En Windows deberás acceder a la Opciones de energía para configurar el máximo de rendimiento, y en Linux puedes hacer uso de TLP.
Para evitar la fragmentación de memoria, recomendamos que siempre esté disponible un porcentaje de memoria libre, mínimo del 25%, y proporcional al número de instancias y la carga que tenga el servidor, para que éste no sufra de fragmentación de memoria y pueda responder de forma eficiente en cargas de trabajo puntuales que requieran de memoria como en el caso de regeneraciones, procesos en 3º plano, etc.
El ideal sería un 75% de memoria libre al menos tras arrancar el servidor.
Recomendamos que el servidor esté en una máquina específica para éste, sin otro software con el que tenga que competir por la memoria.
También debemos evitar la gestión dinámica de memoria en virtualizaciones, ya que producen problemas al chocar su gestión de memoria con la del sistema operativo residente.
El servidor nos avisará cuando se llegue a valores críticos: podremos ver en los mensajes del panel de Velneo vAdmin mensajes indicando que la memoria disponible no es suficiente para seguir trabajando. Debemos tener en cuenta que si el sistema operativo detecta que tiene problemas de falta de memoria, puede llegar a cerrar aplicaciones para poder seguir trabajando, por lo que puede llegar a parar nuestro servidor si lo encuentra necesario.
Con ayuda de estos consejos puedes obtener el máximo rendimiento de tus aplicaciones y dar el mejor servicio a tus clientes.
Límite de variables alfabéticas y numéricas
Tanto las variables globales (disco y memoria) como las locales, tienen el mismo comportamiento en lo que a capacidad de almacenamiento se refiere.
Las variables alfabéticas tienen una limitación de 2gb (512 millones de caracteres), teniendo en cuenta que 1 carácter son hasta 4 bytes. La razón es que usa UTF-16 para guardar las cadenas. Eso quiere decir que guarda caracteres normales con 1 byte, tildes y otros con 2 bytes, y caracteres de otros idiomas o emojis con hasta 4 bytes.
En Las variables numéricas el rango máximo es el mismo que el de los campos numéricos: el rango máximo es 10 bytes (Del 0 al 0 al 1.208.925.819.614.629.174.706.176, o con signo del -604.462.909.807.314.587.353.088 al 604.462.909.807.314.587.353.088, con 10 decimales del 0,0000000000 al 120.892.581.961.462,9531250000).
Añadir que a nivel interno en los cálculos numéricos se opera con 34 dígitos significativos, sumando enteros y decimales e incluyendo el 0 y el punto en un número decimal.
Límites del contenedor
El contenedor es un fichero que se genera para tablas que tengan campos objeto.
El límite que tiene un contenedor de una tabla es de 36^5 = 60.466.176 de objetos de cada tipo de objeto (binarios, dibujos, objetos texto, objeto texto enriquecido y fórmula).
El tamaño máximo que puede tener un objeto a incluir en el contenedor es de 512 MB.
Debemos tener en cuenta que tanto para introducir el objeto como para exportarlo, el servidor requerirá 512 MB libres de memoria.
Límite de procesos asíncronos en cola
El número máximo de procesos en 2º plano admitidos en una cola es de 268.435.456.
El número máximo de procesos en 4º plano (se ejecutan en una cola única) es de 268.435.456.
Límites del control de edición numérica de formularios
El control edición numérica de formularios usa el tipo de dato double de C++, que guarda los números con exponente (su valor oscila entre -1,79769313486231570E+308 y -4,94065645841246544E-324 para valores negativos y entre 4,94065645841246544E-324 y 1,79769313486231570E+308 para valores positivos.), y tiene limitaciones a la hora de mostrar la información y editarla si se excede dicho rango.
En campos, en procesos, fórmulas, etc., no existe el problema ya que garantizamos 64 dígitos significativos, pero a la hora de editar la información con este tipo de control, encontraremos esta limitación. En el caso de necesitar editar campos cuyo contenido exceda ese límite, podemos usar en su lugar un control de edición alfabética.
Tolerancias al error en las comunicaciones en Velneo
Tolerancia con dispersión a la pérdida de paquetes | 10% |
Tolerancia a la latencia | 300ms |
Dispersión de latencia | 20% |
Esto indica que en redes con valores superiores no podemos garantizar el funcionamiento correcto de la aplicación.
Uso de localstorage en Velneo Web
Al ejecutar aplicaciones en web, cuando se usa el localstorage (almacenamiento local del navegador), dado no puede superar los 10 Mb, se controlará para limpiar los ficheros más antiguos garantizando que no se supera el límite.