min_allocation_size_to_log_stack_trace
Tamaño mínimo, en bytes, de un cargo individual al rastreador de memoria global (de todo el servidor) a partir del cual se captura un stack trace, se escribe en el log del servidor con nivelWarning y se inserta en system.trace_log con el tipo de traza MemoryLargeAllocation.
El tamaño que se compara con el umbral, y que se reporta, es el que carga una llamada al tracker, que no corresponde necesariamente a una sola asignación: un thread difiere sus asignaciones pequeñas y las vuelca (flush) como un único cargo, por lo que el tamaño reportado puede superar a la asignación situada en la cima de la pila reportada hasta en max_untracked_memory. Mantener el umbral muy por encima de max_untracked_memory hace que esa diferencia sea irrelevante.
Se trata de un diagnóstico para un total global registrado que ha crecido muy por encima del uso de memoria real del proceso. En ese estado, el servidor rechaza todas las asignaciones, incluso las de cero bytes, mientras utiliza solo una fracción de su límite, y la telemetría ordinaria no permite atribuir el incremento: las asignaciones cargadas bajo un MemoryTrackerBlockerInThread omiten la comprobación del límite y las trazas que la acompañan, y las inserciones en system.trace_log que transportarían el resto fallan una vez que el servidor está bloqueado. El log del servidor se sigue escribiendo, de modo que el stack trace sí llega hasta él.
Se capturan como máximo 10 trazas por ejecución del servidor, ya que capturar y simbolizar una pila es costoso y el trigger tiende a repetirse. Cambiar esta configuración en tiempo de ejecución, en cualquier sentido, no eleva ese límite.
Requiere que trace_log esté configurado. Sin un colector de trazas en ejecución, el valor se ignora y se reporta como 0 en system.server_settings, dado que la traza solo podría capturarse y descartarse. Una traza que el colector procese antes de que esa tabla esté attached, lo que ocurre en una fase tardía del arranque, llega únicamente al log del servidor.
Un valor de 0 (predeterminado) desactiva el diagnóstico. Configúrelo muy por encima de la mayor asignación que el servidor realice legítimamente; de lo contrario, también se registrarán asignaciones grandes ordinarias y el arranque puede consumir todo el presupuesto.
min_allocation_size_to_throw_on_memory_limit
Tamaño mínimo, en bytes, de una asignación genérica de C++ (del tipo que realizan los contenedores estándar, las cadenas, el crecimiento destd::vector, los punteros inteligentes, etc.) que puede provocar MEMORY_LIMIT_EXCEEDED una vez alcanzado max_server_memory_usage. Las asignaciones genéricas más pequeñas se siguen contabilizando en el rastreador de memoria, pero se permite que se completen incluso después de superar el límite, lo que reduce fallos espurios durante las rutas de limpieza y manejo de excepciones cerca de OOM.
Las asignaciones realizadas por los propios búferes grandes de ClickHouse — datos de columna, hash tables, arenas, canalizaciones de consulta, búferes de E/S — siempre respetan el límite de memoria y pueden lanzar una excepción independientemente de este valor. Esta configuración solo afecta a las asignaciones implícitas que pasan por operator new.
Un valor de 0 (predeterminado) conserva el comportamiento heredado: las asignaciones implícitas de operator new nunca son rechazadas por el rastreador de memoria, y solo las asignaciones explícitas de ClickHouse pueden provocar MEMORY_LIMIT_EXCEEDED.
Ten en cuenta que, para evitar efectos secundarios, se recomienda establecer un valor mayor que max_untracked_memory.
min_os_cpu_wait_time_ratio_to_drop_connection
Proporción mínima entre los tiempos de espera de la CPU del SO (métricaOSCPUWaitMicroseconds) y de actividad (métrica OSCPUVirtualTimeMicroseconds) a partir de la cual se considera cerrar conexiones. Se utiliza interpolación lineal entre la proporción mínima y la máxima para calcular la probabilidad; en este punto, la probabilidad es 0.
Consulta Control del comportamiento ante sobrecarga de CPU del servidor para obtener más detalles.