服务器运行在高CPU使用率(100%)

我有一个数字海洋液滴上的nginx服务器,有2个CPU和4GB内存。

我正在运行一些小WP网站,没有太多的stream量,但似乎我可以毫不费力地将服务器推到100%的CPU。 我实际上只是垃圾邮件(1-2 /秒)硬刷新,服务器命中100%,并引发错误500。
我对服务器pipe理和Nginx来说还是很新的,所以我试图debugging到我所知道的最好的状态 – 而且我一直回到我的configuration不够好。

服务器信息:

  • 2个CPU
  • 4GB内存
  • CentOS 7
  • VestaCP
  • 纯Nginx
  • 仅运行WP站点

Nginx的conf:

# Server globals user nginx; worker_processes auto; worker_rlimit_nofile 65535; error_log /var/log/nginx/error.log crit; pid /var/run/nginx.pid; # Worker config events { worker_connections 1024; use epoll; multi_accept on; } http { # Main settings sendfile on; tcp_nopush on; tcp_nodelay on; client_header_timeout 3m; client_body_timeout 3m; send_timeout 3m; client_header_buffer_size 1k; client_body_buffer_size 128k; client_max_body_size 10m; output_buffers 1 32k; postpone_output 1460; large_client_header_buffers 4 4k; keepalive_timeout 30 30; reset_timedout_connection on; server_tokens off; server_name_in_redirect off; server_names_hash_max_size 512; server_names_hash_bucket_size 512; # Log format log_format main '$remote_addr - $remote_user [$time_local] $request ' '"$status" $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; log_format bytes '$body_bytes_sent'; #access_log /var/log/nginx/access.log main; access_log off; # Mime settings include /etc/nginx/mime.types; default_type application/octet-stream; # Compression gzip on; gzip_static on; gzip_comp_level 2; gzip_min_length 1000; gzip_buffers 8 64k; gzip_types text/plain text/css text/javascript text/js text/xml application/json application/javascript application/x-javascript application/xml application/xml+rss application/x-font-ttf image/svg+xml font/opentype; gzip_proxied any; gzip_disable "MSIE [1-6]\."; # Proxy settings proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass_header Set-Cookie; proxy_connect_timeout 90; proxy_send_timeout 90; proxy_read_timeout 90; proxy_buffers 32 4k; # Cloudflare https://www.cloudflare.com/ips set_real_ip_from 199.27.128.0/21; set_real_ip_from 173.245.48.0/20; set_real_ip_from 103.21.244.0/22; set_real_ip_from 103.22.200.0/22; set_real_ip_from 103.31.4.0/22; set_real_ip_from 141.101.64.0/18; set_real_ip_from 108.162.192.0/18; set_real_ip_from 190.93.240.0/20; set_real_ip_from 188.114.96.0/20; set_real_ip_from 197.234.240.0/22; set_real_ip_from 198.41.128.0/17; set_real_ip_from 162.158.0.0/15; set_real_ip_from 104.16.0.0/12; set_real_ip_from 172.64.0.0/13; #set_real_ip_from 2400:cb00::/32; #set_real_ip_from 2606:4700::/32; #set_real_ip_from 2803:f800::/32; #set_real_ip_from 2405:b500::/32; #set_real_ip_from 2405:8100::/32; real_ip_header CF-Connecting-IP; # SSL PCI Compliance ssl_session_cache shared:SSL:10m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4"; # Error pages error_page 403 /error/403.html; error_page 404 /error/404.html; error_page 502 503 504 /error/50x.html; # Cache settings proxy_cache_path /var/cache/nginx levels=2 keys_zone=cache:10m inactive=60m max_size=1024m; proxy_cache_key "$host$request_uri $cookie_user"; proxy_temp_path /var/cache/nginx/temp; proxy_ignore_headers Expires Cache-Control; proxy_cache_use_stale error timeout invalid_header http_502; proxy_cache_valid any 1d; # Cache bypass map $http_cookie $no_cache { default 0; ~SESS 1; ~wordpress_logged_in 1; } # File cache settings open_file_cache max=10000 inactive=20s; open_file_cache_valid 30s; open_file_cache_min_uses 5; open_file_cache_errors off; # Wildcard include include /etc/nginx/conf.d/*.conf; 

}


PHP-FPM:

 pm = ondemand pm.process_idle_timeout = 10s pm.max_children = 3 pm.start_servers = 2 pm.min_spare_servers = 2 pm.max_spare_servers = 2 pm.max_requests = 300 php_admin_value[memory_limit] = 256M env[HOSTNAME] = $HOSTNAME env[PATH] = /usr/local/bin:/usr/bin:/bin env[TMP] = /tmp env[TMPDIR] = /tmp env[TEMP] = /tmp 

热门截图 – imgur.com/a/n02VZ

Nginx错误日志中的最后一项

在php错误日志中的最后一项

问题

这不太可能是一个问题,但我们不知道,因为你没有包括像top / atop这样的信息。 这是因为Wordpress / PHP效率不高,需要大量的服务器资源。 如果你喜欢的话,你可以在服务器忙的时候发布顶部/顶部的截图,但是如果PHP全部采用,那么就没有必要。

解决scheme

一个解决scheme,可能是最好的解决scheme,是caching。 有两种types的caching。

页面caching

在这种情况下页面caching通常是最好的types。 它只适用于匿名用户,而不适用于已login的用户。在许多网站上,匿名用户占据了大部分stream量,因此caching这些stream量可能会带来巨大的好处。 一个页面由用户生成,存储在Nginx页面caching中,然后提供给下一个用户。 Nginx页面caching通常在RAM中,因此速度非常快。

caching头

为了页面caching工作,您需要正确设置您的标题。 这可以使用一些WordPress的caching插件,但我不使用它们,所以我在Nginx中。 我必须添加正确的模块来构buildNginx,这非常简单。

WordPress的caching

另一种types的caching是由WordPress内的插件完成的。 这可以caching需要花费时间的数据库请求,并且还可以执行某些我不完全了解的对象caching。 这可以帮助匿名用户和login用户。 有时会导致问题。

我在这里有一个教程。 它涵盖了caching,构buildNginx以及使用内容分发networking(Content Distribution Network,CDN)等一系列其他function,这些内容也可以加快速度。 页面有可下载的configuration文件。 Nginx有一篇关于微caching的文章,这是一个很好的阅读。

CDN:

说到CDN,如果你有一个超大规模的网站,你可以configuration你的页面caching,并configurationCDNcaching页面。 这意味着您的网站很less会看到请求,只有login用户和caching刷新。 这将影响您的服务器统计信息,并增加为用户提供陈旧数据的机会。

Nginx的错误

Nginx 1.11.11有一个bug,有时候会使用100%的CPU。 Nginx 1.11.12 修复了这个问题 。