
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