Microsoft Office Access是由微軟發布的關系數據庫管理系統。它結合了 MicrosoftJet Database Engine 和 圖形用戶界面兩項特點,是 Microsoft Office 的系統程序之一。Microsoft Office Access是微軟把數據庫引擎的圖形用戶界面和軟件開發工具結合在一起的一個數據庫管理系統。它是微軟OFFICE的一個成員, 在包括專業版和更高版本的office版本里面被單獨出售。2018年9月25日,最新的微軟Office Access 2019在微軟Office 2019里發布。 nginx配置中有關日志的配置主要是圍繞著下面兩個指令: 1、error_log 2、access_log:記錄訪問日志 首先要強調的一點是,如果access日志和error日志都是常量文件名(因為access支持變量文件名,后續會講到),那么nginx進程會緩存文件描述符直到進程結束。 什么時候日志的fd會改變呢? 1)進程重啟 2)收到了NGX_REOPEN_SIGNAL信號,會產生新的日志文件 其他情況下,日志的fd不變,所以當進程運行中,刪除了日志文件的話,并不會生成新的日志文件,且日志都會丟失 下面詳細講一下這兩個指令的來龍去脈 一:先說error_log: nginx有兩個模塊支持error_log指令: 一個是 ngx_errlog_module ,這個模塊只有一個指令,就是error_log ,配置類型為:NGX_MAIN_CONF,回調函數為:ngx_error_log; 另一個是 ngx_http_core_module,這個模塊中也有指令:error_log ,配置類型為:NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF,回調函數為:ngx_http_core_error_log。 static ngx_command_t ngx_errlog_commands[] = { {ngx_string("error_log"), NGX_MAIN_CONF|NGX_CONF_1MORE, ngx_error_log, 0, 0, NULL}, ngx_null_command }; static ngx_command_t ngx_http_core_commands[] = { { ngx_string("error_log"), NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_CONF_1MORE, ngx_http_core_error_log, NGX_HTTP_LOC_CONF_OFFSET, 0, NULL }, } 這樣會產生幾個疑問: 1:為什么需要兩個相同的指令實現相同的功能。 2:兩個指令的類型均支持NGX_HTTP_MAIN_CONF ,那么在main中配置的error_log到底使用的是哪一個 3:兩者的作用關系。 下面來解釋一下: nginx在進行模塊注冊時,會發現 ngx_errlog_module 模塊是先于 ngx_http_core_module 模塊注冊的 。 在nginx在解析配置文件的時候 ,見到 error_log,會按照注冊模塊的順序查找指令,這樣,會先找到ngx_errlog_module模塊,如果此時,error_log是在main配置的,那么和ngx_errlog_module模塊error_log的NGX_HTTP_MAIN_CONF match,執行ngx_error_log。 如果error_log是在http{}配置的,也會按照注冊模塊的順序查找指令,找到ngx_errlog_module模塊的error_log,發現type是NGX_HTTP_MAIN_CONF,不match,繼續往下找,找到ngx_http_core_module的error_log,type是NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF ,match后執行ngx_http_core_error_log。 上面提到了ngx_error_log 和 ngx_http_core_error_log兩個函數,這兩個函數的功能基本一致,但是因為兩個配置作用域不同,所以配置存儲位置不同:ngx_errlog_module存儲在cycle->new_log,ngx_http_core_module存儲在http core模塊數據結構ngx_http_core_loc_conf_s的error_log(在此簡寫成:clcf->error_log)。 clcf->error_log是http模塊中的,其主要記錄和http請求相關的日志。 cycle->new_log主要記錄如進程啟動,event等。 但是主進程啟動的時候,此時還沒有讀取配置文件,即沒有指定日志打印在哪里。nginx這時候雖然可以將一些出錯內容或者結果輸到標準輸出,但是如果要記錄一些系統初始化情況,socket監聽狀況,還是需要寫到日志文件中去的。在nginx的main函數中,首先會調用ngx_log_init 函數,默認日志文件為:安裝路徑/logs/error.log,如果這個文件沒有權限訪問的話,會直接報錯退出。在mian函數結尾處,在ngx_master_process_cycle函數調用之前,會close掉這個日志文件。 如果只在main配置了error_log,http{}中沒有設置,那么clcf->error_log賦值為clcf->error_log,如下: static char * ngx_http_core_merge_loc_conf(ngx_conf_t *cf, void *parent, void *child) { ngx_http_core_loc_conf_t *prev = parent; ngx_http_core_loc_conf_t *conf = child; 。。。。。。 if (conf->error_log == NULL) { if (prev->error_log) { conf->error_log = prev->error_log; } else { conf->error_log = &cf->cycle->new_log; } } 。。。。。。 } 那為什么不把兩個指令合并到一起呢。 首先看一下模塊注冊順序: ngx_module_t *ngx_modules[] = { &ngx_core_module, &ngx_errlog_module, &ngx_conf_module, &ngx_events_module, &ngx_event_core_module, &ngx_rtsig_module, &ngx_epoll_module, &ngx_regex_module, &ngx_http_module, &ngx_http_core_module, &ngx_http_log_module, ...... } 可見ngx_errlog_module 和 ngx_http_core_module中間有n多模塊。這些模塊是獨立于http的,而且需要日志的打印,這些日志肯定是需要記錄的。 則此模塊不可省,那么考慮把ngx_http_core_module的error_log合并過來呢,想想也不行,為什么呢? 想想ngx_errlog_module將error_log信息存在哪里,想想ngx_http_core_module的error_log信息存在哪里。 在調用ngx_error_log時候,把針對不同server或者location的error_log信息存儲在哪里。(模塊之間不能深度耦合) 為了兩個模塊互不影響,這是個好辦法呀! 二:access_log 接下來看一下access_log,access_log指令是屬于ngx_http_log_module模塊。 ngx_http_log_module有三個指令: static ngx_command_t ngx_http_log_commands[] = { { ngx_string("log_format"), NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_CONF_2MORE, ngx_http_log_set_format, NGX_HTTP_MAIN_CONF_OFFSET, 0, NULL }, { ngx_string("access_log"), NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_HTTP_LIF_CONF |NGX_HTTP_LMT_CONF|NGX_CONF_TAKE123, ngx_http_log_set_log, NGX_HTTP_LOC_CONF_OFFSET, 0, NULL }, { ngx_string("open_log_file_cache"), NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_CONF_TAKE1234, ngx_http_log_open_file_cache, NGX_HTTP_LOC_CONF_OFFSET, 0, NULL }, ngx_null_command }; 每個block都可以配置上面的指令 ,這些指令對應著各個block配置中的loc[ngx_http_log_module.index](要理解這個,需要知道配置文件的整個解析過程和block對應關系),即下面這個數據結構: typedef struct { ngx_array_t *logs; /* array of ngx_http_log_t */ ngx_open_file_cache_t *open_file_cache; time_t open_file_cache_valid; ngx_uint_t open_file_cache_min_uses; ngx_uint_t off; /* unsigned off:1 */ } ngx_http_log_loc_conf_t; 關于access_log主要有以下幾個點: 1、ngx_http_log_module是屬于nginx狀態機最后一個階段NGX_HTTP_LOG_PHASE的處理模塊,即一個http請求結束時執行的,它的任務就是打印這次request的訪問情況。 2、access_log支持根據變量指令路徑,如: access_log logs/'$remote_addr'access.log main; 3、不管是變量路徑還是常量路徑,都將信息放入了 ngx_http_log_loc_conf_t的logs這個數組里進行管理,logs數組的元素是ngx_http_log_t。 typedef struct { ngx_open_file_t *file; ngx_http_log_script_t *script; time_t disk_full_time; time_t error_log_time; ngx_http_log_fmt_t *format; } ngx_http_log_t; 當是常量的時候使用file記錄,這個文件記錄會放入到cycle->open_files struct ngx_open_file_s { ngx_fd_t fd; ngx_str_t name; u_char *buffer; u_char *pos; u_char *last; }; 當是變量的時候使用script記錄 typedef struct { ngx_array_t *lengths; ngx_array_t *values; } ngx_http_log_script_t; 4、不管是error_log還是access_log,nginx都是通過保存文件句柄來進行快速寫日志文件的。但是因為access_log支持根據變量指令路徑,如果按照request或者ip來分隔不同的access日志,那么可想而至,若還按照保存文件句柄的方式來寫日志文件,會造成系統fd的大量占用。nginx在此進行了優化: 1)如果用常量指定acess日志路徑: access_log logs/access.log main; 那么和error_log一樣,將文件路徑名稱放到cycle->open_files中去,這是個list,在路徑加入這個list的時候會進行除重操作的。在所有的模塊初始化完畢,會依次打開這些文件路徑,獲取到fd,以備打印日志使用。 打印日志的時候調用函數:ngx_write_fd 2)如果用變量指定acess日志路徑: 使用script標記日志文件為變量文件名的。 打印日志的時候調用函數:ngx_http_log_script_write 在這個函數里,體現出了對緩存fd的管理。這些和指令open_file_log_cache的配置是息息相關的(后面會詳細介紹)。 打日志的函數: static void ngx_http_log_write(ngx_http_request_t *r, ngx_http_log_t *log, u_char *buf, size_t len) { u_char *name; time_t now; ssize_t n; ngx_err_t err; if (log->script == NULL) { name = log->file->name.data; n = ngx_write_fd(log->file->fd, buf, len); } else { name = NULL; n = ngx_http_log_script_write(r, log->script, &name, buf, len); } ...... } 5、說到緩存文件描述符,nginx有兩個指令是管理緩存文件描述符的 一個就是本文中說到的ngx_http_log_module模塊的open_file_log_cache; 一個是ngx_http_core_module模塊的 open_file_cache; 前者是只用來管理access變量日志文件。 后者用來管理的就多了,包括:static,index,tryfiles,gzip,mp4,flv,看到了沒,都是靜態文件哦! 這兩個指令的handler都調用了函數 ngx_open_file_cache_init ,這就是用來管理緩存文件描述符的第一步:初始化 ngx_open_file_cache_t * ngx_open_file_cache_init(ngx_pool_t *pool, ngx_uint_t max, time_t inactive) { ngx_pool_cleanup_t *cln; ngx_open_file_cache_t *cache; cache = ngx_palloc(pool, sizeof(ngx_open_file_cache_t)); if (cache == NULL) { return NULL; } ngx_rbtree_init(&cache->rbtree, &cache->sentinel, ngx_open_file_cache_rbtree_insert_value); ngx_queue_init(&cache->expire_queue); cache->current = 0; cache->max = max; cache->inactive = inactive; cln = ngx_pool_cleanup_add(pool, 0); if (cln == NULL) { return NULL; } cln->handler = ngx_open_file_cache_cleanup; cln->data = cache; return cache; } 可以看到nginx管理緩存文件描述符,使用了紅黑樹和隊列,這個后續還是作為一篇文章來敘述吧,涉及的內容有點多,本文還是以分析日志模塊為主。 6、說一下指令 open_file_log_cache 1)nginx下默認這個指令的配置是:open_file_log_cache off; 也就是說不對access變量日志文件的fd做緩存,每寫一個文件就打開,然后寫日志。那么這個文件fd什么時候關閉呢。 這就涉及到nginx內存管理的cleanup了,cleanup可以注冊,在內存池被銷毀的時候,調用cleanup鏈表中各個cleanup的handler(詳細可以去翻閱nginx內存池管理) 而此時的文件fd就是在request完畢后,銷毀內存池的時候,關閉fd。 配置open_log_file_cache off; 時的運行 這是獲取access變量文件fd的函數,返回值應該是access日志的fd。 ngx_int_t ngx_open_cached_file(ngx_open_file_cache_t *cache, ngx_str_t *name, ngx_open_file_info_t *of, ngx_pool_t *pool) { time_t now; uint32_t hash; ngx_int_t rc; ngx_file_info_t fi; ngx_pool_cleanup_t *cln; ngx_cached_open_file_t *file; ngx_pool_cleanup_file_t *clnf; ngx_open_file_cache_cleanup_t *ofcln; of->fd = NGX_INVALID_FILE; of->err = 0; //配置open_log_file_cache off的話,cache為空 if (cache == NULL) { ...... //添加一個cleanup cln = ngx_pool_cleanup_add(pool, sizeof(ngx_pool_cleanup_file_t)); if (cln == NULL) { return NGX_ERROR; } //打開日志文件,獲得fd rc = ngx_open_and_stat_file(name, of, pool->log); rc = ngx_open_and_stat_file(name, of, pool->log); //打開日志文件成功 if (rc == NGX_OK && !of->is_dir) { //添加cleanup回調,在銷毀內存池的時候調用ngx_pool_cleanup_file,函數內采用了close關閉fd cln->handler = ngx_pool_cleanup_file; clnf = cln->data; clnf->fd = of->fd; clnf->name = name->data; clnf->log = pool->log; } return rc; } ...... } 2)如果配置open_file_log_cache的話,支持四種參數: max = N [ inactive = time ] [ min_uses = N ] [ valid = time ] max 最大緩存文件描述符數量 inactive 在多少時間內不活動,就會被刪除 min_uses 必須在 inactive時間內活動N次,才會被緩存 valid 檢查inactive的時間。 具體的緩存文件fd的來龍去脈值得用一篇文章來詳細描述,在這里就暫且不說了,希望最近有時間整理出來。 The End Microsoft Access在很多地方得到廣泛使用,例如小型企業,大公司的部門。 |
溫馨提示:喜歡本站的話,請收藏一下本站!