Estrategias y gestión del almacenamiento

No obstante, las técnicas para mejorar el rendimiento en los sistemas Numa y en los paisajes distribuidos son similares.

Allí SAP-Como las aplicaciones manejan a menudo varios cientos de gigabytes o incluso terabytes de datos, es esencial un acceso eficiente a la memoria principal. Este artículo se centra en este aspecto:

SAP presentó en Sapphire 2012, en Orlando, un sistema que permite ejecutar consultas analíticas en un sistema distribuido de Hana-Se procesa una BD de 100 nodos con un total de 100 TB de memoria principal agregada.

Distribución típica Hana-paisajes tienden a utilizar de cinco a diez nodos de servidor. Sin embargo, está claro que en un entorno de servidores distribuidos, la atención se centra más en la distribución eficaz de datos y peticiones y en la comunicación eficiente en red que en el acceso eficiente a la memoria principal.

¿Qué es Numa?

Los sistemas de servidor modernos disponen de varios procesadores (o CPU) en su placa de circuitos, normalmente de una a cuatro CPU en los sistemas de sobremesa de Intelmientras que en Intel-servidores, se pueden encontrar de dos a ocho CPU. Los procesadores se conectan a la placa a través de un zócalo.

Cada una de estas CPU suele contener varios núcleos en los que se realizan los cálculos. Las CPU modernas de Intel contienen entre dos y diez núcleos. En total, los grandes servidores tienen hasta 80 núcleos disponibles para el procesamiento de datos.

Dado que, por razones térmicas entre otras, la frecuencia de reloj de los núcleos no puede aumentar más, el número de núcleos en los servidores aumentará aún más en los próximos años. Las CPU y la memoria principal están conectadas entre sí mediante un sistema de bus.

Si los cálculos de una solicitud pueden distribuirse entre muchos núcleos, se plantea la cuestión de cómo se transportan los datos a los núcleos. Básicamente, aquí hay dos alternativas a nivel de la arquitectura del procesador (Hennessy y Patterson, 2012):

1. Multiprocesamiento simétrico (SMP):
   En esta arquitectura, el tiempo de acceso a una dirección de memoria es el mismo para todas las direcciones y para todos los núcleos. Esta arquitectura se muestra en la Figura 2. Las cachés se asignan localmente a cada procesador. A la memoria principal se accede a través de un Autobúscompartida por todos los procesadores. En esta arquitectura, el Bus de memoria se convierten en un cuello de botella, ya que las operaciones de lectura que no pueden ser atendidas por la caché local y todas las operaciones de escritura pueden realizarse en la caché común. Bus de memoria necesitan acceder.
2. Acceso no uniforme a la memoria:
   En esta arquitectura (Figura 3), los procesadores tienen asignadas tanto las cachés como la memoria local. Para un procesador, acceder a la memoria local es más rápido que acceder a la memoria de otro procesador porque los accesos remotos se realizan a través de un Bus de memoria deben procesarse. Para los programas de aplicación, la asignación de memoria física a los procesadores individuales no es directamente reconocible - trabajan como en un SMP con un espacio de direcciones homogéneo.

Puesto que en la Intel-sistemas contienen varios núcleos en un procesador, esto da lugar a una arquitectura Numa a nivel de procesador, pero a un SMP-sistema a nivel de cada procesador.

Este último también se denomina multiprocesador de chip (CMP). Ejemplos SMP-son Intel Pentium D, Intel Itanium, IBM PowerSun UltraSparc T2 o SGI MIPS, mientras que ejemplos de arquitecturas Numa son las CPU Intel Nehalem o AMD Las CPU Opteron (y sus sucesoras) lo son.

¿Es Numa relevante para Hana?

El SAP–Hana-DB se desarrolló en cooperación con Intel para la ejecución en corriente Intel-Procesadores Xeon. Por ejemplo, el Hana-DB el ESS-Extensiones de Intel-procesadores para procesar múltiples elementos en paralelo en una instrucción de máquina.

Dado que estos Intel-procesadores se basan en una arquitectura Numa, el código del Hana-DB puede optimizarse para esta arquitectura. A continuación, se discuten algunos escenarios en los que los efectos de Numa en la Hana-DB son relevantes y cómo Hana-DB puede manejarlo.

Cuando una solicitud llega al Hana-DB, esta petición se asigna primero a un hilo. En general, los hilos permiten un procesamiento concurrente ligero de múltiples peticiones (en comparación con los procesos del sistema operativo).

Los hilos activos se muestran en un momento dado exactamente en un Núcleo ejecutada. Durante el procesamiento de una consulta, la base de datos debe asignar memoria en la mayoría de los casos, por ejemplo para recoger el resultado de la consulta para la aplicación de base de datos. A continuación, la memoria debe asignarse en la zona de memoria disponible para el procesador y la base de datos. Núcleo para que los accesos a memoria no se retrasen por accesos a memoria remota.

Los sistemas operativos modernos ya tienen en cuenta las arquitecturas Numa: tanto Microsoft Windows 7 o Windows Server 2008R2, así como Linux (a partir del kernel 2.5) intentan asignar memoria en el área asignada al procesador del hilo o proceso del sistema operativo. De este modo, las aplicaciones se benefician automáticamente de las optimizaciones del sistema operativo.

Cabe señalar aquí que las soluciones de virtualización como VMware ESX se abstraen del hardware físico. Dado que el software trabaja con CPU lógicas y una capa de virtualización para la memoria, las optimizaciones para una arquitectura Numa en un sistema virtualizado pueden incluso provocar efectos negativos.

La gestión automática de memoria del sistema operativo puede tener efectos indeseables si una aplicación gestiona ella misma la memoria para evitar costosas llamadas al sistema al asignar y liberar memoria. Entonces la memoria puede estar presente en la zona equivocada cuando se reutiliza la memoria. Prácticamente todas las bases de datos implementan su propia gestión de memoria que funciona a nivel de aplicación.

Otro efecto es que un hilo asigna memoria (localmente), pero muchos otros hilos quieren trabajar con esta memoria.

Como ejemplo, considere la memoria de una columna: Esta memoria se asigna una vez cuando la columna se carga en la memoria principal, pero muchas peticiones leen los datos de la columna.

En los dos escenarios mencionados, la gestión de la memoria a nivel de aplicación y el acceso a la memoria por parte de muchos hilos, puede ayudar una programación eficaz de los hilos. También en este caso, los sistemas operativos modernos implementan estrategias para ejecutar hilos en los que se asignan los datos utilizados.

Esto puede ir tan lejos que un hilo puede ser iniciado por un Núcleo se traslada a otra para poder procesar los accesos desde la memoria local. Sin embargo, el sistema operativo alcanza límites en los que, por ejemplo, el conocimiento del sistema de bases de datos puede llevar a tomar mejores decisiones sobre los resultados.

Soporte Numa en Hana

En la sección anterior se analizaron estrategias sobre arquitecturas Numa, que están disponibles para cualquier aplicación en servidores modernos y sistemas operativos modernos.

Sin embargo, estas técnicas por sí solas conducen a decisiones subóptimas porque no se pueden tener en cuenta las características específicas de un sistema de base de datos. Las posibilidades de optimización específicas de las bases de datos en el Hana-DB se aborda en esta sección.

Gestión del almacenamiento

Como ya se ha indicado, el Hana-Por razones de eficiencia, la base de datos utiliza una gestión de memoria que se basa en la gestión de memoria del sistema operativo. Normalmente, la memoria no se devuelve al sistema operativo cuando se libera en el código de la base de datos.

Al mismo tiempo, se reutiliza la memoria ya asignada. Por un lado, esto debería reducir la fragmentación de la memoria principal, pero también el número de llamadas al sistema operativo. En este punto, se abren posibilidades para explotar las propiedades específicas de una arquitectura Numa:

Cuando un hilo solicita memoria, se proporciona memoria local del procesador al hilo para que los accesos a esta memoria sean realizados por el servidor de memoria local.Controlador se procesan y se alivian los buses de memoria entre los procesadores. Esta estrategia parece especialmente útil en escenarios en los que la memoria es utilizada por subprocesos en el mismo procesador.

2. en algunos casos, sin embargo, parece tener más sentido distribuir la memoria solicitada entre varios procesadores. En los sistemas actuales, en determinados escenarios, la memoriaControlador representan un cuello de botella. En estos casos, tiene más sentido distribuir tanto la memoria como los hilos que la utilizan entre distintos procesadores. De esta forma, por ejemplo, al acceder a columnas grandes y de uso frecuente, se puede evitar el cuello de botella.

Programación de trabajos

En muchos casos, un sistema operativo moderno toma una buena decisión en cuanto a qué hilos en qué Núcleo deben ejecutarse.

La decisión tiene en cuenta si todavía hay núcleos en un procesador que no están realizando ningún cálculo en ese momento, el estado de actividad de los núcleos y procesadores individuales (para ahorrar energía, merece la pena agrupar el trabajo en procesadores individuales y desactivar otros procesadores), si los procesadores individuales están funcionando actualmente "overclockeados" (TurboBoost a Intel) y a qué datos accede un hilo.

Además de esta decisión automática del sistema operativo, un desarrollador de aplicaciones puede influir en la asignación de hilos a procesadores o núcleos.

Básicamente, las posibilidades de optimización asociadas en la programación de los hilos en el sistema dependen de la gestión de la memoria:

1. Si los datos utilizados por un subproceso se asignan localmente a un procesador, el subproceso también debe procesarse en ese procesador. Sorprendentemente, a veces merece la pena tener más subprocesos ejecutándose en un procesador de los que éste puede soportar (número de núcleos, con hyperthreading teóricamente el doble de núcleos), especialmente si estos subprocesos acceden a memoria compartida y esta memoria ya está disponible en las cachés.
2. Algunas operaciones complejas de bases de datos leen y escriben grandes cantidades de datos, lo que sobrecarga la memoria.Controlador Si los datos para estas operaciones ya están distribuidos por la memoria local de varios procesadores, entonces los hilos para acceder a los datos deben distribuirse entre varios procesadores. De este modo, la memoria individualControlador y la carga de trabajo se distribuye a través de múltiples conexiones de almacenamiento y almacenamientoControlador distribuido.
3. En algunos casos, las operaciones de base de datos, como las operaciones join, deben implementarse con especial atención a la arquitectura Numa. Las primeras "directrices" para tales implementaciones se discuten en la literatura de investigación (Albutiu, Kemper & Neumann, 2012).

El futuro de Numa

No sólo el software de bases de datos se creó durante varias décadas bajo la premisa de que la velocidad de procesamiento aumentaría con la siguiente generación de procesadores, en parte porque aumentaría la frecuencia de reloj. Por razones técnicas, este automatismo ya no se aplica desde principios del milenio.

Proveedores como Intel o AMD propagar sistemas en los que el trabajo se distribuye entre varios procesadores, cada uno con varios núcleos. Como se comenta en el artículo, parece estar ganando aceptación una arquitectura en la que el acceso a la memoria varía en complejidad, dependiendo de dónde se haya asignado físicamente la memoria (denominada Numa).

Por tanto, el software de aplicación debe rediseñarse para aprovechar el paralelismo que ha traído consigo la disponibilidad de arquitecturas multinúcleo. En este sentido, el software debe tener en cuenta las peculiaridades de la arquitectura Numa y optimizar la asignación y el acceso a la memoria.

Aunque los sistemas operativos modernos proporcionan algunas optimizaciones en este ámbito, las aplicaciones críticas para el rendimiento, como el Hana-DB puede realizar mejoras que van mucho más allá.

En el Hana-ya incorpora algunas de estas mejoras. No obstante, la implantación de bases de datos en arquitecturas Numa no ha hecho más que empezar y cabe esperar nuevas mejoras.