記一次nginx module 除錯

參考了

先進入nginx工作目錄 /usr/local/nginx/sbin/

使用gdb -q -tui（q選項是以安靜模式啟動，不顯示gdb版本等資訊。tui選項可以顯示**介面）

然後在gdb中啟動nginx shell ./nginx

啟動之後，可以檢視當前nginx中的程序號：shell pidof nginx

也可以使用ps -ef|grep nginx 檢視（在另乙個視窗中）

可以使用attach命令跟蹤子程序 attach

可以發現子程序即worker程序在執行後會停留在epoll_wait處等待相應的事件發生

測試之前的hello module

首先給hello module中的ngx_http_hello_handler函式打上斷點，也就是這種handler模組的處理函式，這種函式是真正用來處理請求並發回響應包體給客戶端的。使用 b ngx_http_hello_handler打斷點。（使用i b可以查詢斷點）然後用命令c讓nginx一直執行，直到遇到第乙個斷點。(使用delete breakpoint b_num刪除斷點，如delete breakpoint 1)

使用bt顯示當前函式的呼叫棧，使用frame n（eg:frame 1）可進入具體某一幀

然後可以在另乙個終端中輸入 wget 100.100.60.199/hello或者使用postman 如圖

send即可，然後就可以看到**介面了。

使用n命令向下執行，主要是跟蹤最後呼叫的輸出函式return ngx_http_output_filter，執行到這一句時使用s命令進入該函式

繼續執行到rc=ngx…這句，再次使用s命令進入該函式

發現進入的是這個ngx_http_range_body_filter函式，繼續執行發現進入了ctx==null這句，使用p ctx可以檢視ctx的值，是0x0,進入ngx_http_next_body_filter函式，發現進入了ngx_http_copy_filter函式

最後執行到rc=…時，進入ngx_output_chain函式，

繼續執行，發現進入了in->next==null分支，可以使用p in->next檢視，然後進入output_filter，發現進入了ngx_http_trailers_filter函式

這裡就不一一截圖了，就是很多filter函式在把處理往下推，大致程序如下

上方為呼叫（進入）的函式，下方為進入時的條件，可以看到，最後請求的處理被丟給了ngx_http_write_filter函式，該函式在執行到

時，使用s命令進入，發現進入了ngx_linux_sendfile_chain函式，該函式呼叫了ngx_output_chain_to_iovec函式，大致的流程如下

最後在ngx_writev函式中呼叫了writev函式，執行到這一步時postman中收到了輸出。

writev函式介紹，參照

writev函式：是posix提供的乙個比write函式更加高階的writev，在很多場景下，它相對於write有一定的優勢。大體而言，write面向的是連續記憶體塊，writev面向的是分散的資料塊，兩個函式的最終結果都是將內容寫入連續的空間。分散的資料塊，顯然與nginx鏈式輸出的規則符合。

函式原型：writev(int fd, struct iovect* iov, int iovcnt);

iov_base就是每個pair的基址，iov_len則是長度，不用包含「0」。

ngx_iovec_t結構體的定義

typedef struct ngx_iovec_t;

iovec結構體

#include

struct iovec {

ptr_t iov_base; /* starting address */

size_t iov_len; /* length in bytes */

記一次nginx module 除錯

記一次uwsgi django nginx 調優

記一次調bug記錄 15 4 17

記一次oracle sql調優過程

記一次nginx module 除錯

記一次uwsgi django nginx 調優

記一次調bug記錄 15 4 17

記一次oracle sql調優過程

相關推薦