☰

Alta utilización de %sys en el nodo de caché de Nginx

tag-icon • tag-icon nginx cache linux-kernel lua
Alta utilización de %sys en el nodo de caché de Nginx

Configuramos Nginx con Lua (paquete openresty) para que sea un nodo de almacenamiento en caché local para nuestro servidor de intercambio de archivos, separamos los archivos en fragmentos de "50 MB cada uno" (porestemétodo) y almacenarlos en caché para aumentar su eficiencia. Con poco tráfico, funciona bien, pero con el aumento de los archivos almacenados en caché y la carga (aunque no sea realmente alto), el caché dejará de responder debido a >80% de compras del sistema la mayor parte del tiempo. Entonces, ¿qué podría ser un asesino del rendimiento en tal situación?

aunque experimentamos ajustando varios parámetros (es decir, niveles de directorio de almacenamiento en caché, parámetros RAID), pero todavía no di la solución óptima

PD. los síntomas comienzan después de solo 10000 archivos en caché con ~300 conexiones en el servidor

Especificaciones del servidor de caché

    1xCPU 2.5 Ghz 12 Cores
    128GB RAM
    10x500GB Samsung SSD RAID0 (128KB chuck s) storage
    linux Os -CentOS 6.6 64bit 
    File system ext4 4k block

Configuración de Nginx

 worker_processes  auto;

events {

    use epoll;
    worker_connections 1024;
    multi_accept on;
 }


http {
    include       /usr/local/openresty/nginx/conf/mime.types;

    proxy_cache_path  /mnt/cache/ levels=2:2:2 keys_zone=default:1000m loader_threshold=100 loader_files=2000
                     loader_sleep=10 inactive=1y max_size=3500000m;
    proxy_temp_path /mnt/temp2 2 2;
    client_body_temp_path /mnt/temp 2 2;
    limit_conn_zone $remote_addr$uri zone=addr:100m;

    map $request_method $disable_cache {
      HEAD  1;
      default   0;
    }

    lua_package_path "/opt/ranger/external/lua-resty-http/lib/?.lua;/opt/ranger/external/nginx_log_by_lua/?.lua;/opt/ranger/external/bitset/lib/?.lua;;";

    lua_shared_dict file_dict  50M;
    lua_shared_dict log_dict   100M;
    lua_shared_dict cache_dict 100M;
    lua_shared_dict chunk_dict 100M;


    proxy_read_timeout 20s;
    proxy_send_timeout 25s;
    reset_timedout_connection on;

    init_by_lua_file '/opt/ranger/init.lua';

    # Server that has the lua code and will be accessed by clients
    server {
      listen       80 default;
      server_name  _;
      server_name_in_redirect off;

      set $ranger_cache_status $upstream_cache_status;

      lua_check_client_abort on;
      lua_code_cache on;

      resolver ----;
      server_tokens off;
      resolver_timeout 1s;

      location / {
        try_files $uri $uri/ index.html;
      }

      location  ~* ^/download/ {
        lua_http10_buffering off;
        content_by_lua_file '/opt/ranger/content.lua';
        log_by_lua_file '/opt/ranger/log.lua';
        limit_conn addr 2;
      } 
    }

    # Server that works as a backend to the lua code
    server {
      listen 8080;

      server_tokens off;
      resolver_timeout 1s;

      location  ~* ^/download/(.*?)/(.*?)/(.*) {
        set $download_uri  $3;
        set $download_host $2;
        set $download_url http://$download_host/$download_uri?$args;
        proxy_no_cache $disable_cache;
        proxy_cache_valid 200 1y;
        proxy_cache_valid 206 1y;
        proxy_cache_key "$scheme$proxy_host$uri$http_range"; 
        proxy_cache_use_stale error timeout http_502;
        proxy_cache default; 
        proxy_cache_min_uses 1;

        proxy_pass $download_url;
      }
    }
}

Respuesta1

Gracias @myaut por la orientación, busqué _spin_lock_irqsave y resultó que estaba relacionado con el kernel en sí y no con Nginx.

De acuerdo conesteartículo, el problema se puede solucionar desactivando la función RedHat Transparent Huge Page que solucionó el problema.

echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled

información relacionada