(Click the public account above, you can follow it quickly)
Source: huangguisu
Link: http://blog.csdn.net/hguisu/article/details/8930668
6. Nginx optimization
1. Optimize the compilation and installation process
1). Reduce the compiled file size of Nginx
By default, Nginx is compiled in Debug mode, which inserts a lot of trace and ASSERT messages, and once compiled, an Nginx is several megabytes long. If you disable debug mode on Nginx before compiling, Nginx is only a few hundred kilobytes after compiling. Therefore, you can modify the relevant source code and disable debug mode before compiling. Specific methods are as follows:
After the Nginx source file is decompressed, find the auto/cc/ GCC file in the source directory and find the following lines:
# debug
CFLAGS = $CFLAGS – “g”
To disable debug mode, comment out or delete these two lines.
2. Specify CPU type compiler optimization for a specific CPU
When compiling Nginx, the default GCC compilation parameter is “-o”. To optimize GCC compilation, use the following two parameters:
– with – cc – opt = ‘- O3’
— with — CPU — opt=CPU # compiled for a specific CPU, valid values include:
pentium, pentiumpro, pentium3, # pentium4, athlon, opteron, amd64, sparc32, sparc64, ppc64
To determine the CPU type, run the following command:
[root@localhost home]#cat /proc/cpuinfo | grep “model name”
2. Use TCMalloc to optimize Nginx performance
TCMalloc, short for Thread-Caching Malloc, is a member of Google-PerfTools, an open source tool developed by Google. Compared with the standard GLIBC library Malloc, the TCMalloc library is much more efficient and fast in memory allocation, which greatly improves the performance of the server under high concurrency conditions, thus reducing the system load. Here’s how to add TCMalloc library support to Nginx.
To install the TCMalloc library, you need to install two software packages, Libunwind (not required for 32-bit operating systems) and Google-PerfTools. The Libunwind library provides basic function call chains and function call registers for 64-bit CPU – and operating-system based programs. The following describes how to optimize Nginx using TCMalloc.
1). Install the LibunWind library
Corresponding libunwind version can be downloaded from http://download.savannah.gnu.org/releases/libunwind, here to download the libunwind – 0.99 – alpha. Tar. Gz. The installation process is as follows:
[root @ localhost home] # tar ZXVF libunwind – 0.99 – alpha. Tar. Gz
[root @ localhost home] # CD libunwind – 0.99 – alpha /
[root @ localhost libunwind – 0.99 – alpha] # CFLAGS = -fpic. / configure
[root @ localhost libunwind – 0.99 – alpha] # make CFLAGS = -fpic
[root @ localhost libunwind – 0.99 – alpha] # make CFLAGS = -fpic install
2). Install Google – perftools
You can download the corresponding version of Google-PerfTools from http://google-perftools.googlecode.com, in this case Google-Perftools-1.8.tar.gz. The installation process is as follows:
[root @ localhost home] # tar ZXVF Google – perftools – 1.8. Tar. Gz
[root @ localhost home] # CD Google – perftools – 1.8 /
[root @ localhost Google – perftools – 1.8] #. / configure
[root@localhost Google — Perftools — 1.8]#make && make install
[root @ localhost Google – perftools – 1.8] # echo “/ usr /
local/lib” > /etc/ld.so.conf.d/usr_local_lib.conf
[root @ localhost Google – perftools – 1.8] # ldconfig
At this point, the Google-PerfTools installation is complete.
3). Recompile Nginx
To enable Nginx to support Google-Perftools, you need to add the “-with-google_perftools_module” option to recompile Nginx during installation. The installation code is as follows:
[root @ localhostnginx – 0.7.65] #. / configure
> – with – google_perftools_module – with – http_stub_status_module — prefix = / opt/nginx
[root @ localhost nginx – 0.7.65] # make
[root @ localhost nginx – 0.7.65] # make install
Nginx installation is complete.
4). Add thread directory for Google-PerfTools
Create a thread directory and place the files under/TMP /tcmalloc. The operation is as follows:
[root@localhost home]#mkdir /tmp/tcmalloc
[root@localhost home]#chmod 0777 /tmp/tcmalloc
5). Modify the Nginx master configuration file
To modify the nginx.conf file, add the following code below the pid line:
#pid logs/nginx.pid;
google_perftools_profiles /tmp/tcmalloc;
Next, restart Nginx to finish loading Google-PerfTools.
6). Verify the running status
To verify that Google-PerfTools has been loaded properly, run the following command:
[root@ localhost home]# lsof -n | grep tcmalloc
Nginx 2395 nobody 9w REG 8 8 0 1599440 / TMP /tcmalloc.2395
Nginx 2396 nobody 11w REG 8 8 0 1599443 / TMP /tcmalloc.2396
Nginx 2397 nobody 13W REG 8 8 0 1599441 / TMP /tcmalloc.2397
Nginx 2398 nobody 15W REG 8 8 0 1599442 / TMP /tcmalloc.2398
Since worker_PROCESSES is set to 4 in the Nginx configuration file, four Nginx threads are started, each with a row of records. The numeric value after each thread file is the PID value of the started Nginx.
At this point, the optimization of Nginx using TCMalloc is complete.
3.Nginx kernel parameter optimization
Kernel parameter optimization, mainly in Linux system for Nginx application kernel parameter optimization.
An optimization example is given below for your reference.
net.ipv4.tcp_max_tw_buckets = 6000
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_syncookies = 1
net.core.somaxconn = 262144
net.core.netdev_max_backlog = 262144
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_syn_retries = 1
net.ipv4.tcp_fin_timeout = 1
net.ipv4.tcp_keepalive_time = 30
Add the above kernel parameter values to the /etc/sysctl.conf file and run the following command for them to take effect:
[root@ localhost home]#/sbin/sysctl -p
The following describes the meanings of the options in the example:
Net.ipv4. tcp_max_tw_buckets: Sets the number of timewaits. The default value is 180 000.
Net.ipv4. ip_local_port_range: Specifies the range of ports allowed to be opened by the system. Otherwise the port number will be insufficient in high concurrency cases.
Net.ipv4. tcp_TW_RECYCLE: This option is used to enable timewait fast recycle.
Net.ipv4. tcp_tw_reuse: Allows time-wait sockets to be reused for new TCP connections.
Net.ipv4. tcp_syncookies: This option is used to enable SYN Cookies. When the SYN wait queue overflows, the Cookies are enabled for processing.
Net.core. somaxconn: The default value of this option is 128. This parameter is used to adjust the number of TCP connections initiated by the system at the same time.
Net.core.net dev_MAX_backlog: Option represents the maximum number of packets allowed to be sent to the queue when each network interface receives packets at a rate faster than the kernel can process them.
Net.ipv4. tcp_MAX_orphans: Option used to set the maximum number of TCP sockets in the system that are not associated with any user file handles. If this number is exceeded, the isolated connection is immediately reset and a warning message is printed. This restriction is intended only to prevent simple DoS attacks. Do not rely too much on this limit or even artificially reduce the value, more often should increase the value.
Net.ipv4. tcp_max_syn_backlog: Option for logging the maximum number of connection requests that have not yet received client confirmation. The default value of this parameter is 1024 for a system with 128MB of memory and 128 for a system with small memory.
The value of the net.ipv4.tcp_synack_retries parameter determines the number of SYN+ACK packets that the kernel can send before disconnecting.
The net.ipv4.tcp_syn_retries option indicates the number of SYN packets sent before the kernel discontinues establishing a connection.
The net.ipv4.tcp_fin_timeout option determines how long the socket remains in fin-WaIT-2 state. The default value is 60 seconds. Setting this value correctly is important because sometimes even a lightly loaded Web server can have a large number of dead sockets and run the risk of running out of memory.
The net.ipv4.tcp_syn_retries option indicates the number of SYN packets sent before the kernel discontinues establishing a connection.
The net.ipv4.tcp_fin_timeout option determines how long the socket remains in fin-WaIT-2 state if the sender asks to close the socket. The receiver can go wrong and never close the connection, or even go down unexpectedly.
The default value of net.ipv4.tcp_fin_timeout is 60 seconds. Note that even a lightly loaded Web server runs the risk of running out of memory due to a large number of dead sockets. Fin-wait-2 is less dangerous than Fin-WaIT-1, as it consumes up to 1.5KB of memory, but it has a longer lifetime.
Net.ipv4. tcp_keepalive_time Indicates the frequency at which TCP sends Keepalive messages when Keepalive is enabled. The default value is 2 (in hours).
4. PHP – FPM optimization
These tips may be useful if you use phP-fPM to manage FastCGI for your high-load site:
1) Increase the FastCGI process count
Increase the number of PHP FastCGI child processes to 100 or more, and 200 is recommended for stress testing on a server with 4 gb of memory.
2) Add restrictions on phP-fPM opening file descriptors
The rlimit_files tag is used to set the limit of phP-FPM on open file descriptors. The default value is 1024. The value of this tag must be associated with the number of open files in the Linux kernel; for example, to set this value to 65 535, you must execute “ulimit-HSN 65536” on the Linux command line.
Then add a limit to the phP-fPM open file descriptor:
# vi /path/to/php-fpm.conf
Find the “1024”
Change 1024 to 4096 or higher.
Restart PHP – FPM.
Ulimit-n should be set to 65536 or greater. How to adjust this parameter, you can refer to some articles on the web. Run the ulimit -n 65536 command to change the password. If you can’t modify, need to set up the/etc/security/limits the conf, to join
* hard nofile65536
* soft nofile 65536
3) Add max_requests as appropriate
The max_requests tag indicates the maximum number of requests per child that will be closed. The default setting is 500.
500
4. Parameter optimization of nginx.conf
The number of processes nginx needs to start is usually equal to the total number of CPU cores.
Each Nginx process consumes about 10 megabytes of memory
worker_cpu_affinity
For Linux only, you can bind the worker process to the CPU using this option (not available on machines with 2.4 cores)
If the CPU is 8, the CPU allocation is as follows:
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000
00100000 01000000 10000000
Nginx can use multiple worker processes for the following reasons:
to use SMP
to decrease latency when workers blockend on disk I/O
to limit number of connections per process when select()/poll() is
used The worker_processes and worker_connections from the event sections
allows you to calculate maxclients value: k max_clients = worker_processes * worker_connections
worker_rlimit_nofile 102400;
The maximum number of open file descriptors for each Nginx process must be the same as the number of open files for a single process in the system. In Linux 2.6, the number of open files is 65535. Worker_rlimit_nofile should be filled with 65535 nginx scheduling when allocating requests to processes is not so balanced, if exceeded will return 502 error. Let me write it a little bit bigger here
use epoll
Nginx uses the latest EPoll (Linux 2.6 kernel) and KQueue (FreeBSD) network I/O models, while Apache uses the traditional SELECT model.
The SELECT network I/O model used by Apache is very inefficient to handle a large number of reads and writes to connections. Polling I/O is the most time-consuming operation on a high-concurrency server, which Linux can currently tolerate
Squid and Memcached used epoll NETWORK I/O model.
worker_connections 65535;
Maximum number of simultaneous connections allowed per worker process (Maxclient = work_processes *worker_connections)
keepalive_timeout 75
Keepalive timeout duration
Note the official line here:
The parameters can differ from each other. Line Keep-Alive:
timeout=time understands Mozilla and Konqueror. MSIE itself shuts
keep-alive connection approximately after 60 seconds.
client_header_buffer_size 16klarge_client_header_buffers 4 32k
Client request header buffer size
By default, nginx uses client_header_buffer_size to read the header value, or large_client_header_buffers if the header is too large
Nginx 400 bad request lines if the number of bad request lines exceeds the buffer value Nginx must accept the longest HTTP header size larger than one of the buffers, otherwise it will report a Bad Request of 400.
open_file_cache max 102400
Use the fields HTTP, server, location directive to specify whether caching is enabled. If enabled, the following information will be recorded in the file: · Open file descriptor, size information and modification time · Existing directory information · Error messages during file search — without this file, cannot be read correctly, refer to the open_FILe_cache_errors directive option:
· Max — Specifies the maximum number of caches, and if the cache overflows, the longest used file (LRU) will be removed example:
open_file_cache max=1000 inactive=20s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on;
open_file_cache_errors
Grammar: open_file_cache_errors on | off default: open_file_cache_errors off use field: HTTP, server, whether this directive specifies the location in the search for a file is a record cache error.
open_file_cache_min_uses
Syntax :open_file_cache_min_uses number Default :open_file_cache_min_uses 1 Fields: HTTP, server, The location directive specifies the minimum number of files that can be used within a certain time range for open_file_cache invalid arguments. If larger values are used, the file descriptor is always open in the cache.
open_file_cache_valid
Syntax: open_file_cache_VALID Time Default: open_file_cache_VALID 60 Fields: HTTP, server, The location directive specifies when to check for valid information about cached items in open_file_cache.
Open the gzip
gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_http_version 1.0;
gzip_comp_level 2;
gzip_types text/plain application/x-javascript text/css
application/xml; gzip_vary on;
Cache static files:
location ~* ^.+.(swf|gif|png|jpg|js|css)$ {
root /usr/local/ku6/ktv/show.ku6.com/;
expires 1m;
}
7. Error check
1, Nginx 502 Bad Gateway
Error 502 occurs when there are not enough php-cgi processes, PHP takes a long time to execute (mysql is slow), or the php-cgi process dies
Nginx 504 Gateway time-out Nginx 504 Gateway time-out nginx.conf
1) Check whether the current number of PHP FastCGI processes is sufficient:
Netstat anpo | grep “PHP – cgi” | wc -l
If the actual number of FastCGI processes used is close to the preset number, it indicates that the number of FastCGI processes used is insufficient and needs to be increased.
2) The execution time of some PHP programs exceeds the waiting time of Nginx, which can be increased appropriately
The FastCGI timeout in the nginx.conf configuration file, for example:
http {
…
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
…
}
2, 413 Request Entity Too Large
Solution: Increase client_max_body_size
Client_max_body_size: The directive specifies the maximum request entity size allowed for client connections, which appears in the Content-Length field of the request header. If the Request is larger than the specified value, the client will receive a “Request Entity Too Large” (413) error. Remember, the browser doesn’t know how to display this error.
Increase post_max_size and upload_max_filesize in php.ini
3 Ngnix error.log appears:
Upstream sent too big header while reading response header from upstream error
1) If it is an Nginx reverse proxy
Upstream sends too big header: nginx proxy sends too big header: nginx proxy sends too big header: nginx proxy proxy: Nginx proxy: nginx proxy: nginx proxy: nginx proxy: nginx proxy: Nginx proxy: Nginx proxy: Nginx proxy The header returned by the backend server is too large for Nginx to handle.
server {
listen 80;
server_name *.xywy.com ;
large_client_header_buffers 4 16k;
location / {
Add these three lines
proxy_buffer_size 64k;
proxy_buffers 32 32k;
proxy_busy_buffers_size 128k;
proxy_set_header Host $host;
Proxy_set_header X – Real – IP $remote_addr;
Proxy_set_header X – Forwarded – For $proxy_add_x_forwarded_for;
}
}
2）如果是 nginx+PHPcgi
Upstream: “fastcgi://127.0.0.1:9000” On the
Add:
fastcgi_buffer_size 128k;
fastcgi_buffers 4 128k;
server {
listen 80;
server_name ddd.com;
index index.html index.htm index.php;
client_header_buffer_size 128k;
large_client_header_buffers 4 128k;
proxy_buffer_size 64k;
proxy_buffers 8 64k;
fastcgi_buffer_size 128k;
fastcgi_buffers 4 128k;
location / {
…
}
}
PHP vulnerability in Nginx
Vulnerability: Nginx is a high-performance Web server that is widely used. It is not only used as a reverse proxy, but also supports PHP well. 80Sec found that there was a serious security issue, which by default could cause the server to incorrectly parse any type of file as PHP. This would result in a serious security issue, allowing malicious attackers to compromise phP-enabled Nginx servers.
Vulnerability analysis: Nginx uses CGI to support PHP by default, such as in configuration files
location ~ .php$ {
root html;
Fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
include fastcgi_params;
}
The key variable SCRIPT_FILENAME passed to the backend Fastcgi is determined by the $fastcgi_script_name generated by nginx. Analysis shows that $fastcgi_script_name is directly controlled by the URI environment variable, and this is where the problem arises. To better support PATH_INFO extraction, there is the cgi.fix_pathinfo option in the PHP configuration options, which is used to extract the actual script name from SCRIPT_FILENAME.
Suppose there is a http://www.80sec.com/80sec.jpg, we are going to visit in the following way
http://www.80sec.com/80sec.jpg/80sec.php
You will get a URI
/80sec.jpg/80sec.php
After the location directive, the request will be handled by fastCGI on the back end, and nginx sets the environment variable SCRIPT_FILENAME to
/scripts/80sec.jpg/80sec.php
In other webservers like Lighttpd, we find SCRIPT_FILENAME is correctly set to
/scripts/80sec.jpg
So there is no such problem.
When receiving this option, the backend fastCGI determines whether SCRIPT_FILENAME will be extra processed based on the fix_pathinfo configuration. In general, not setting fix_pathinfo will affect the application that uses PATH_INFO for routing. Therefore, this option is usually enabled. Php will use this option to look for the actual name of the script file to see if the file exists, separating SCRIPT_FILENAME from PATH_INFO
/ scripts / 80 SEC. JPG and 80 SEC. PHP
Finally, with /scripts/80sec.jpg as the script for this request, the attacker can make Nginx parse any type of file in PHP.
POC: Visit a PHP supported nginx site and add /80sec.php to any resource file such as robots.txt. You can see the following differences:
Go to http://www.80sec.com/robots.txt
HTTP / 1.1 200 OK
Server: nginx / 0.6.32
Date: Thu, 20 May 2010 10:05:30 GMT
The Content – Type: text/plain
The Content – Length: 18
Last–Modified: Thu, 20 May 2010 06:26:34 GMT
Connection: keep–alive
Keep – the Alive: timeout = 20
The Accept – Ranges: bytes
Access to http://www.80sec.com/robots.txt/80sec.php
HTTP / 1.1 200 OK
Server: nginx / 0.6.32
Date: Thu, 20 May 2010 10:06:49 GMT
The Content – Type: text/HTML
Transfer – Encoding: chunked
Connection: keep–alive
Keep – the Alive: timeout = 20
X – Powered By: PHP / 5.2.6
Changes in the Content-Type indicate that the backend is responsible for parsing changes, and the site may be vulnerable.
Vulnerability vendor: http://www.nginx.org
Solution:
We have tried to contact the authorities, but you can reduce the loss through the following ways before
Close cgi.fix_pathinfo to 0
or
if ( $fastcgi_script_name ~ .. */.*php ) {
return 403;
}
【 微信 号 recommend 】
For more recommendations, please see “Notable technology and Design public account”.
IT recommended popular public accounts related to technology, design, geeks and IT dating. Technology covers: Python, Web front-end, Java, Android, iOS, PHP, C/C++,.NET, Linux, database, operation and maintenance, big data, algorithms, IT workplace, etc. Click “noteworthy technology and design public number”, find wonderful!