0

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;
      }
    }
}
3
  • 1
    Use perf record -a to profile kernel and perf report to gather results after that
    – myaut
    Mar 3, 2015 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 Mar 3, 2015 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 3, 2015 at 21:02

1 Answer 1

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
1
  • 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. Mar 5, 2015 at 2:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .