SO
En general, no es necesario ajustar demasiado los parámetros del kernel y del SO para el clúster de Kafka que se ejecuta en Linux, pero se pueden hacer referencia a las siguientes situaciones de acuerdo con la situación específica:
Descriptor de archivo (fd): se puede hacer referencia al límite de fd en el nodo del intermediario (número_de_particiones) * (tamaño_de_partición / tamaño_del_segmento) fórmula
búfer de socket (búfer de socket): este parámetro puede aumentar la transmisión de datos entre múltiples centros de datos (generalmente clústeres remotos) Se recomienda ajustar la copia de seguridad para aumentar el rendimiento.)
Número máximo de área de asignación de memoria (vm.max_map_count): cuando el nodo del agente de kafka tiene demasiadas particiones, debe prestar mucha atención a este parámetro a nivel del sistema. El valor predeterminado es 65535 . Cada segmento de registro, partición asignada, requiere un par de archivos de índice / índice de tiempo, y cada archivo consume un área de memoria (un segmento de registro usa 2 áreas mapeadas en memoria), por lo que una partición requiere al menos 2 áreas de memoria, una Cuando el corredor tiene 50.000 particiones, consumirá 100.000 áreas de memoria En este momento, los parámetros predeterminados harán que el corredor se bloquee con OutOfMemoryError.
Nota: La cantidad de segmentos de registro por partición depende del tamaño del segmento, la carga y la estrategia de retención.
Kafka utiliza una gran cantidad de archivos y sockets para comunicarse con los clientes. Todos sabemos que bajo Linux, todo es un archivo, por lo que el sistema necesita establecer más descriptores de archivos disponibles>.
En la mayor parte de la configuración predeterminada del sistema, un solo proceso puede usar 1024 descriptores de archivo, que es demasiado pequeño para Kafka. Se recomienda ajustarlo a al menos 100,000, pero generalmente está relacionado con el sistema operativo y la versión de lanzamiento, y debe realizarse de acuerdo con el ajuste de sistema operativo específico.
El número de mmap actual se puede calcular calculando el archivo .index en el directorio de datos de Kafka. La mayoría de los archivos .index representan archivos asignados en memoria.
1. Cuente el número de archivos .index
$ find . -name '*index' | wc -l
2. Establezca el parámetro vm.max_map_count para cada sesión, que calculará el número de archivos asignados en la memoria actual. El valor mínimo del límite de mmap es el límite ulimit de archivos abiertos.
Este valor es mucho mayor que el número de índices
$ sysctl -w vm.max_map_count=262144
3. Parámetros de mmap persistentes
$ echo 'vm.max_map_count=262144' >> /etc/sysctl.conf
$ sysctl -p
La Internet
La baja latencia garantiza que los nodos se puedan comunicar fácilmente, mientras que un ancho de banda alto facilita el movimiento y la recuperación de copias anteriores de los nodos del clúster (a menudo, el punto de cuello de botella prioritario en los clústeres de Kafka es el ancho de banda).
La mayoría de los centros de datos actuales son básicamente redes Gigabit (1 GbE) o 10 Gigabit (10 GbE), lo que suele ser suficiente para la mayoría de los clústeres.
Debe intentar evitar los clústeres que abarcan varios centros de datos, incluso si los centros de datos están muy cerca de la misma área, evite los clústeres que abarquen grandes distancias geográficas.
Nota: De hecho, el particionamiento ocurrirá definitivamente en un sistema distribuido. Si se evita la implementación entre salas de máquinas, se puede reducir la probabilidad de particionado.
El clúster de Kafka asume que todos los nodos son iguales. Los retrasos más grandes pueden exacerbar los problemas en los sistemas distribuidos y dificultar la depuración y la solución.
Nota: Si la empresa necesita leer y escribir datos en diferentes lugares, el método recomendado es implementar un clúster Kafka local en cada centro de datos, y las instancias de la aplicación en cada centro de datos solo interactúan con sus clústeres locales y entre los clústeres Mirror (Kafka proporciona una herramienta para hacer espejos).
Sistema de archivos
En el sistema operativo actual, la mayoría de los sistemas deben usar el sistema Ext4 o XFS, el funcionario también recomienda el uso de estos dos sistemas de archivos, pero para la selección del sistema de archivos específico, el funcionario proporciona los siguientes escenarios y puntos a tener en cuenta.
Al utilizar varias opciones de creación y montaje de sistemas de archivos, y realizar pruebas comparativas en clústeres con una gran carga de mensajes, XFS ofrece una mejor hora local (la mejor configuración EXT4 es 160ms frente a 250ms +) y un tiempo de espera promedio más bajo. La variabilidad del rendimiento de XFS en términos de rendimiento del disco también es relativamente pequeña.
Independientemente del sistema de archivos utilizado, se recomienda modificar los parámetros de montaje predeterminados:
noatime: esta opción prohíbe actualizar el atributo atime (última hora de acceso) del archivo al leer el archivo, lo que puede eliminar muchas operaciones de escritura del sistema de archivos, especialmente en el caso de arrancar consumidores, Kafka no depende del atributo atime en todo, por lo que es seguro deshabilitarlo
$ cat /etc/fstab
UUID="4231b126-7e67-45c4-b8bf-554006291d35" /export1 xfs defaults,noatime 0 2
Optimización de parámetros de montaje del sistema de archivos XFS:
largeio: esto afectará el tamaño de E / S preferido informado por la llamada estadística. Aunque esto puede lograr un mayor rendimiento en escrituras de disco más grandes, en realidad tiene poco o ningún impacto en el rendimiento.
nobarrier: debido a que tiene respaldo de batería Dispositivo básico en caché, este La opción puede proporcionar un mayor rendimiento al deshabilitar la actualización de escritura periódica. Sin embargo, si el dispositivo básico se comporta bien, informará al sistema de archivos que no es necesario actualizarlo y esta opción no será válida.
Optimización de parámetros de montaje del sistema de archivos EXT:
Nota: Para obtener el mejor rendimiento en el sistema de archivos ext4, es necesario ajustar varios parámetros. Estas opciones generalmente no son seguras en condiciones de falla y causarán más pérdida y daño de datos. Para una falla de un solo agente, puede borrar el disco y reconstruir la copia desde el clúster. En la mayoría de los casos, una anomalía de múltiples intermediarios significa potencial El sistema de archivos está dañado y no se puede restaurar fácilmente.
data = writeback: Ext4 tiene como valor predeterminado data = order, lo que hace que ciertas operaciones de escritura tengan un orden fuerte. En escenarios de Kafka, este parámetro en realidad no es necesario. Esta configuración elimina la restricción de orden y parece reducir en gran medida la demora.
Desactivación del registro en diario: Registro es un compromiso: hace que el servidor se reinicie más rápido después de un bloqueo del servidor, pero introduce muchos bloqueos adicionales y aumenta la diferencia en el rendimiento de escritura
commit = num_secs: Esto ajusta la frecuencia de confirmaciones de ext4 en su registro de metadatos. Establecer este valor en un valor más bajo puede reducir la pérdida de datos no actualizados durante un bloqueo. Establecer este valor en un valor más alto aumentará el rendimiento.
nobh: esta configuración controla garantías de clasificación adicionales cuando se usa el modo data = writeback, que puede mejorar el rendimiento y la latencia.
delalloc: asignación retrasada significa que el sistema de archivos evita la asignación de bloques antes de que se produzcan las escrituras físicas. Esta función es muy adecuada para el rendimiento