High %sys utilization in Nginx cache node

Question

We set up Nginx with Lua (openresty bundle) to be a local caching node to our file sharing server, we seperated files to chunks "50MB each" (by this method) and store them in cache to increase its efficiency. In low traffic it works fine but with the increase of cached files and load (even though its not really high) the cache will become unresponsive due to >80% sys buys most of the time. so what could be a preformance killer in such situation

although we experimented tuning several parameters (i.e caching directory levels,RAID parameters) but i didnt give the optimal solution yet

Ps. the symptoms starts after only 10000 files in cache with ~300 connection/s on the server

Cache server Specs

    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

Nginx conf

 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;
      }
    }
}

Use `perf record -a` to profile kernel and `perf report` to gather results after that — myaut, Mar 03 '15 at 18:16
thanks for the suggestion, these are the top 3 from the result 75.50% [kernel] [k] _spin_lock_irqsave 25.15% libc-2.12.so [.] memcpy 12.00% [kernel] [k] compaction_alloc — Ali Alnakeab, Mar 03 '15 at 19:28
`_spin_lock_irqsave` may be called from many places since spinlocks are popular in kernel. Try to collect with callchain data: `perf record -a -g` and in `perf report` press `E` so it'll show entire chain for this function. — myaut, Mar 03 '15 at 21:02

score 1 · Accepted Answer · answered Mar 04 '15 at 08:07

1

thanks @myaut for the guidance, i looked up the _spin_lock_irqsave and it turned out to be related to the kernel itself and not Nginx.

Acording to this article, the problem can be fixed by disabling RedHat Transparent Huge Page feature which fixed the problem.

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

answered Mar 04 '15 at 08:07

Ali Alnakeab

11
2

If `THP` is causing issues that most likely means that you are doing too many `memcpy`/`memmove` operations (you have those in your `perf report`). That is probably because of your lua scripts. To further improve performance of the server you can try minimizing number of memory copies in your code. – SaveTheRbtz Mar 05 '15 at 02:32

High %sys utilization in Nginx cache node

1 Answers1