La compresión a menudo juega un papel muy importante en el proceso de transmisión y almacenamiento de datos, por lo que mejorar la eficiencia de la compresión puede ayudarnos a ahorrar tiempo y reducir los costos de almacenamiento. Este artículo presenta la aplicación de la optimización del algoritmo de compresión en la plataforma de construcción e implementación, lo que puede ayudar a los equipos de I + D a mejorar la I + D y la eficiencia de la entrega.
antecedentes
En términos generales, el proceso de construcción e implementación de la plataforma de publicación de servicios (excepto la implementación de imágenes) se someterá a construcción (código de sincronización -> compilación -> empaquetado -> carga), implementación (descargar paquete -> descomprimir en la máquina de destino -> reiniciar el servicio) , etc. paso. Tomemos como ejemplo la plataforma de lanzamiento interna Plus de Meituan. Recientemente, descubrimos que algunos elementos de lanzamiento tardan mucho en empaquetar y comprimir el producto. El paso de empaque que se muestra en la siguiente figura tomó 1 minuto y 23 segundos en total.
Cuando solemos responder a las preguntas de operación y mantenimiento de los usuarios, también encontramos que muchos usuarios están acostumbrados a poner en el almacén algunos datos más grandes relacionados con el aprendizaje automático o la PNL. Esta parte de los datos a menudo ocupa cientos de megabytes o incluso varios GB de espacio en disco. afecta en gran medida la velocidad del envasado. Lo mismo ocurre con los proyectos de Java, debido a que existen muchos marcos de servicios de Java y muchas dependencias, estos servicios suelen ocupar un espacio de 100 megabytes después de ser empaquetados y tardarán más de diez segundos. La siguiente figura es la mediana de nuestro paso de paquete. Básicamente, la mayoría de los servicios de Java y de Node.js tardan al menos 13 segundos en comprimir y empaquetar.
El paquete es un paso necesario para casi todos los servicios que deben implementarse. Su tiempo actual es básicamente menor que el de compilar y construir imágenes. Por lo tanto, para mejorar la eficiencia general de la construcción, vamos a realizar una ronda de Trabajos de optimización en los pasos de empaquetado y compresión del paquete.
Comparación de esquemas
Preparar los datos de la escena
Análisis del tamaño del paquete de los elementos publicados
Para simular los escenarios de aplicación en la construcción e implementación tanto como sea posible, hemos organizado y analizado algunos de los datos del paquete de construcción en 2020. El tamaño del paquete comprimido se muestra en la siguiente figura. La curva de campana muestra que el paquete general el volumen se distribuye normalmente y tiene un efecto de cola larga más obvio. El volumen después de la compresión se encuentra principalmente dentro de los 200 M y el tamaño antes de la compresión está aproximadamente dentro de los 516,0 MB.
Y el 99% del tamaño del paquete de compresión del servicio será inferior a 1 GB, y para el paso de compresión, de hecho, cuanto más grande sea el proyecto, más tiempo consumirá y mayor será el espacio de optimización. Por lo tanto, en la prueba de comparación de programas específicos, elegimos un paquete de construcción de aproximadamente 1 GB para las pruebas de compresión, que puede cubrir el 99% de las escenas, y también se puede ver que los algoritmos de compresión han mejorado significativamente.
Las principales razones de esta elección son las siguientes:
-
En el caso de datos grandes, el resultado del cálculo tendrá un error mucho menor que los datos pequeños.
-
Puede cubrir la mayoría de los escenarios de aplicación.
-
El efecto de contraste es obvio, se puede ver si hay una mejora significativa.
Observaciones: Dado que la velocidad de compresión no ha cambiado significativamente con la misma configuración de la misma biblioteca de compresión y la misma relación de compresión, no hay una prueba por lotes ni un resumen de datos para otros tamaños de paquetes.
El proyecto de prueba que usamos en este artículo es un proyecto C ++ más grande dentro de Meituan, donde los tipos de archivo excluyen C ++, Python, archivos de código Shell y datos binarios como NLP y herramientas (excluyendo los datos de envío almacenados en .git). es más completo.
El tamaño del catálogo es 1.2G y la brecha entre las diferentes soluciones se puede comparar claramente .
gzip
gzip es un algoritmo basado en DEFLATE , que es una combinación de codificación LZ77 y Huffman . El propósito de DEFLATE era reemplazar LZW y otros algoritmos de compresión de datos protegidos por patente, porque estos algoritmos limitaban la disponibilidad de compresión y otros archivadores populares en ese momento (Wikipedia).
Usualmente usamos el tar -czfcomando para empaquetar y comprimir la operación, el parámetro z es la forma de usar la compresión gzip. El estándar DEFLATE (RFC1951) es un estándar de compresión de datos sin pérdidas ampliamente utilizado. Su formato de datos comprimidos está compuesto por una serie de bloques, correspondientes al bloque de datos de entrada, cada bloque es comprimido por LZ77 (basado en la compresión del diccionario, es decir, la letra con mayor probabilidad se expresa en el código más corto) algoritmo y Huffman Se busca el algoritmo LZ77 y se reemplaza la cadena de caracteres repetida para reducir el volumen de datos.
formato de archivo
-
Un encabezado de 10 bytes contiene un número mágico (1f 8b), un método de compresión (como 08 para DEFLATE), indicadores de encabezado de 1 byte, marca de tiempo de 4 bytes, indicadores de compresión e ID del sistema operativo.
-
Encabezados adicionales opcionales, incluido el nombre del archivo original, el campo de comentario, el campo "extra" y la mitad inferior de la suma de comprobación CRC-32 del encabezado.
-
DESINFLAR comprime el cuerpo.
-
Pie de página de 8 bytes, incluida la verificación CRC-32 y los datos originales sin comprimir.
Podemos ver que gzip se basa principalmente en el algoritmo DEFLATE de CRC y Huffman LZ77, que también es el objetivo de optimización de la biblioteca ISA-L más adelante.
Brotley
Alakuijala y Szabadka completaron la especificación Brotli en 2013-2016. Este formato de datos tiene como objetivo mejorar aún más la relación de compresión. Tiene una gran cantidad de aplicaciones para optimizar la velocidad del sitio web. Mark Adler implementó de forma independiente la verificación formal de la especificación Brotli. Brotli es una especificación de formato de datos para la compresión del flujo de datos, que utiliza una combinación específica del algoritmo de compresión sin pérdidas LZ77 general, la codificación de Huffman y el modelado de contexto de segundo orden. Puede consultar este documento para ver su principio de implementación.
Por las características del lenguaje en sí, el método de modelado basado en contexto (Context Modeling) puede obtener una mejor relación de compresión, pero es difícil de popularizar debido a sus problemas de rendimiento. Actualmente existen dos algoritmos de avance populares:
-
RESPUESTA: Zstd, lzfse
-
Modelado de contexto: Brotli, bz2
Consulte a continuación los datos de prueba específicos.
Zstd
Zstd nombre completo Zstandard, es un proveedor de algoritmo de compresión rápida de alta compresión que el principal logro del lenguaje de programación C, es Yann Collet de Facebook lanzado en 2016, Zstd utiliza codificador de entropía de estado finito (Entropía de estado finito, abreviado como FSE). Este codificador es un nuevo tipo de codificador de entropía desarrollado por Jarek Duda basado en la teoría ANS , que proporciona una solución de compromiso de velocidad de compresión / relación de compresión muy potente (de hecho, logra tanto "pez" como "pata de oso"). Zstd proporciona relaciones de compresión cercanas a lzma, lzham y ppmx en su nivel máximo de compresión, y su rendimiento es mejor que lza o bzip2. Zstandard logra la frontera de Pareto (el estado ideal para la asignación óptima de recursos) porque se descomprime más rápido que cualquier otro algoritmo disponible actualmente, pero la relación de compresión es similar o mejor.
Para datos pequeños, también proporciona un método para cargar un diccionario preestablecido para optimizar la velocidad El diccionario se puede generar entrenando los datos de destino.
Comparación de datos de referencia oficial
El nivel de compresión se puede especificar mediante --fast, que proporciona una velocidad de compresión y descompresión más rápida. En comparación con el nivel 1, provocará cierta pérdida de relación de compresión, como se muestra en la tabla anterior. Zstd puede cambiar la velocidad de compresión por una relación de compresión más fuerte. Es un pequeño incremento configurable. Bajo todas las configuraciones, la velocidad de descompresión sigue siendo la misma. Esta es una característica compartida por la mayoría de los algoritmos de compresión LZ (como zlib o lzma).
-
Usamos los parámetros predeterminados de Zstd para las pruebas, y el tiempo de compresión fue de 8.471 s, solo el 11.266% del original, un aumento del 88.733%.
-
El tiempo de descompresión de 3.211 es solo el 29.83% del original, un aumento de aproximadamente 70.169%.
-
Al mismo tiempo, la tasa de compresión también se ha incrementado de 2.548 a 2.621.
LZ4
LZ4 es un algoritmo de compresión sin pérdidas que proporciona una velocidad de compresión superior a 500 MB / s (superior a 0,15 Bytes / ciclo) por núcleo. Se caracteriza por una velocidad de decodificación extremadamente rápida, con una velocidad de varios GB / s por núcleo (aproximadamente 1 Bytes / ciclo).
De la comparación de referencia de Zstd anterior, podemos ver que el algoritmo LZ4 es muy efectivo, por lo que también comparamos LZ4. LZ4 se enfoca más en la velocidad de compresión y descompresión, especialmente la velocidad de descompresión. La relación de compresión no es su punto fuerte Los parámetros de compresión 1-9 son compatibles de forma predeterminada y los probamos por separado.
LZ4 usa los parámetros predeterminados para comprimir la velocidad muy bien, mucho más rápido que Zstd, pero la relación de compresión no es alta, 206 MB más que Zstd después de la compresión, un 46% total, lo que significa más tiempo de transmisión de datos y espacio en disco ocupado. Incluso la relación de compresión máxima no es alta, solo aumentó de 1,79 a 2,11, pero el tiempo que consume ha aumentado de 5 a 51 segundos. En comparación, LZ4 no es la mejor solución en términos de tasa de compresión. Básicamente, la ventaja de tiempo de la tasa de compresión de nivel 2.x básicamente se ha ido, y hay otro punto en el que LZ4 actualmente no admite oficialmente la compresión paralela de CPU de varios núcleos. ., Entonces, en la comparación de seguimiento, LZ4 pierde la ventaja de la velocidad de compresión y descompresión.
Pigz
Mark Adler, el autor de Pigz, también es coautor del zip y unzip de Info-ZIP, las bibliotecas de compresión gzip y zlib de GNU, y participa en el desarrollo del formato de imagen PNG.
Pigz es la abreviatura de implementación paralela de gzip, y su idea principal es utilizar múltiples procesadores y núcleos. Divide la entrada en bloques de 128 KB y cada bloque se comprime en paralelo. El valor de control único de cada bloque también se calcula en paralelo. Su implementación utiliza directamente las bibliotecas zlib y pthread, que es relativamente fácil de leer, y es importante que sea compatible con el formato gzip. Pigz usa un hilo (el hilo principal) para la descompresión, pero se pueden crear otros tres hilos para leer, escribir y verificar cálculos, por lo que la descompresión se puede acelerar en algunos casos.
Cuando algunos blogs prueban el rendimiento de compresión de Pigz en una plataforma de PC doméstica como i7 4790K, la velocidad no es muy alta, pero la mejora es mucho más evidente en los datos verificados por nuestra máquina real. A través de las pruebas, su velocidad de ejecución del tiempo de compresión es de solo 1.768s, lo que da un juego completo al rendimiento de la máquina física de nuestra plataforma. El tiempo de usuario (la suma del tiempo de CPU) usa un total de 1m30.569s, que es el mismo que el anterior. método gzip de un solo subproceso La velocidad es casi un nivel. La relación de compresión 2.5488 y el uso normal son tar -czfcasi similares.
Versión de aceleración ISA-L
ISA-L es un conjunto de bibliotecas de funciones de código abierto que aceleran la ejecución de algoritmos sobre la arquitectura IA, con el propósito de resolver los requisitos informáticos del sistema de almacenamiento. ISA-L utiliza la licencia BSD-3-Clause , por lo que también se puede utilizar comercialmente.
Si ha utilizado SPDK (Storage Performance Development Kit) o DPDK (Data Plane Development Kit), debería haber oído hablar de ISA-L. El primero usa la parte CRC de ISA-L y el segundo usa su optimización de compresión. ISA-L utiliza instrucciones SIMD (instrucción única, datos múltiples) eficientes e instrucciones dedicadas para maximizar el uso de la microarquitectura de la CPU para acelerar el proceso de cálculo de los algoritmos de almacenamiento. Las funciones subyacentes de ISA-L están escritas en código de ensamblaje manual y sintonizadas en muchos detalles (ahora consideremos a menudo la plataforma ARM, algunas de las instrucciones mencionadas en este artículo no son altamente compatibles o incluso no son compatibles con esta plataforma).
ISA-L optimiza principalmente la codificación CRC, DEFLATE y Huffman para el algoritmo de compresión.Los datos oficiales señalan que ISA-L es 5 veces más rápido que zlib-1.
Por ejemplo, muchos software de código abierto de almacenamiento de bajo nivel implementan el CRC que utiliza el método de tabla de búsqueda. Se almacena o genera una tabla de valor de CRC en el código, y luego se consulta el valor durante el cálculo. El código de ensamblaje de ISA-L no contiene ninguna. La instrucción de multiplicación de acarreo PCLMULQDQ realiza una multiplicación sin acarreo en dos números de 64 bits para maximizar el rendimiento de la instrucción intel PCLMULQDQ para optimizar el rendimiento de CRC. En una mejor situación, si la CPU admite AVX-512, puede usar otros conjuntos de instrucciones optimizados como VPCLMULQDQ (PCLMULQDQ se implementa en la versión de 512 bits de la codificación EVEX) (consulte el "Apéndice" al final del artículo para cómo comprobar si es compatible).
utilizar
El nivel de optimización de compresión implementado por ISA-L admite [0,3]. 3 es la versión con la relación de compresión más grande. Teniendo en cuenta que hemos adoptado la relación de compresión más grande, aunque la relación de compresión de 2.346 es ligeramente menor que gzip, tiene poco efecto. En la versión v2.27 lanzada en junio de 2019, ISA-L agregó una característica de subprocesos múltiples, por lo que en pruebas posteriores, adoptamos el parámetro de concurrencia de subprocesos múltiples y el efecto se mejoró significativamente.
Dado que el sistema que construimos la máquina para Centos7 necesita compilar las dependencias ISA-L, como nasm y otras bibliotecas, la instalación y configuración será más complicada. ISA-L soporta múltiples parámetros de optimización como IGZIP_HIST_SIZE (agrandar la ventana deslizante durante la compresión)), LONGER_HUFFTABLES, una tabla de codificación Huffman más grande, estos parámetros de compilación también mejorarán en gran medida la biblioteca.
Tiempo de compresión
real 0m1.372s
user 0m5.512s
sys 0m1.791sEl efecto después de la prueba es bastante sorprendente, es el más rápido en el esquema de comparación actual, ahorrando un 98.09% en el tiempo.
Dado que el formato gzip y es compatible, por lo que puede usar el mismo tar -xfcomando para descomprimir el proceso de prueba de descompresión posterior, todavía lo usamos para aliviar el estrés que proporciona ISA-L.
Pzstd
A través de la prueba de Pigz, nos preguntamos si un algoritmo excelente como Zstd también puede soportar el paralelismo En el Repo oficial, nos sorprendió encontrar un "tesoro".
Pzstd es una versión paralela de Zstandard implementada en C ++ 11 (Zstd también agregó soporte para múltiples subprocesos después de esto), similar a las herramientas de Pigz. Proporciona funciones de compresión y descompresión compatibles con el formato Zstandard y puede utilizar varios núcleos de CPU. Divide la entrada en bloques de igual tamaño y comprime cada bloque de forma independiente en marcos Zstandard. Luego, estos marcos se unen para producir la salida comprimida final. Pzstd también admite la descompresión paralela de archivos. Al descomprimir archivos comprimidos con Zstandard, PZstandard realiza IO en un hilo y lo descomprime en otro hilo.
La siguiente figura es una comparación de la velocidad de compresión y descompresión de Pigz, del repositorio oficial de Github (configuración de la máquina: Intel Core i7 @ 3.1 GHz, 4 subprocesos), el efecto es incluso mejor que Pigz, los datos de comparación específicos se ven a continuación:
Pied Piper Compresión de salida media）
La compresión Middle-out fue originalmente un concepto mencionado en los dramas estadounidenses, pero ahora hay una implementación real de middle-out . El algoritmo se utiliza actualmente en un pequeño rango de datos de series de tiempo comprimidos. Debido a la falta de datos y apoyo teórico maduro En comparación, no hay una evaluación comparativa oficial en el plan.
Nota: Pied Piper es una empresa virtual y un algoritmo del drama estadounidense "Silicon Valley".
compatibilidad
Todos los esquemas de comparación mencionados en la encuesta de este artículo se prueban en las máquinas del grupo de construcción. Dado que la configuración del grupo de máquinas en el sistema de construcción es muy uniforme (incluida la plataforma de hardware y la versión del sistema), el rendimiento de compatibilidad y los datos de prueba son También muy consistente.
Selección
De hecho, la configuración de algunas máquinas de prueba oficiales no es coherente con la configuración de la máquina física de la plataforma de compilación Meituan, y los escenarios también pueden ser diferentes. La arquitectura de la CPU y la plataforma y el entorno de compilación utilizados en los resultados de las pruebas citados anteriormente también son algo diferente de lo que usamos. Y la mayor parte del hardware es de uso doméstico, como i7-4790K o i9-9900K. Es por eso que necesitamos usar la máquina física de la plataforma de compilación y el escenario de compresión del paquete de compilación específico para las pruebas, porque en de esta manera podemos obtener los datos más cercanos a nuestro escenario de uso.
Datos comparativos
La comparación de datos de varios programas es la siguiente (la selección de datos de tiempo en este artículo es para seleccionar la mediana de los resultados después de múltiples ejecuciones):
Comparación del tiempo de compresión
A partir del diagrama de visualización de tiempo del paquete de compilación comprimido después de la compilación completa, se puede ver que la versión inicial de la compresión gzip consume bastante tiempo, y Pzstd es la solución más rápida, ISA-L es un poco más lenta y Pigz es más lento, los tres. Puede lograr una optimización de 1m11s a 1s, y el tiempo de compresión más rápido se puede ahorrar en un 98.51% .
Comparación del tiempo de descompresión
El tiempo de descompresión no difiere tanto como la eficiencia de compresión.Cuando la relación de compresión está en el rango de 2.5-2.6 en proyectos de nivel de GB, el tiempo está dentro de los 11 segundos. Y para lograr la máxima compatibilidad con la estabilidad existente y mantener, descomprima la opción preferida de la estrategia de formato compatible con gzip, de modo que la máquina de destino de implementación menos intrusiva, que puede utilizar las tar -xfprioridades del programa de descompresión.
En la implementación posterior del programa, debido a que la implementación requiere un entorno estable y confiable, no hemos modificado el entorno de la máquina de implementación por el momento.
La siguiente comparación de tiempo es la comparación del uso de sus respectivas soluciones de descompresión:
-
Pzstd tiene la velocidad de descompresión más rápida y ahorra un 86,241% de tiempo en comparación con Gzip.
-
La eficiencia de descompresión del algoritmo Zstd es la segunda, lo que puede ahorrar alrededor del 70,169% del tiempo de descompresión.
-
ISA-L puede ahorrar un 61,9658% del tiempo.
-
Pigz puede ahorrar un 43,357% del tiempo de descompresión.
-
La descompresión de Brotli puede ahorrar un 29,02% del tiempo.
Comparación de la relación de compresión
En la comparación de la relación de compresión, Zstd y Pzstd tienen algunas ventajas, entre las que Brotli y LZ4 son difíciles de probar la velocidad al mismo nivel de relación de compresión debido a la limitación de los parámetros admitidos, por lo que se selecciona un parámetro de relación de compresión ligeramente menor. , pero la eficiencia aún está lejos de Pigz y Pzstd. Hay algunas lagunas.
La implementación de ISA-L tiene algunos sacrificios en la relación de compresión, pero no existe una gran brecha.
Resumen del análisis de pros y contras
Al comienzo de este artículo, presentamos el proceso de construcción e implementación, por lo que la fórmula de cálculo aproximada para nuestro tiempo objetivo de optimización es la siguiente:
En la comparación de casos de prueba, el orden de consumo de tiempo es Pzstd <ISA-L <Pigz <LZ4 <Zstd <Brotli <Gzip (cuanto más alta sea la clasificación, mejor), y el tiempo dedicado a la compresión y descompresión representa el total comparación que requiere mucho tiempo Grande, por lo que las estrategias alternativas son Pzstd, ISA-L, Pigz.
Por supuesto, también existe el problema de la optimización de costos del espacio en disco. Es decir, la relación de compresión puede optimizar el espacio en disco, pero optimizará negativamente la construcción que consume tiempo. Sin embargo, debido a que la dimensión de tiempo actual es nuestro principal objetivo de optimización , es más caro que el costo del disco. El costo del ancho de banda de carga es importante, por lo que la relación de compresión adopta un esquema de relación de compresión óptimo más común o predeterminado, que está en el rango de 2,3-2,6. Sin embargo, en algunos escenarios donde el costo de los medios de almacenamiento, como las bases de datos en memoria, es relativamente alto, es posible que se requieran más consideraciones para integrar varios aspectos.
Estrategia de puntuación
En comparación con gzip, el nuevo algoritmo tiene la velocidad deseada, pero debido a la incompatibilidad directa del formato de compresión y la necesidad de soporte del cliente (máquina de destino de implementación), el ciclo de implementación de la solución puede ser más largo.
Para la implementación, los beneficios pueden no ser muy obvios, pero aumentan algunos costos de mantenimiento y operación, por lo que no hemos dado mayor prioridad a la solución Pzstd por el momento.
La estrategia de selección se basa principalmente en los siguientes principios:
-
La optimización general que lleva mucho tiempo es la que más mejora, que también es el punto de partida del plan de optimización general.
-
Para asegurar la máxima compatibilidad, con el fin de reducir el costo de cambios en los servicios y plataformas que acceden a la plataforma de construcción, es necesario mantener la compatibilidad de la solución (se prioriza la estrategia más compatible, es decir, la solución compatible con gzip es privilegiado).
-
Para garantizar la estabilidad y confiabilidad del entorno de la máquina de destino de implementación, elija la solución menos intrusiva para la máquina de implementación, de modo que no sea necesario instalar el cliente o la biblioteca.
-
La escena de compresión en la prueba de simulación de máquina real encaja completamente con la escena de la plataforma de construcción Meituan, es decir, la comparación de datos entre nuestra plataforma de máquina física existente y la escena de compresión objetivo tiene un buen efecto.
-
De hecho, el ángulo de puntuación más completo de esta pregunta tiene muchas dimensiones, como el costo en disco del almacenamiento de objetos, el costo del ancho de banda, la tarea que consume mucho tiempo e incluso el costo de la máquina. Sin embargo, para simplificar la selección de la solución general, hemos omitido algunos cálculos y la relación de compresión. Los respectivos rangos oficiales recomendados también fueron seleccionados para comparar.
Con base en los puntos anteriores, se decide adoptar el método ISA-L para acelerar la primera fase, lo que puede mejorar la eficiencia de la construcción de la plataforma de manera más estable y a mayor velocidad. El plan Pzstd puede implementarse en el futuro. Los siguientes datos son el resultado de la primera fase.
Efecto de optimización
Para facilitar la visualización de los resultados, filtramos algunos de los elementos de lanzamiento con un tiempo de empaque prolongado (estos elementos de consumo prolongado a menudo afectan en gran medida la experiencia del usuario, y la proporción general es de aproximadamente el 10%), esta parte del la tarea está optimizada El tiempo varía de 27s a 72s. En el pasado, cuanto más grande era el proyecto, mayor era el tiempo de compresión. Ahora el tiempo de compresión se puede estabilizar en 10s, y es cuando nuestra máquina realiza múltiples tareas al mismo tiempo.
Luego resumimos parte de los datos de empaque antes de la optimización (compresión + carga), y parte de los datos optimizados, y obtuvimos una comparación del efecto de optimización promedio. Los datos son los siguientes:
-
En nuestras estadísticas anteriores de paquetes de compilación, la mayoría de los paquetes de compilación tienen alrededor de 100 MB después de la compresión y alrededor de 250 MB antes de la compresión. Según el algoritmo gzip, la velocidad de compresión será de alrededor de 10 segundos.
-
Dado que la máquina física construida puede ejecutar varias tareas al mismo tiempo, el efecto de compresión real tardará un poco más que la prueba.
La compresión ahorra una media del 90% del tiempo.
Escribir en la parte de atrás
-
Dado que algunas de las soluciones mencionadas en el artículo involucran el conjunto de instrucciones de la CPU del entorno de plataforma específico, e incluso el entorno de compilación de la biblioteca, los parámetros de compilación también afectarán los efectos específicos, por lo que se recomienda mantener un entorno de clúster unificado durante la implementación del plan, o puede ser un entorno de clúster. Realice una optimización de personalización especial.
-
Al empaquetar archivos RPM para Centos, debe prestar especial atención a la configuración del entorno de compilación, de lo contrario, los efectos y las pruebas pueden diferir.
-
El paquete Jar de Java y el paquete War también pueden estar comprimidos.Para este tipo de escenario, la tasa de compresión no mejora mucho, pero la velocidad sigue mejorando.
Sobre el Autor
Hongda, ingeniero de I + D del Departamento de Tecnología Básica de Meituan.
Perfil del equipo
Departamento de Tecnología Básica - Departamento de Calidad y Eficiencia de I + D - Equipo de Almacén y Construcción de Código . El equipo tiene como objetivo desarrollar capacidades de construcción de código, colaboración y gestión de almacén de código, mejorar el motor de ejecución de flujo de trabajo multidimensional y construir una cadena de herramientas, y conectarse con otras herramientas de I + D de la empresa Mejorar el desarrollo comercial general y la eficiencia de la entrega.
apéndice
Entorno de la máquina
Las pruebas de este artículo se llevan a cabo en las siguientes máquinas físicas y se utilizan los mismos archivos de destino en las pruebas. La
máquina de prueba utiliza discos SSD que no son PCIE.
inxi -Fx 省略部分数据输出如下，其中一些并行指令集在优化中可能会使用到。其中 flags 中可以看到支持 avx avx2 指令集，并不支持 avx-512 ，不过仍然有很大性能提升。
System: Host: ****** Kernel: ****** bits: 64 compiler: gcc v: 4.8.5 Console: tty 7 Distro: CentOS Linux release 7.1.1503 (Core)
CPU: Info: 2x 16-Core model: Intel Xeon Gold 5218 bits: 64 type: MT MCP SMP arch: Cascade Lake rev: 7 L2 cache: 44.0 MiB
flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 293978 Speed: 2300 MHz min/max: N/A
Info: Processes: 764 Memory: 187.19 GiB used: 15.05 GiB (8.0%) Init: systemd runlevel: 3 Compilers: gcc: 4.8.5
/proc/cpuinfo 文件中也可以查看 CPU 支持的指令集
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb cat_l3 cdp_l3 intel_ppin intel_pt ssbd mba ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm mpx rdt_a avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts pku ospke spec_ctrl intel_stibp flush_l1d arch_capabilitiesreferencias
-
https://engineering.fb.com/core-data/smaller-and-faster-data-compression-with-zstandard/
-
https://peazip.github.io/fast-compression-benchmark-brotli-zstandard.html
-
http://fastcompression.blogspot.com/2013/12/finite-state-entropy-new-breed-of.html
-
https://cran.r-project.org/web/packages/brotli/vignettes/brotli-2015-09-22.pdf
-
https://01.org/sites/default/files/documentation/isa-l_api_2.28.0.pdf
---------- FIN ----------
Ofertas de trabajo
El equipo de la plataforma de I + D del Departamento de Calidad y Eficiencia de I + D de Meituan está comprometido con la construcción de una plataforma de entrega continua de primera clase en la industria. Ahora está contratando ingenieros en múltiples direcciones, como biblioteca de productos, almacén de códigos, lanzamiento de servicios, línea de ensamblaje, etc. coordinado en Beijing / Shanghai. ¡Los estudiantes interesados son bienvenidos a unirse! El currículum se puede enviar a: [email protected] (indique el asunto del correo electrónico: Departamento de Calidad y Eficiencia de I + D de Meituan-Plataforma de I + D)
Tal vez todavía quieras mirar
| Análisis de tecnología de motor informático de centro de datos de billones de OCTO de Meituan