nginx調優和報錯處理
MySQL安全優化包括：初始化安全腳本、密碼安全、備份與還原、數據安全。
Tomcat安全優化包括：隱藏版本信息、降權啟動、刪除默認測試頁面.
###################################################################
vim /usr/local/nginx/logs/access.log //訪問日誌
keepalive_timeout //長時間不訪問，服務器斷開連接
[[email protected] ~]# curl http://192.168.4.5/status
Active connections: 1 //多少人同時訪問
server accepts handled requests
10 10 3
Reading: 0 Writing: 1 Waiting: 0客戶端訪問10次 TCP握手連接數
服務器接收10次
發送3次請求 點頁面的次數
###################################################################
http是tcp協議
worker_processes 2; //與CPU核心數量一致
events {
worker_connections 50000; //並發連接數
即使修改了配置文件的並發連接數，但是內核的默認參數還是不變的。
###################################################################
優化Linux內核參數（最大文件數量）
ulimit-a
open files (- n) 1024
ulimit -Hn 100000 //硬限制 不能超過這個數
（都是臨時規則）
ulimit -Sn 100000 //軟限制 只是警告
vim /etc/security/limits.conf //永久配置
-
soft nofile 100000 //軟限制
- hard nofile 100000 //硬限制
####################################################################
優化Nginx數據包頭緩存
1）優化前，使用腳本測試長頭部請求是否能獲得響應
[[email protected] ~]# cat lnmp_soft/buffer.sh
#!/bin/bash
URL=http://192.168.4.5/index.html?
for i in {1..5000}
do
URL=${URL}v$i=$i
done
curl $URL //經過5000次循環後，生成一個長的URL地址欄
[[email protected] ~]# ./buffer.sh
.. ..
<center><h1>414 Request-URI Too Large</h1></center> //提示頭部信息過大`
url=192.168.4.5/
for i in 1..5000
url=$url_v$i=$i
url=192.168.4.5/v1=1
usl=http://192.168.4.5/v1=1v2=2v3=3 v5000=5000
服務器和客戶端都會報錯414，說明服務器給的內存太小，地址欄過長
修改配置文件，能存更多的地址欄
414報錯，優化緩存大小，讓他處理地址欄數據更大
修改Nginx配置文件，增加數據包頭部緩存大小
[[email protected] ~]# vim /usr/local/nginx/conf/nginx.conf
http }
client_header_buffer_size 1k; //默認請求包頭信息的緩存
large_client_header_buffers 4 4k; //大請求包頭部信息的緩存個數與容量
}
[[email protected] ~]# nginx -s reload
######################################################################
瀏覽器自帶緩存功能
如果你訪問的是 （多媒體） jpg，視頻，mp3
expries 30; //緩存多久
修改Nginx配置文件，定義對靜態頁面的緩存時間
[[email protected] ~]# vim /usr/local/nginx/conf/nginx.conf
server {
listen 80;
server_name localhost;
location / {
root html;
index index.html index.htm;
}
location ~* .(jpg|jpeg|gif|png|css|js|ico|xml)$ {
expires 30d; //定義客戶端緩存時間為30天
}
}
[[email protected] ~]# cp /usr/share/backgrounds/day.jpg /usr/local/nginx/html
[[email protected] ~]# nginx -s reload
#請先確保nginx是啟動狀態，否則運行該命令會報錯,報錯信息如下：
#[error] open() "/usr/local/nginx/logs/nginx.pid" failed (2: No such file or directory)
###############################################################################
日誌切割
日誌文件越來越大怎麽辦？單個文件10G? 如何切割？（非常常見的面試題）
步驟：
- 把舊的日誌重命名
- kill USR1 PID(nginx的進程PID號)
1）手動執行
備註：/usr/local/nginx/logs/nginx.pid文件中存放的是nginx的進程PID號。
[[email protected] ~]# mv access.log access2.log
[[email protected] ~]# kill -USR1 $(cat /usr/local/nginx/logs/nginx.pid)
2）自動完成
每周5的03點03分自動執行腳本完成日誌切割工作。
[[email protected] ~]# vim /usr/local/nginx/logbak.sh
#!/bin/bash
date=date +%Y%m%d
logpath=/usr/local/nginx/logs
mv $logpath/access.log $logpath/access-$date.log
mv $logpath/error.log $logpath/error-$date.log
kill -USR1 $(cat $logpath/nginx.pid)
[[email protected] ~]# crontab -e
03 03 5 /usr/local/nginx/logbak.sh
########################################################################
/usr/local/nginx/conf/mime.types
步驟七：對頁面進行壓縮處理
1）修改Nginx配置文件
[[email protected] ~]# cat /usr/local/nginx/conf/nginx.conf
http {
.. ..
gzip on; //開啟壓縮
gzip_min_length 1000; //小文件不壓縮
gzip_comp_level 4; //壓縮比率
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
//對特定文件壓縮，類型參考mime.types
.. ..
}
###################################################################
客戶端可以通過內存讀取數取，不通過硬盤。可以更快速獲取數據
服務器內存緩存
1）如果需要處理大量靜態文件，可以將文件緩存在內存，下次訪問會更快。
http {
open_file_cache max=2000 inactive=20s;
open_file_cache_valid 60s;
open_file_cache_min_uses 5;
open_file_cache_errors off;
//設置服務器最大緩存2000個文件句柄，關閉20秒內無請求的文件句柄
//文件句柄的有效時間是60秒，60秒後過期
//只有訪問次數超過5次會被緩存
//緩存報錯關掉
}
Nginx安全優化包括：刪除不要的模塊、修改版本信息、限制並發、拒絕非法請求、防止buffer溢出。
性能優化：定義狀態頁面、優化NGINX並發量、優化Linux內核參數、優化nginx數據包頭緩存、對頁面進行壓縮處理
服務器內存緩存
#############################################################################
Nginx常見報錯及處理方法
403是很常見的錯誤代碼，一般就是未授權被禁止訪問的意思。
可能的原因有兩種：
Nginx程序用戶無權限訪問web目錄文件
Nginx需要訪問目錄，但是autoindex選項被關閉
修復方法：
授予Nginx程序用戶權限讀取web目錄文件
設置autoindex目錄為on
location /path/to/website/folder {
...
autoindex on;
... }
404
第一種：Nginx自己的錯誤頁面
Nginx訪問一個靜態的html 頁面，當這個頁面沒有的時候，Nginx拋出404，那麽如何返回給客戶端404呢？
看下面的配置，這種情況下不需要修改任何參數，就能實現這個功能。
第二種：反向代理的錯誤頁面
如果後臺Tomcat處理報錯拋出404，想把這個狀態叫Nginx反饋給客戶端或者重定向到某個連接，配置如下：
location / {
if ($request_uri ~ ‘^/$’) {
rewrite . http://域名/index.html redirect;
}
關鍵參數：這個變量開啟後，我們才能自定義錯誤頁面，當後端返回404，nginx攔截錯誤定義錯誤頁面
第三種：Nginx解析php代碼的錯誤頁面
1
如果後端是php解析的，需要加一個變量
在http段中加一個變量
fastcgi_intercept_errors on 就可以了。
2
指定一個錯誤頁面：
error_page 404 /404.html;
location = /404.html {
root /usr/share/nginx/html;
}
3
指定一個url地址：
error_page 404 /404.html;
error_page 404 = http://www.test.com/error.html;
413 Request Entity Too Large
一般原因:一般出現在上傳文件
解決方法：配置nginx.conf相關設置
1.client_max_body_size 10m; //客戶端最大上傳大小
配置php.ini如下(必須和nginx.conf配置一致)
1.post_max_size=10M //設置最大大小
2.upload_max_filesize=2M //上傳最大文件大小
499 Client Closed Request
一般原因:server處理請求未結束，而client提前關閉了連接，此時也會返回499。
解決方法：proxy_ignore_client_abort on; //代理忽視客戶端終止計劃
#讓代理服務端不要主動關閉客戶端的連接。
只在做反向代理的時候加入，作為其他服務器的時候，關閉為好，默認設置是關閉的！
如果使用了 proxy_ignore_client_abort on ;
默認 proxy_ignore_client_abort 是關閉的，此時在請求過程中如果客戶端端主動關閉請求或者客戶端網絡斷掉，那麽 Nginx 會記錄 499
那麽客戶端主動斷掉連接之後，Nginx 會等待後端處理完(或者超時)，然後記錄「後端的返回信息」到日誌。所以，如果後端返回 200，就記錄 200 ；如果後端放回 5XX ，那麽就記錄 5XX 。
如果超時(默認60s，可以用 proxy_read_timeout 設置)，Nginx 會主動斷開連接，記錄 504
500 Internal Server Rrror
一般原因：腳本錯誤，（php語法錯誤、lua語法錯誤）
訪問量過大，系統資源限制，不能打開過多文件
磁盤空間不足。（access log開啟可能導致磁盤滿溢 關閉）
解決方法：語法錯誤查看nginx_err_log php_err_log。
文件訪問量：
1.修改nginx配置文件
1.worker_rlimit_nofile 65535; //worker進程最大打開文件數
2.修改/etc/security/limits.conf
-
- soft nofile 65535 //軟文件數
-
- hard nofile 65535 //硬文件數
一般分析思路:
（1）查看nginx error log ,查看php error log；
（2）如果是too many open files,修改nginx的worker_rlimit_nofile參數,使用ulimit查看系統打開文件限制,修改/etc/security/limits.conf；
（3）如果是腳本的問題,則需要修復腳本錯誤,並優化代碼；
（4）各種優化都做好,還是出現too many open files,那就要考慮做負載均衡,把流量分散到不同服務器上去了。
502 Bad Gateway、503 Serveice Unavailable
一般原因:後端服務無法處理，業務中斷。
解決方法：從後端日誌獲取錯誤原因，解決後端服務器問題。
504 Gateway Timeout
一般原因:後端服務器在超時時間內，未響應Nginx代理請求
解決方法：根據後端服務器實際處理情況，調正後端請求超時時間。
1.proxy_read_timeout 90;
2.proxy_send_timeout 90;
一般原因:可能網站頁面緩存大，而fastcgi默認進程響應緩存區8k
解決方法：配置nginx.conf相關設置
1.fastcgi_buffers 8 128k
2.send_timeout 60;
nginx調優和報錯處理