Please enable JavaScript.
Coggle requires JavaScript to display documents.
An Analysis of Linux Scalability to Many Cores - Coggle Diagram
An Analysis of Linux Scalability to Many Cores
The Mosbench Applications
Mail Server
Se ejecuta de modo que un solo proceso maestro escucha las conexiones SMTP entrantes a través de TCP y bifurca un nuevo proceso para cada conexión, que a su vez acepta el correo entrante, lo pone en cola, lo agrega al archivo de correo de usuario, elimina el correo en cola y registra la entrega en un archivo de registro compartido.
Object Cache
memcached es un almacén de clave-valor en memoria que se utiliza a menudo para mejorar el rendimiento de las aplicaciones web.
Ejecuta varios servidores Memcached, cada uno en su propio puerto, y hace que los clientes distribuyan de manera determinista las búsquedas de claves entre los servidores.
Web Server
Apache es un servidor web popular, que se ha utilizado en trabajos anteriores para estudiar la escalabilidad de Linux.
Cada proceso tiene un grupo de subprocesos para dar servicio a las conexiones. Un subproceso se dedica a aceptar conexiones entrantes mientras que los otros subprocesos procesan las conexiones.
Database
PostgreSQL es una base de datos SQL de código abierto popular que, a diferencia de muchas de nuestras otras cargas de trabajo, hace un uso interno extensivo de estructuras de datos compartidos y sincronización.
Parallel Build
gmake es una implementación de la utilidad make estándar que admite la ejecución simultánea de reglas de compilación independientes.
gmake es el punto de referencia predeterminado no oficial en la comunidad de Linux.
File Indexer
Psearchy es una versión paralela de searchy, un programa para indexar y consultar páginas web.
Map Reduce
Metis es una biblioteca de MapReduce para servidores multinúcleo únicos inspirada en Phoenix.
Kernel Optimizations
Multicore packet processing
Un paquete recibido generalmente pasa por varias colas antes de llegar finalmente a una cola por socket, desde la cual la aplicación lo lee con una llamada al sistema como leer o aceptar.
El buen rendimiento con muchos núcleos y muchas conexiones de red independientes exige que cada paquete, cola y conexión sean manejados por un solo núcleo.
Sloppy counters
Linux usa contadores compartidos para la recolección de elementos no utilizados contados por referencia y para administrar varios recursos.
Sloppy Counters, se basa en la intuición de que cada núcleo puede contener algunas referencias de repuesto a un objeto, con la esperanza de que pueda otorgar la propiedad de estas referencias a los subprocesos que se ejecutan en ese núcleo, sin tener que modificar el recuento de referencia global.
Lock-free comparison
The lock-free protocol utiliza un contador de generación, que el núcleo PK incrementa después de cada modificación de una entrada de directorio.
Per-core data structures
Primero se divide la lista por superbloque de archivos abiertos en listas percore. Cuando un proceso abre un archivo, el kernel bloquea la lista del núcleo actual y agrega el archivo. En la mayoría de los casos, un proceso cierra el archivo en el mismo núcleo en el que lo abrió.
Eliminating false sharing
El rendimiento por núcleo de Exim se degradó debido al uso compartido falso de indicadores y recuentos de referencias de páginas físicas, que el núcleo ubicó en la misma línea de caché de una variable de página. Memcached, Apache y PostgreSQL enfrentaron problemas similares de uso compartido falso con dispositivos de red y variables de dispositivos.
Colocar los datos muy modificados en una línea de caché separada mejora la escalabilidad.
Evaluation
Method
Se ejecutan las aplicaciones que modifican archivos en un tmpfs en el sistema de archivos de memoria para evitar esperar la E/S del disco. El resultado es que MOSBENCH estresa más al kernel que si tuviera que esperar por el disco.
El propósito de estos experimentos es evaluar el rendimiento multinúcleo del kernel de Linux, utilizando las aplicaciones para generar una combinación razonablemente realista de llamadas al sistema.
Exim
Se configura Exim para usar tmpfs para todos los archivos mutables (archivos de cola, archivos de registro y archivos de correo de usuario) y deshabilitamos DNS y RFC1413
búsquedas
Los clientes se ejecutan en la misma máquina que Exim. Cada uno abre repetidamente una conexión SMTP a Exim, envía 10 mensajes separados de 20 bytes a un usuario local y cierra la conexión SMTP.
memcached
Se ejecuta un proceso Memcached 1.4.4 separado en cada núcleo para evitar la contención de bloqueo de aplicaciones. Cada servidor está anclado a un núcleo separado y tiene su propio puerto UDP.
Se usa una cola de recepción y transmisión de hardware separada para cada núcleo y se configura el IXGBE para inspeccionar el número de puerto en cada encabezado de paquete entrante, colocar el paquete en la cola dedicada al núcleo de memcached asociado y entregar la interrupción de recepción a ese núcleo.
Apache
Se ejecuta una instancia separada de Apache por núcleo con cada servidor ejecutándose en un puerto distinto.
Apache bifurca un proceso por núcleo, anclando cada nuevo proceso a un núcleo diferente. Cada proceso dedica un subproceso para aceptar conexiones desde el socket de escucha compartido.
Postgre SQL
Se configura PostgreSQL para usar un caché de nivel de aplicación de 2 Gbyte porque PostgreSQL protege su lista libre de caché con un solo bloqueo y, por lo tanto, se escala mal con cachés más pequeños.
gmake
Se mide el rendimiento de gmake paralelo mediante la creación de archivos de objetos de Linux 2.6.35-rc5 para x86 64. Todos los archivos de origen de entrada residen en la memoria caché del búfer y los archivos de salida se escriben en tmpfs.
Psearchy/pedsort
El pedsort con subprocesos se escala mal porque un kernel mutex por proceso serializa las llamadas a mmap y munmap para el espacio de direcciones virtuales de un proceso. pedsort lee los archivos de entrada mediante secuencias de archivos libc, que acceden al contenido de los archivos a través de mmap.
Discussion
Las aplicaciones MOSBENCH pueden escalar bien a 48 núcleos, con cambios modestos en las aplicaciones y en el kernel de Linux.
Las técnicas que han introducido una serie de sistemas operativos de investigación multinúcleo recientes (como rangos de direcciones, núcleos dedicados a funciones, memoria compartida para el paso de mensajes entre núcleos, asignación cuidadosa de estructuras de datos a cachés en chip...) podrían aplicarse igualmente bien a Linux, mejorando su rendimiento absoluto y beneficiando a determinadas aplicaciones.
Un problema más difícil es abordar los cuellos de botella en las aplicaciones, o aquellos en los que el rendimiento de la aplicación no se ve obstaculizado por los ciclos de la CPU, sino por algún otro recurso de hardware, como la DRAM.
banda ancha.
Related Work
Linux scalability improvements
Los primeros kernels multiprocesador de Linux se escalaban mal con cargas de trabajo paralelas intensivas en el kernel. Desde entonces, la comunidad de Linux ha rediseñado muchos subsistemas del kernel para mejorar la escalabilidad.
El simposio de Linux presenta documentos relacionados con
escalabilidad casi todos los años.
Linux scalability studies
Gough estudia la escalabilidad de Oracle Database 10g ejecutándose en Linux 2.6.18. El estudio encuentra problemas con la cola de ejecución de Linux, el asignador de bloques y el procesamiento de E/S.
Veal y Foong evalúan la escalabilidad de Apache ejecutándose en Linux 2.6.20.3.
Una serie de nuevos sistemas operativos de investigación utilizan los problemas de escalabilidad en Linux como motivación.
Solaris scalability studies
Solaris proporciona un UNIX API y se ejecuta en procesadores multinúcleo basados en SPARC y x86.
Zou encontró bloqueos de granularidad gruesa en la pila de redes UDP de Solaris 10 que limitaban la escalabilidad del servidor proxy OpenSER SIP en un sistema SPARC de 8 núcleos.
La licencia de Solaris prohíbe informar resultados cuantitativos, sin embargo se observan resultados similares o peores en compaortamientos de escalabilidad en comparación con Linux.