一,nginx?介紹
(一)nginx? 與apache
1,? ?Apache event?模型
相對于?prefork?模式??可以同時處理更多的請求
相對于?worker? 模式? ??解決了keepalive場景下,長期被占用的線程的資源浪費問題? 因為有監聽線程(某些線程因為被keepalive,空掛在哪里等待,中間幾乎沒有請求過來,甚至等到超時)
?但是在生產環境中?apache?event?的表現不盡人意,這時就要說到他的缺點:
沒有線程安全控制? ? ? ?
處理高并發 ? 進程切換問題
2,更高性能的Web服務端? ?Nginx
基于Nginx的工作場景
正向代理: 代理的客戶端( 科學上網 )
反向代理: 代理的服務端
二? ?Input Output 模型
(一)常見名詞介紹
1,磁盤I/O? (本地I/O)
磁盤I/O是進程向內核發起系統調用,請求磁盤上的某個資源比如是html 文件或者圖片,然后內核通過相應的驅動程序將目標文件加載到內核的內存空間,加載完成之后把數據從內核內存再復制給進程內存,如果是比較大的數據也需要等待時間
2,網絡I/O
一切皆文件,本質為對socket文件的讀寫 網絡通信就是網絡協議棧到用戶空間進程的IO就是網絡IO
3,用戶態
用戶態:應用程序 我們可以控
4,內核態
內核態:操作系統層面,我們不容易去控制的 操作系統
(二)客戶端上網的過程
1.客戶端發起請求 先發送到網卡 ??
2.網卡收到的報文復制到內核空間
3.內核空間再復制到用戶空間的應用程序空間
4.nginx 分析得到一個磁盤頁面文件
5.再將需求反饋給內核空間,應為應用程序沒有權限從磁盤上直接讀取文件,需要依靠內核
6.內核去磁盤上找到所需要的文件,加載到內核空間
7.加載后再復制到用戶空間
8.用戶空間構建響應報文,交給內核空間,內核空間再復制給網卡,返回給用戶
整個過程會來回切換 用戶空間,內核空間 ?那么我們可以再次基礎上做優化處理
為了優化客戶體驗? ,要么解決的是本地 io (零拷貝技術 )?要么?解決的是網絡 io(多路復用 )
(三)零拷貝技術
1,零拷貝技術目的
解決的是本地 i/o
2,零拷貝技術原理
原理:減少 內核空間 和 用戶空間 之間拷貝次數
3,零拷貝技術?方法
通過 緩存或者映射
(可以簡單粗暴理解為? 內核把經常要找給nginx的文件緩存或者映射? ?減少nginx沒有權利去調用磁盤上的內容,需要內核去調? ? 這一步)
4,零拷貝技術在nginx?配置文件上的體現
在主配置文件有 體現 這一行和零拷貝技術有關
(四)I/O 模型相關概念
nginx 分析該報文, 將報文和自己的配置文件,一一比對,按照配置文件完成請求, 分析后發現 客戶需要 index.html 由于 程序的權限問題, 沒有資格直接調用磁盤上的文件, 程序會再將這個請求 再次轉發給內核
在這個過程時,A (nginx)程序布置了一個任務給 B(內核)
任務是 找個某個文件,先復制內核,在復制給我
1,消息反饋機制(同步?異步)
同步
同步: 內核處理完了 不會主動 告訴 nginx你交代的任務我做完了,需要nginx 自己不停的去問內核 你做完沒有
異步
內核處理完了 會主動 告訴 nginx,我準備好資源了你來復制吧
2,調用者在等待結果返回之前所處的狀態(阻塞/非阻塞 )
1 2 3 4
nginx 進程 在 處理 1 請求的時候 是否可以繼續處理2的請求?
非阻塞:
nginx在等待內核給文件的時候,這中間的等待時間,我可以去處理其他請求
阻塞:
只能處理完1客戶所有的任務后再去接待2客戶
(五)網絡I/O模型
1,阻塞型 I/O 模型(blocking IO)
1.1?說明
阻塞IO模型是最簡單的I/O模型,用戶線程在內核進行IO操作時被阻塞用戶線程通過系統調用read發起I/O讀操作,由用戶空間轉到內核空間。內核等到數據包到達后,然后將接收的數據拷貝到用戶空間,完成read操作用戶需要等待read將數據讀取到buffer后,才繼續處理接收的數據。整個I/O請求的過程中,用戶線程是被阻塞的,這導致用戶在發起IO請求時,不能做任何事情,對CPU的資源利用率不夠
1.2?優缺點
-
優點:程序簡單,在阻塞等待數據期間進程/線程掛起,基本不會占用 CPU 資源
-
缺點:每個連接需要獨立的進程/線程單獨處理,當并發請求量大時為了維護程序,內存、線程切換開銷較大,apache 的preforck使用的是這種模式。? ??慢 不能處理高并發
2,非阻塞型 I/O 模型 (nonblocking IO)
2.1?說明
用戶線程發起IO請求時立即返回。但并未讀取到任何數據,用戶線程需要不斷地發起IO請求,直到數據到達后,才真正讀取到數據,繼續執行。即 “輪詢”機制存在兩個問題:如果有大量文件描述符都要等,那么就得一個一個的read。這會帶來大量的Context Switch(read是系統調用,每調用一次就得在用戶態和核心態切換一次)。輪詢的時間不好把握。這里是要猜多久之后數據才能到。等待時間設的太長,程序響應延遲就過大;設的太短,就會造成過于頻繁的重試,干耗CPU而已,是比較浪費CPU的方式,一般很少直接使用這種模型,而是在其他IO模型中使用非阻塞IO這一特性。
2.2?優缺點
實際使用很少? ?沒有返回機制
3,多路復用 I/O 型 ( I/O multiplexing )
3.1?說明?
I/O multiplexing 主要包括:select,poll,epoll三種系統調用,select/poll/epoll的好處就在于單個process就可以同時處理多個網絡連接的IO。它的基本原理就是select/poll/epoll這個function會不斷的輪詢所負責的所有socket,當某個socket有數據到達了,就通知用戶進程。當用戶進程調用了select,那么整個進程會被block,而同時,kernel會“監視”所有select負責的socket,當任何一個socket中的數據準備好了,select就會返回。這個時候用戶進程再調用read操作,將數據從kernel拷貝到用戶進程。Apache prefork是此模式的select,work是poll模式。linux里的nginx默認是epoll
3.2?優缺點
讓select 或者poll 或者 epoll 進程
去看好沒好 阻塞在select nginx照樣接請求
4,信號驅動式 I/O 模型 (signal-driven IO)
4.1?說明
信號驅動I/O的意思就是我們現在不用傻等著了,也不用去輪詢。而是讓內核在數據就緒時,發送信號通知我們。
調用的步驟是,通過系統調用 sigaction ,并注冊一個信號處理的回調函數,該調用會立即返回,然后主程序可以繼續向下執行,當有I/O操作準備就緒,即內核數據就緒時,內核會為該進程產生一個SIGIO 信號,并回調注冊的信號回調函數,這樣就可以在信號回調函數中系統調用 recvfrom 獲取數據,將用戶進程所需要的數據從內核空間拷貝到用戶空間
此模型的優勢在于等待數據報到達期間進程不被阻塞。用戶主程序可以繼續執行,只要等待來自信號處理函數的通知。
在信號驅動式 I/O 模型中,應用程序使用套接口進行信號驅動 I/O,并安裝一個信號處理函數,進程繼續運行并不阻塞
當數據準備好時,進程會收到一個 SIGIO 信號,可以在信號處理函數中調用 I/O 操作函數處理數據。
4.2?優缺點
-
優點:線程并沒有在等待數據時被阻塞,內核直接返回調用接收信號,不影響進程繼續處理其他請求因此可以提高資源的利用率
-
缺點:信號 I/O 在大量 IO 操作時可能會因為信號隊列溢出導致沒法通知
5,異步 I/O 模型 (asynchronous IO)
5.1?說明
異步I/O 與 信號驅動I/O最大區別在于,信號驅動是內核通知我們何時開始一個I/O操作,而異步I/O是由內核通知我們I/O操作何時完成,兩者有本質區別,相當于不用去飯店場吃飯,直接點個外賣,把等待上菜的時間也給省了。所有事情都交給內核處理。
5.2?優缺點
阻塞最少? ?,但是對內核的性能要求很高
6,? 總結
這五種 I/O 模型中,越往后,阻塞越少,理論上效率也是最優
目前linux? 里的nginx? 使用多路復用i/o?模型
(六)select poll epoll
1,nginx?驅動模型介紹
Nginx支持在多種不同的操作系統實現不同的事件驅動模型,但是其在不同的操作系統甚至是不同的系統版本上面的實現方式不盡相同,主要有以下實現方式:
1、select: select庫是在linux和windows平臺都基本支持的 事件驅動模型庫,并且在接口的定義也基本相同,只是部 分參數的含義略有差異,最大并發限制1024,是最早期的事件驅動模型。 |
2、poll: 在Linux 的基本驅動模型,windows不支持此驅動模型,是select的升級版,取消了最大的并發限制,在編 譯nginx的時候可以使用--with-poll_module和--without-poll_module這兩個指定是否編譯select 庫。 |
3、epoll: epoll是庫是Nginx服務器支持的最高性能的事件驅動庫之一,是公認的非常優秀的事件驅動模型,它和 select和poll有很大的區別,epoll是poll的升級版,但是與poll有很大的區別. epoll的處理方式是創建一個待處理的事件列表,然后把這個列表發給內核,返回的時候在去輪訓檢查這個 表,以判斷事件是否發生,epoll支持一個進程打開的最大事件描述符的上限是系統可以打開的文件的最大 數,同時epoll庫的I/O效率不隨描述符數目增加而線性下降,因為它只會對內核上報的“活躍”的描述符進行 操作。 |
4、rtsig: 不是一個常用事件驅動,最大隊列1024,不是很常用 |
5、kqueue: 用于支持BSD系列平臺的高校事件驅動模型,主要用在FreeBSD 4.1及以上版本、OpenBSD 2.0級以上版 本,NetBSD級以上版本及Mac OS X 平臺上,該模型也是poll庫的變種,因此和epoll沒有本質上的區別, 都是通過避免輪訓操作提供效率。 |
6、/dev/poll: 用于支持unix衍生平臺的高效事件驅動模型,主要在Solaris 平臺、HP/UX,該模型是sun公司在開發 Solaris系列平臺的時候提出的用于完成事件驅動機制的方案,它使用了虛擬的/dev/poll設備,開發人員 將要見識的文件描述符加入這個設備,然后通過ioctl()調用來獲取事件通知,因此運行在以上系列平臺的時 候請使用/dev/poll事件驅動機制。 |
7、eventport: 該方案也是sun公司在開發Solaris的時候提出的事件驅動庫,只是Solaris 10以上的版本,該驅動庫看防 止內核崩潰等情況的發生。 |
8、Iocp: ?Windows系統上的實現方式,對應第5種(異步I/O)模型 |
2,select poll epoll? 具體區別
Select | Poll | Epoll | |
操作方式 | 遍歷 | 遍歷 | 回調 |
底層實現 | 數組 | 鏈表 | 哈希表 |
I/O效率 | 每次調用都進行線性遍歷,時間復雜度為o(n) | 同左 | 事件通知方式,每當fd就緒,系統注冊的回調函數就會被調用,將就緒的fd放到rdlllist里,時間復雜度為o(1) |
最大連接數 | 1024(x86) 2048(x64) | 無上限 | 無上限 |
fd拷貝 | 每次調用select都需要把fd集合從用戶拷貝到內核態 | 每次調用poll,都需要把fd集合從用戶態拷貝到內核態 | 調用epoll_ct時拷貝進內核并保存,之后每次epoll_wait不拷貝 |
3,總結?
epoll
linux里的nginx默認是epoll?
性能最好 epoll? ? (epoll? 是poll?升級版? )
只會遍歷已準備好的事件(fd)集合,事件個數無限制
select
會輪詢遍歷所有的 事件集合,其次遍歷的事件個數有限制
性能最差 select? ?
4,?實驗驗證
select 不管內核有沒有做好,只會遍歷fd 里的請求? ? ? ? ? ? 上限2048
epoll 會篩選出準備好的fd 里的請求? ? ? ? ? ?沒有上限限制
三,Nginx概述
(一)Nginx 功能介紹
-
靜態的web資源服務器html,圖片,js,css,txt等靜態資源
-
http/https協議的反向代理 ,7層 url
-
結合FastCGI /uWSGI/SCGI等協議反向代理動態資源請求
-
tcp/udp協議的請求轉發(反向代理) 4層
(二)?基礎特性
-
模塊化設計,較好的擴展性
-
高可靠性
-
支持熱部署:不停機更新配置文件,升級版本,更換日志文件
-
低內存消耗:10000個keep-alive連接模式下的非活動連接,僅需2.5M內存
-
event-driven, aio, mmap,sendfile
(三)Web 服務相關的功能
-
虛擬主機(server)
-
支持 keep-alive 和管道連接(利用一個連接做多次請求)
-
訪問日志(支持基于日志緩沖提高其性能)
-
url rewirte
-
路徑別名
-
基于IP及用戶的訪問控制
-
支持速率限制及并發數限制
-
重新配置和在線升級而無須中斷客戶的工作進程
(四)Nginx 進程結構
1,web請求處理機制
-
多進程方式:服務器每接收到一個客戶端請求就有服務器的主進程生成一個子進程響應客戶端,直到用戶關閉連接,這樣的優勢是處理速度快,子進程之間相互獨立,但是如果訪問過大會導致服務器資源耗盡而無法提供請求。
-
多線程方式:與多進程方式類似,但是每收到一個客戶端請求會有服務進程派生出一個線程來個客戶方進行交互,一個線程的開銷遠遠小于一個進程,因此多線程方式在很大程度減輕了web服務器對系統資源的要求,但是多線程也有自己的缺點,即當多個線程位于同一個進程內工作的時候,可以相互訪問同樣的內存地址空間,所以他們相互影響,一旦主進程掛掉則所有子線程都不能工作了,IIS服務器使用了多線程的方式,需要間隔一段時間就重啟一次才能穩定
2,主進程(master process)的功能
master是主進程? ? 不干活
對外接口:接收外部的操作(信號)
對內轉發:根據外部的操作的不同,通過信號管理 Worker
監控:監控 worker 進程的運行狀態,worker 進程異常終止后,自動重啟 worker 進程
讀取Nginx 配置文件并驗證其有效性和正確性
建立、綁定和關閉socket連接
按照配置生成、管理和結束工作進程
接受外界指令,比如重啟、升級及退出服務器等指令
不中斷服務,實現平滑升級,重啟服務并應用新的配置
開啟日志文件,獲取文件描述符
不中斷服務,實現平滑升級,升級失敗進行回滾處理
編譯和處理perl腳本
3,工作進程(worker process)的功能
worker?是子進程? 干活
所有 Worker 進程都是平等的
實際處理:網絡請求,由 Worker 進程處理
Worker進程數量:一般設置為核心數,充分利用CPU資源,同時避免進程數量過多,導致進程競爭CPU資源,
增加上下文切換的損耗
接受處理客戶的請求
將請求依次送入各個功能模塊進行處理
I/O調用,獲取響應數據
與后端服務器通信,接收后端服務器的處理結果
緩存數據,訪問緩存索引,查詢和調用緩存數據
發送請求結果,響應客戶的請求
接收主程序指令,比如重啟、升級和退出等
四,nginx 模塊
-
核心模塊:是 Nginx 服務器正常運行必不可少的模塊,提供錯誤日志記錄 、配置文件解析 、事件驅動機制 、進程管理等核心功能
-
標準HTTP模塊:提供 HTTP 協議解析相關的功能,比如: 端口配置 、 網頁編碼設置 、 HTTP響應頭設置 等等
-
可選HTTP模塊:主要用于擴展標準的 HTTP 功能,讓 Nginx 能處理一些特殊的服務,比如:Flash 多媒體傳輸 、解析 GeoIP 請求、 網絡傳輸壓縮 、 安全協議 SSL 支持等
-
郵件服務模塊:主要用于支持 Nginx 的 郵件服務 ,包括對 POP3 協議、 IMAP 協議和 SMTP協議的支持
-
Stream服務模塊: 實現反向代理功能,包括TCP協議代理 反向
-
第三方模塊:是為了擴展 Nginx 服務器應用,完成開發者自定義功能,比如: Json 支持、 Lua 支持等
nginx高度模塊化,但其模塊早期不支持DSO機制;1.9.11 版本支持動態裝載和卸載
核心模塊:core module
標準模塊:
?HTTP 模塊: ngx_http_*
?HTTP Core modules ??#默認功能
?HTTP Optional modules #需編譯時指定
?Mail 模塊: ngx_mail_*
?Stream 模塊 ngx_stream_*
第三方模塊
五,? 安裝nginx?和準備工作
企業主流1.18? ?偶數為? 穩定版
(一)編譯安裝nginx
為什么要編譯安裝?? ?可以安裝更多的模塊
1,?編譯安裝步驟
https://nginx.org/en/download.html
#官網yum -y install gcc pcre-devel openssl-devel zlib-devel openssl openssl-devel
#安裝依賴包
useradd -M -s /sbin/nologin nginx
#新建nginx用戶便于管理cd /opt/
wget http://nginx.org/download/nginx-1.18.0.tar.gz
#官網下載安裝包tar xf nginx-1.18.0.tar.gz
cd nginx-1.18.0/
#解壓軟件包
mkdir /apps/nginx -p./configure --help
#查看幫助模塊./configure --prefix=/apps/nginx \
--user=nginx \
--group=nginx \
--with-http_ssl_module \
--with-http_v2_module \
--with-http_realip_module \
--with-http_stub_status_module \
--with-http_gzip_static_module \
--with-pcre \
--with-stream \
--with-stream_ssl_module \
--with-stream_realip_modulemake
make installchown -R nginx.nginx /apps/nginx
#修改權限ll /apps/nginx/
total 0
drwxr-xr-x 2 root root 333 Sep 22 12:49 conf
drwxr-xr-x 2 root root ?40 Sep 22 12:49 html
drwxr-xr-x 2 root root ? 6 Sep 22 12:49 logs
drwxr-xr-x 2 root root ?19 Sep 22 12:49 sbin
注意:有一個報錯? ? yum?進程被占用
嘗試用? ?kull? -s9?強殺?也不行
解決辦法:?移走該進程
2,?重要文件詳細介紹
2.1?源碼包
-
contrib:vim 格式文件,修改nginx配置文件的格式,高亮 cp -r /opt/nginx-1.18.0/contrib/vim/* /usr/share/vim/vimfiles/
-
conf:配置文件
-
man:man幫助 man man/nginx.8 不加路徑看不了 nginx.8 文件
-
src:源碼包 點c 點h 結尾的文件 find src -type f |xargs cat |wc -l 193678 (統計源代碼多少行)?
-
objs? ?后面生成的文件夾? ?放二進制
2.2? 安裝完成后的文件
-
conf:保存nginx所有的配置文件,其中nginx.conf是nginx服務器的最核心最主要的配置文件,其他的.conf則是用來配置nginx相關的功能的,例如fastcgi功能使用的是fastcgi.conf和fastcgi_params兩個文件,配置文件一般都有個樣板配置文件,是文件名.default結尾,使用的使用將其復制為并將default去掉即可。
-
html目錄中保存了nginx服務器的web文件,但是可以更改為其他目錄保存web文件,另外還有一個50x的web文件是默認的錯誤頁面提示頁面。
-
logs:用來保存nginx服務器的訪問日志錯誤日志等日志,logs目錄可以放在其他路徑,比如/var/logs/nginx里面。
-
sbin:保存nginx二進制啟動腳本,可以接受不同的參數以實現不同的功能。
3,在使用nginx?前的準備工作
3.1?啟動停止nginx
做軟連接 為了可以不寫絕對路徑
3.2?改屬主數組?
3.3?加不能登錄的? nginx程序用戶
useradd -M -s /sbin/nologin nginx
3.4? 把? nginx?交給systemctl?管理
因為是編譯安裝,所以需要手搓Nginx 自啟動文件
#復制同一版本的nginx的yum安裝生成的service文件vim /usr/lib/systemd/system/nginx.service
#建立文件
[Unit]
Description=nginx - high performance web server
Documentation=http://nginx.org/en/docs/
After=network-online.target remote-fs.target nss-lookup.target
Wants=network-online.target
[Service]
Type=forking
PIDFile=/apps/nginx/logs/nginx.pid
#注意文件位置,如果不對 啟動不了
ExecStart=/apps/nginx/sbin/nginx -c /apps/nginx/conf/nginx.conf
#注意啟動文件位置
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s TERM $MAINPID
LimitNOFILE=100000[Install]
WantedBy=multi-user.target
(二)yum?安裝?nginx
centos7 需要安裝epel源
yum install -y epel-release
#安裝epel源 額外 rpeo
yum install nginx -y
六,? ? ? nginx命令
?(一)nginx?命令常見選項
1,nginx -v??顯示版本
2,nginx -V??顯示編譯詳細情況 模塊等信息
3,??nginx -t??nginx -T?測試配置文件是否有語法錯誤
4,nginx -h? 幫助
5,nginx -c? ?使用指定的配置文件
6,nginx -g? ?指定配置指令
7,?nginx -p? ?指定運行目錄
8,nginx -s? 發射信號
(二)nginx -s? 發射信號?詳細介紹
? ? ? ? ? ? ? ? ? 這兩個是等同的 | 含義 | |
nginx -s??stop | kill -s??SIGTERM | 直接停止 |
nginx -s??quit | kill -s? ?SIGQUIT | 優雅的退出:有人在訪問不會結束進程 |
nginx -s? ?reopen | kill -s? ??SIGUSR1 | 分割日志 |
nginx -s? ?reload | kill -s? ? SIGHUP? | 重新加載配置文件 |
注意:kill -l ?看信號大全
nginx -h ? 中可以看到的信號較少
可以使用man手冊來查看詳細的信號 如果沒安裝,去源碼包里找到man文件
man ? 路徑/nginx.8 ? ? ?不加路徑打不開man幫助
(三)分割日志
找到日志? ?在安裝路徑下的? logs? 文件夾里
access.log?為成功訪問的日志
將日志備份? 并新建一個access.log? 文件
查看目前的?文件大小
?客戶機再次訪問? ?發現日志并沒有放到新增的文件中,還是在備份的文件中
?輸入?nginx? -s?reopen? 或者kill ? -s ?USR1?子進程號
再次客戶機訪問? ? ? ?可以看到日志成功分割了
(四)nginx -g??指定配置 不已配置文件中的為準
nginx -g 指定配置 不已配置文件中的為準
1,nginx -g 'user zhangsan;' ? 已張三身份運行,默認是以nginx身份
2,nginx -g 'daemon off;' ? ? ?前臺運行命令
3,nginx -g 'worker_processes 1;'? ? ? ? ??只開一個工作進程
七,?熱升級nginx1.18? ?到nginx1.20
(一)步驟
-
將舊Nginx文件換成新Nginx文件(注意備份)
-
向master進程發送USR2信號
-
master進程修改pid文件名,加后綴.oldbin
-
master進程用新Nginx文件啟動新master進程,系統中將有新舊兩個Nginx主進程共同提供Web服務
-
向舊的Nginx服務進程發送WINCH信號,使舊的Nginx worker進程平滑停止,并刪除Nginx.pid.oldbin文件
-
向舊master進程發送QUIT信號,關閉老master
-
如果發現升級有問題,可以回滾向老master發送HUP,向新master發送QUIT
(二)實驗操作
1,從官網下載1.20.2?的包
2,?找到壓縮包
3,解壓
4,進到源碼包
5,./configure? 安裝模塊? ?(可以nginx? -V?直接復制)
注意:?這邊出現了這個問題? ?是解壓壓縮包時出錯? 重新下壓縮包再解壓就好了
6,make?編譯? ?不要make?install? !!!!!!!!!!
7,? 去到?objs? 文件夾? ?可以看到綠色的可執行文件
查看版本號? 為1.20.2
?
8,將低版本的nginx主程序改名
9,?將新版本 拷入進去
10,查看?現在的版本號? 發現已經改過來了
11,? 但是內存里還是1.8? ?所以需要熱升級
12,? 查看主進程號? 并 kill? -USR2? 主進程號? ? ?(在運行中升級)
13?就會生成一個新的master?和新的worker
框出來的是? ? 新的
14,生成一個測試文件? ? 讓客戶機來下載
15,?客戶機下載? ?并限速1M?每秒
16,?優雅關閉老進程的 ?worker 進程?
17? ,此時可以看到不會影響客戶機下載? ?且客戶機訪問看到的版本號也變過來了?
18? ,服務機?的進程? ?可以看到老的worker? 已經關閉
(三)回滾
就是把1.20的nginx?移走
再把老的nginx移回來
八,??配置文件詳細解釋
(一)配置文件位置
主配置文件:nginx.conf
子配置文件: include conf.d/*.conf
主配置文件貼心的有備份
(二)主配置文件架構? ?及格式
1,主配置文件架構
2,?詳細介紹?主配置文件部分
events? ??控制事件驅動?
http? ? ? ??web網頁配置有關
location? ??和url 有關
main block? ??主配置段,即全局配置段,對http,mail都有效
mail? ??協議相關配置段
stream? ??服務器相關配置段(負載均衡)
3,配置文件格式
關鍵字 值 ;? ? ?;結尾
(三)全局配置
nginx 有多種模塊
-
核心模塊:是 Nginx 服務器正常運行必不可少的模塊,提供錯誤日志記錄 、配置文件解析 、事件驅動機制 、進程管理等核心功能
-
標準HTTP模塊:提供 HTTP 協議解析相關的功能,比如: 端口配置 、 網頁編碼設置 、 HTTP響應頭設置 等等
-
可選HTTP模塊:主要用于擴展標準的 HTTP 功能,讓 Nginx 能處理一些特殊的服務,比如:Flash 多媒體傳輸 、解析 GeoIP 請求、 網絡傳輸壓縮 、 安全協議 SSL 支持等
-
郵件服務模塊:主要用于支持 Nginx 的 郵件服務 ,包括對 POP3 協議、 IMAP 協議和 SMTP協議的支持
-
Stream服務模塊: 實現反向代理功能,包括TCP協議代理
-
第三方模塊:是為了擴展 Nginx 服務器應用,完成開發者自定義功能,比如: Json 支持、 Lua 支持等
九 ,? ?主配置文件調優
(一)關閉版本號
在配置文件中? ?加入?server_tokens ?off;? ? 檢查語法
重新加載配置文件
客戶機?訪問? ?驗證
(二)?自定義版本號
1,修改注意事項
注意:去修改源碼,在安裝包里, 再重新編譯安裝
? ? ? ? ? ??先吧服務關閉,不然編譯不成功
2.?修改規則
注意:當主配置文件? ??server_tokens ?on;? ? 版本顯示的是源代碼包src/core/nginx.h? 里改的內容
? ? ? ? ? ?當主配置文件? ?server_tokens ?off;? ??版本顯示的源代碼包? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?src/http/ngx_http_header_filter_module.c? 里改的內容
3,實驗
1,先去到? 源碼包?src/core/nginx.h? ?改第13 14行
2,再去???源碼包src/http/ngx_http_header_filter_module.c? ?改49行
3,去到源碼包所在目錄? ?重新編譯安裝
4,重新加載配置文件
5,? 當主配置文件?server_tokens ?on;?客戶機顯示heihei/9999
6,? 當主配置文件??server_tokens ?off;? ?客戶機顯示?haha
(三)修改啟動的進程數
如果設置為auto ?就是你真實的cpu數量
設置為5?個? 可以看到有5個worker? ?
pid (進程號)? cmd(程序名)?psr(運行在那個cpu上 )
(四)cpu與work 進程 綁定??
1,意義
將Nginx工作進程綁定到指定的CPU核心,默認Nginx是不進行進程綁定的,綁定并不是意味著當前nginx進程獨占以一核心CPU,但是可以保證此進程不會運行在其他核心上,這就極大減少了nginx的工作進程在不同的cpu核心上的來回跳轉,減少了CPU對進程的資源分配與回收以及內存管理等,因此可以有效的提升nginx服務器的性能。
2,?實驗
cpu?序號:
CPU MASK: 00000001:0號CPU
? ? ? ? ? ? ? ? ? ? ?00000010:1號CPU
? ? ? ? ? ? ? ? ? ? ? ................
? ? ? ? ? ? ? ? ? ? ? 10000000:7號CPU
1,因為服務機目前? 就只有兩個cpu? 主配置文件只需要分配兩個cpu親緣性
2,服務機? 記得刷新配置文件
3,?為了查看實驗結果? ?客戶機壓力測試(ab? ?要先裝httpd)
4,?不停查看? 服務機的worker? 發現綁定cpu
?
(五)PID 路徑
一般不改
pid ?進程號文件位置可以自定義? ?在主配置文件
(六)nginx進程的優先級(work進程的優先級)
NI 越小 優先級越大? 可以看到目前ni?優先級都是0
主配置文件? 加ni? -20
重新加載配置文件? 并查看
(七)調試work進程打開的文件的個數
1,在主配置文件? 加上這一句
意思是所有的? worker?可以打開的文件數量為 65536
2,?nginx?程序允許了? ?但是linux的文件系統最大只默認打開1024個
3,需要改內核文件? ?添加這一行? 加到最后(注意數字不要特別大,會死機)
4,重啟
5,驗證
先到在站點目錄下生成大文件big.img
dd if=/dev/zero ?of=big.img ?bs=100M count=1
可以在?客戶機器上安裝壓力測試的工具寫一個壓力測試腳本
while : ;do ab -c 1000 -n 10000 http://192.168.217.66/big.img;sleep 1;done
服務機worker?fd?會產生很多? 請求文件
6,?注意!!!!
去worker 進程看一下
還是沒改 ,因為nginx 交給systemctl 管理了 要告訴systemctl
在nginx 的systemct啟動配置文件 加這一句話
(八)服務是否已后臺方式運行
服務進程: 一般都是后臺 一旦開啟 一直開啟 除非人為干預
在容器里 服務必須前臺
加入這一行? 前臺運行
(九)只有 master進程沒有 work進程
實際生產中使用較少
master_process off|on;
#是否開啟Nginx的master-worker工作模式,僅用于開發調試場景,默認為on