Usando un disco RAM para aumentar la velocidad

2 comentarios

A veces necesitamos que se acelere la velocidad con la cual se realizan operaciones en nuestra Base de Datos, sobre todo cuando se accede a ella mediante Internet. Una de las opciones que tenemos para conseguirlo es a través de un disco RAM.

¿Qué es un disco RAM?

Es una parte de la memoria RAM de la computadora que se usa como si fuera un dispositivo de almacenamiento (disco duro, pen-drive, etc.)

¿Por qué usar un disco RAM?

Un disco RAM a todos los efectos funciona como si fuera una memoria externa (disco duro, pen-drive, etc.) pero utilizando parte de la memoria RAM de la computadora. Eso significa que los datos y los archivos no se grabarán ni en el disco duro ni en el pen-drive sino en la memoria RAM pero para el Sistema Operativo y para todos los otros programas será como si se hubieran grabado en un disco duro o en un pen-drive.

La gran ventaja de usar un disco RAM es la gran velocidad que se consigue en todas las operaciones. Si está bien configurado, en muchos casos se consigue acelerarlas hasta en 40 veces, lo cual hace una diferencia increíblemente notoria. ¿Por qué eso? porque la memoria RAM es muchísimo más rápida que la memoria externa (disco duro, pen-drive, etc.)

¿Cuáles son las desventajas de usar un disco RAM?

No todo es bueno, también hay un problema potencial y es el siguiente: si se apaga o se reinicia la computadora todo el contenido del disco RAM se perderá.

Eso es debido a que el disco RAM, tal como su nombre lo indica, se encuentra en la memoria RAM y si el contenido de ésta se pierde (lo cual siempre sucede cuando se reinicia o se apaga la computadora) todo lo que estaba en el disco RAM desaparecerá para siempre. Lo anterior implica que si vas a usar un disco RAM sí o sí deberás tener también una UPS (unidad de corriente ininterrumpida) confiable conectada a tu computadora. Usar un disco RAM sin una UPS en buen estado es una locura, una idiotez.

Otra desventaja es que evidentemente la memoria RAM de tu computadora disponible para los programas disminuye en el  tamaño que le asignaste a tu disco RAM. Por ejemplo, si tu computadora tiene 4 Gigabytes de RAM y al disco RAM le asignaste 1 Gigabyte de RAM, los demás programas (el Sistema Operativo y todos los demás) solamente tendrán 3 Gigabytes disponibles.

¿Cuándo debería usar un disco RAM?

  1. Cuando tienes una necesidad imperiosa de acelerar las operaciones con tu Base de Datos
  2. Cuando tienes una buena y confiable UPS conectada a tu computadora
  3. Cuando tienes bastante memoria RAM para que usar una parte de la misma como disco RAM no afecte a los demás programas

Si alguno de esos puntos no se cumple, no uses un disco RAM

¿Cómo hago para crear un disco RAM?

Existen varios programas que realizan esa tarea, por ejemplo este es el que yo utilizo:

http://memory.dataram.com/products-and-services/software/ramdisk

tiene una versión freeware que permite almacenar hasta 4 Gigabytes lo cual es más que suficiente para la mayoría de las Bases de Datos que no guardan contenido multimedia. Además, puede automáticamente guardar el contenido del disco RAM en un archivo y restaurarlo cuando se reinicia la computadora lo cual a todos los efectos funciona como si se tuviera otro disco duro.

¿Cómo funciona un disco RAM?

Exactamente igual que un disco duro o pen-drive. Después de instalar el disco RAM tendrás una nueva letra de unidad (por ejemplo: F:, G:, H:, etc.) en la cual podrás copiar, borrar, o renombrar archivos, tal como lo harías en la unidad C:

¿Qué debo guardar en el disco RAM?

Siempre recordando que esto se aplica a Firebird:

  • Podrías guardar los archivos temporales

En el archivo FIREBIRD.CONF que se encuentra en la carpeta donde instalaste el Firebird (por ejemplo en: C:\ARCHIVOS DE PROGRAMA\FIREBIRD\FIREBIRD_2_5) puedes especificar en cual carpeta (directorio) se guardarán los archivos temporales. Para ello busca la etiqueta

#TempDirectories =

bórrale el símbolo de numeral y especifica cual será la carpeta temporal, por ejemplo si tu disco RAM se encuentra en la unidad G: tendrías que escribir:

TempDirectories = G:

Haciendo así, todos los archivos temporales del Firebird (usa archivos temporales para reordenar, para backups y restores y para otras operaciones) se encontrarán en el disco RAM y el incremento en la velocidad será muy notorio.

NOTA: Para que los cambios realizados en el archivo FIREBIRD.CONF tengan efecto deberás reiniciar el Servidor del Firebird (o reiniciar la computadora donde se encuentra el Servidor del Firebird).

 

Diferencias entre SuperServer, Classic y SuperClassic

8 comentarios

Cuando se instala el Firebird tenemos la opción de elegir la arquitectura:

  • Classic
  • SuperClassic
  • SuperServer

¿Por qué hay varias arquitecturas?

Porque difieren en como manejan las conexiones múltiples (porque Firebird, aunque puede ser usado en aplicaciones mono-usuario fue creado para ser usado mayormente en aplicaciones multi-usuario), y esa diferencia se refleja en el consumo de memoria RAM.

¿Hay una arquitectura que es mejor en todos los casos?

No, si la hubiera, esa sería la única que existiría. ¿Para qué tener varias arquitecturas si una de ellas le superara en todo a las demás? No tendría sentido. Por lo tanto, el hecho de existir varias arquitecturas significa que cada una de ellas es mejor que las otras en alguna tarea.

¿Cuál arquitectura debo elegir?

La elección depende de la computadora, del Sistema Operativo y de la cantidad de usuarios que se conectarán al mismo tiempo (en Informática se dice: concurrentemente) a la Base de Datos.

En Windows, hasta unos 25 usuarios puedes instalar SuperServer, funcionará bien. En Linux, cualquiera. Si tu computadora es de 64 bits, SuperClassic puede ser la mejor elección (instalando la versión de 64 bits, por supuesto); pero si es de 32 bits SuperClassic será el primero que se quedará sin memoria.

¿Elegir alguna de esas arquitecturas afectará a las bases de datos o a las aplicaciones?

No, las bases de datos continuarán exactamente igual sea cual sea la arquitectura elegida, nada cambiará dentro de ellas y nada debes modificar. Las bases de datos no saben con cual arquitectura estás accediendo a ellas. Igualmente, nada debes cambiar dentro de tus aplicaciones. Los que cambian son los servidores, no las bases de datos.

¿Qué implica elegir una de esas arquitecturas?

Procesos:

    • Classic usa un proceso separado (único) para cada conexión
    • SuperClassic usa un solo proceso para todas las conexiones
    • SuperServer usa un solo proceso para todas las conexiones

¿Qué ocurrirá si hay un problema grave en un proceso? si usas Classic, los demás procesos no se verán afectados; en cambio si usas SuperClassic o SuperServer finalizarán todas las conexiones, con todas las nefastas consecuencias que te puedas imaginar. Por lo tanto, desde este punto de vista lo mejor sería que uses Classic.

Guardian:

    • Classic no usa al Guardian
    • SuperClassic puede usar al Guardian en Linux pero no en Windows
    • SuperServer sí puede correr bajo el control del Guardian

¿Para qué sirve el Guardian? Para reiniciar el Servidor automáticamente en el caso de una falla grave. Desde este punto de vista, el mejor es SuperServer.

Recursos:

    • Classic usa más recursos (más memoria RAM) que las demás arquitecturas porque cada conexión requiere de memoria RAM para el proceso y para la memoria cache
    • SuperClassic necesita más memoria RAM cuando hay más usuarios conectados porque cada conexión requiere de memoria cache
    • SuperServer usa siempre la misma cantidad de memoria RAM, sin importar la cantidad de conexiones

Cada conexión en Classic requiere de una “X” cantidad de memoria RAM (por defecto: 300 kilobytes), eso significa que si la cantidad de conexiones se incrementa también lo hará la memoria RAM consumida. En cambio SuperServer usa siempre la misma cantidad de memoria RAM, sin importar cuantos usuarios estén conectados. Desde este punto de vista, SuperServer es mejor.

Conexiones locales:

    • En Linux, Classic y SuperClassic ofrecen un modo “embedded” que es muy rápido aunque poco seguro en cuanto al acceso
    • En Windows, en un solo archivo se tienen el Servidor y el Cliente “embedded”, el cual es aún más inseguro en cuanto al acceso

¿Por qué usar una conexión local? Porque eso nos permite tener en un CD, DVD, pen-drive u otro dispositivo removible nuestra aplicación y nuestra Base de Datos, lo cual lo hace muy útil para programas de catálogo, programas de demostración, etc. O sea que en un pen-drive podríamos tener todo lo que necesitemos sin necesidad de instalar algo en las computadoras ajenas, de nuestros potenciales clientes.

Conexiones simultáneas:

    • Classic permite conexiones simultáneas a una Base de Datos desde un Servidor normal y desde uno o más servidores “embedded”
    • SuperClassic permite conexiones simultáneas a una Base de Datos desde un Servidor normal y desde uno o más servidores “embedded”
    • SuperServer no permite conexiones simultáneas a una Base de Datos desde un servidor normal y uno o más servidores “embedded”

Esto significa que puede ser ventajoso que tu Servidor normal sea Classic o SuperClassic si simultáneamente necesitas conectarte a la Base de Datos desde un servidor “embedded”

Multiprocesamiento:

    • Todas las arquitecturas (exceptuando SuperServer en Windows) ya están preparadas por defecto para usar todos los procesadores o cores de las computadoras
    • SuperServer en Windows por defecto usa solamente el primer procesador o core. Para que use más procesadores se debe modificar el parámetro CpuAffinityMask en el archivo FIREBIRD.CONF

Fuera de memoria:

    • Classic usa más memoria RAM que las otras arquitecturas cuando la cantidad de conexiones se incrementa. Cada conexión usará (por defecto) 300 Kilobytes
    • En 32 bits SuperClassic será el primero en quedarse sin memoria
    • El consumo de memoria por SuperServer es fijo, sin importar la cantidad de usuarios conectados. Por defecto esa cantidad es de 8 Megabytes

Por lo tanto, si habrá hasta 25 usuarios conectados suele ser preferible usar SuperServer pero cuando la cantidad de usuarios conectados sea mayor Classic será una mejor elección en 32 bits y SuperClassic en 64 bits.

Problema con operaciones intensivas:

    • Classic no tiene problemas con las operaciones intensivas
    • Supper Classic y SuperServer pueden encontrarse con un “cuello de botella” si una transacción está teniendo mucho tráfico en la red (por ejemplo un SELECT que trae millones de filas)

Un SELECT que traiga más de 100 filas con seguridad está mal diseñado pero a veces esos errores de diseño ocurren. En tal caso dicho SELECT estará consumiendo demasiados recursos y si se está usando SuperClassic o SuperServer todas las demás transacciones se verán afectadas. Dicho problema también podría ocurrir si se están haciendo inserciones masivas (por ejemplo, migrando todo el contenido de  una tabla .DBF en una tabla de Firebird)

Para estos casos, Classic es el mejor.

Unos gráficos explicativos

Dicen que un gráfico es mejor que mil palabras, así que espero que estos gráficos te ayuden a entender mejor todo lo anterior

ClassicServerDiagram(1)

SuperClassicDiagram

SuperServerDiagram

Como puedes ver, Classic ejecuta un proceso (una instancia del programa FBSERVER.EXE) para cada conexión. Tambien la memoria cache utilizada aumenta con cada conexión (si hay una conexión se usará “X” memoria, pero si hay dos conexiones se usará “2X” memoria, si hay tres conexiones se usará “3X” memoria y así sucesivamente).

SuperClassic y SuperServer usan un solo proceso (una sola instancia del programa FBSERVER.EXE) sin importar cuantos usuarios estén conectados. Pero el consumo de memoria cache es distinto: mientras que SuperClassic aumenta la memoria cache junto con la cantidad de usuarios, SuperServer no lo hace así: la memoria cache utilizada es siempre la misma, sin importar cuantos usuarios estén conectados.

Conclusión:

La arquitectura elegida puede afectar grandemente el rendimiento o desempeño de tus aplicaciones. Como elegir una arquitectura u otra no afectará a las bases de datos lo más conveniente suele ser el viejo método informático de “prueba y error”. Pruebas con una, si no te satisface pruebas con otra y si tampoco te satisface pruebas con la tercera. En otro artículo explicaré como cambiar el tamaño de la memoria cache y otros parámetros que afectan al rendimiento y desempeño de las aplicaciones. Mediante ellos podrás conseguir mayor velocidad en todas las operaciones.

.