您现在的位置是:Instagram刷粉絲, Ins買粉絲自助下單平台, Ins買贊網站可微信支付寶付款 >
02 Keep如何查看已經訂閱的(keep賽事在哪訂閱)
Instagram刷粉絲, Ins買粉絲自助下單平台, Ins買贊網站可微信支付寶付款2024-06-21 19:22:21【】0人已围观
简介omanyopenfiles”這個問題,本文將在上一篇的基礎上,繼續探討和分析。“Toomanyopenfiles”這個錯誤其實很常見,想必大家早已對其有一定的了解,這里打算再簡單的介紹一下。很明顯,
“Too many open files”這個錯誤其實很常見,想必大家早已對其有一定的了解,這里打算再簡單的介紹一下。
很明顯,“Too many open files”即說明打開的文件(包括socket)數量過多,已經超出了系統設定給某個進程最大的文件描述符的個數,超過后即無法繼續打開新的文件,并且報這個錯誤。
首先,我們需要了解有關open files的基本知識。詳細的概念大家可以谷歌,網上也有各種各樣的解決辦法,這里只對open files做簡單的介紹和總結。
我們在linux上運行ulimit -a 后,出現:
如圖open files的個數為1024,很明顯這個值太小了(linux默認即為1024),當進程耗盡1024個文件或socket后,就會出現“Too many open files”錯誤。現實生產環境中這個值很容易達到,所以一般都會進行相應修改。
最簡單的修改方式是ulimit -n 65535,但這樣重啟系統后又會恢復。永久生效的方法是修改/etc/security/limits.買粉絲nf 文件,在最后加入:
修改完成后,重啟系統或者運行sysctl -p使之生效。
soft 和hard,表示對進程所能打開的文件描述符個數限制,其概念為:
他們的區別就是軟限制可以在程序的進程中自行改變(突破限制),而硬限制則不行(除非程序進程有root權限)。
上面的規則大家最好自己嘗試一下,以增加印象。
重啟后,運行ulimit -a,可以看到open files 的值改變為:
簡單介紹完open files,我們再來了解下file-max。這個參數相信有很多人經常與ulimit中的open files混淆,他們的區別我們必須了解。
file-max 從字面意思就可以看出是文件的最大個數,運行cat /proc/sys/fs/file-max,可以看到:
這表示當前系統所有進程一共可以打開的文件數量為387311。請務必注意”系統所有進程"這幾個字。
運行 vim /etc/sysctl.買粉絲nf ,有時候你會看到類似:fs.file-max = 8192。出現這個則表示用戶手動設置了這個值,沒有則系統會有其默認值。手動設置的話,只需要在sysctl.買粉絲nf 中加上上述語句即可。
回到ulimit中的open files,它與file-max的區別就是:opem filese表示當前shell以及由它啟動的進程的文件描述符的限制,也就是說ulimit中設置的open files,只是當前shell及其子進程的文件描述符的限定。是否清楚?可以簡單的理解為:
好了,對于 file-max與open files的簡單介紹到此為止。現在的問題就是,“Too many open files”到底是碰到哪個設置的雷區造成的。
結合上一篇,我們知道sentinel主要在執行accept函數時出現了“Too many open files”錯誤,熟悉accept這個系統調用的朋友很清楚,accept會接收客戶端的請求,成功的話會建立連接,并返回新的socket描述符。所以,我們確定這里的“Too many open files”指的即是socket的數目過多。
我們猜測,是否是有大量的Jedis連接同時存在,耗盡服務器的socket資源,導致新的連接請求無法建立。所以,我們查看一下sentinel服務器的TCP連接,運行:買粉絲stat -anp | grep 26379,得到:
由上圖可以發現,有非常多處于ESTABLISHED狀態的TCP連接,運行 買粉絲stat -anp | grep 118:26379 | wc -l查看他們的個數:
可以看到,Sentinel同時維持了4071個TCP連接,而且過了很久之后,仍然是這么多,不會有大幅變化。
這個值很大,看似一切正常。繼續運行sudo cat /proc/5515/limits,發現:
看到上圖,我們似乎發現了端倪,這里的hard和soft都是4096,與前面的4072比較接近。為什么會這么低?我們繼續查看一下ulimit,運行ulimit -a :
可以看到,ulimit中open files 的設置為64000,為什么會不一致?按理說sentinel應該最大有64000+的open files。
對于這個矛盾,一開始我怎么也想不明白。最后我推測:應該是在最早啟動sentinel啟動的時候,系統的設置為4096,sentinel啟動之后,又在某個時間又改為64000,而sentinel進程確保持原有設置,從而導致很快達到限制。
我馬上查看了進程的啟動時間,運行ps -eo pid,lstart,etime | grep 5515:
發現進程啟動于2015年12月2日,接著再次運行 ll /etc/security/limits.買粉絲nf:
發現確實在2016年4月改動過, 然后我買粉絲了運維人員,他們告知我,確實改動過,但由多少改動到多少,他們也忘了。。。
為了了解Sentinel啟動時的狀況,緊接著查看了Sentinel的日志,下面是Sentinel啟動時打印的畫面:
上圖說明了進程是2015年12月2日啟動的,特別注意最開頭的幾行,非常關鍵:
這幾句的意思是:
問題很清楚了,redis sentinel最大可以支持10000個客戶端,也就是10032個文件描述符,但由于當前被人為限制到4096 了,所以,自動降低了標準。
因此,我猜測,最早open files的限制為4096時,Sentinel已經啟動了,只要進程啟動,改多少都沒有用。很明顯,在生產環境上,4096個連接請求很快就會達到。
接著,我繼續查看了Sentinel的配置文件,如下圖所示:
上圖中, “Generated by CONFIG REWRITE”之前的都是是人工配置,其后為Sentinel自動重寫的配置。
熟悉Redis的朋友都知道。Sentinel可能會對其配置文件進行更新重寫:
我們很快注意到了maxclients 4064這個配置項,此時我很迷惑。我們知道,在Sentinel中是無法手動運行買粉絲nfig set命令的,那這個4096必然不是來自于人工配置,Sentinel為什么要自動重寫4064這個值。其實,仔細發現,這里Sentinel限制了最多4064個連接,加上32個預留,剛好為4096。
于是,綜上,我猜測,Sentinel在啟動的時候發現自己的10032個open files的預期與事實設置的4096不符,所以被迫遵守4096,減去預留的32,最終maxclients 只有4064,并且之后因為某些原因重寫了配置,所以輸出了這個值。
好吧,我的一貫作風,先猜測,再讓源碼說話。
我們可以通過異常信息定位異常所處源碼,所以我搜索了前面提到的Sentinel在啟動時打印的關于maxclients 的日志信息中的文本,如“You requested maxclients of ...”。
這個異常出現在adjustOpenFilesLimit函數,通過函數名可以清楚它的作用,然后發現它的調用鏈只是:
``main()->initServer()->adjustOpenFilesLimit()```
所以,可以確定,在Sentinel服務器啟動并進行初始化的時候,會調用adjustOpenFilesLimit函數對open files個數進行調整。調整策略是什么呢?我們查看源碼:
在第1行中,REDIS_MIN_RESERVED_FDS即預留的32,是Sentinel保留的用于額外的的操作,如listening sockets, log files 等。同時,這里讀取了server.maxclients的值,看來server.maxclients具有初始化值,通過經過定位源碼,發現調用鏈:
即Sentinel在啟動時,調用initServerConfig()初始化配置,執行了server.maxclients = REDIS_MAX_CLIENTS(REDIS_MAX_CLIENTS為10000),所以server.maxclients就有了初始值10000。
回到adjustOpenFilesLimit()函數,adjustOpenFilesLimit最終目的就是得到適合的soft,并存在server.maxclients中,因為該函數比較重要,下面專門作出解釋:
1 先得到maxfiles的初始值,即Sentinel的期望10032
2 然后獲取進程當前的soft和hard,并存入limit ,即執行getrlimit(RLIMIT_NOFILE,&limit) :
調整過程為:
1 先用oldlimit變量保存進程當前的soft的值(如4096)
2 然后,判斷oldlimit<maxfiles ,如果真,表示當前soft達不到你要求,需要調整。調整的時候,策略是從最大值往下嘗試,以逐步獲得Sentinel能申請到的最大soft。
嘗試過程為:
1 首先f保存要嘗試的soft值,初始值為maxfiles (10032),即從10032開始調整。
2 然后開始一個循環判斷,只要f大于oldlimit,就執行一次setrlimit(RLIMIT_NOFILE,&limit) ,然后f減16:
這樣,用這種一步一步嘗試的方法,最終可用得到了Sentiel能獲得的最大的soft值,最后減去32再保存在server.maxclients中。
另外,當得到Sentinel能獲得的最合適的soft值f后,還要判斷f與oldlimit(系統最初的soft限制,假設為4096),原因如下:
也許會直到f==4096才設置成功,但也會出現f<4096的情況,這是因為跨度為16,最后一不小心就減多了,但最后的soft值不應該比4096還小。所以,f=oldlimit就是這個意思。
最后,還有一個判斷:
上面的過程我們用簡單的表示為:
adjustOpenFilesLimit()的分析到此結束。但有一點一定要明確,adjustOpenFilesLimit()只會在Sentinel初始化的時候執行一次,目的就是將最合適的soft保存到了server.maxclients (第xx行),以后不會再調用。這樣,一旦設置了server.maxclients ,只要Sentinel不重啟,這個值就不會變化,這也就解釋了為什么Sentinel啟動之后再改變open files沒有效果的原因了。
那什么時候發生了重寫呢
很赞哦!(55351)
相关文章
- 07 youtube mp3 music editor(2007年影響人類生活的十大IT產品)
- 01 訂閱轉換服務地址配置錯誤網絡(在線訂閱轉換工具怎么使用)
- 07 youtube mp3 application windows(求一個能看視頻參數的軟件)
- 07 my music mix on youtube music(大家來幫忙推薦好歌 高分)
- 01 訂閱鏈接在哪里找(怎么在買粉絲訂閱號文章里找到鏈接?)
- 07 youtube dis買粉絲 music 80(功夫熊貓片頭曲涉及哪些朝代哪些事件)
- 01 訂閱鏈接轉買粉絲軟件介紹模板(vmess如何轉換)
- 07 youtube 80's r and b(一個國外的十多歲的男孩吧!唱過一首歌叫《Baby》.我想知道他的個人資料)
- 01 訂閱鏈接是什么意思呢酒吧(買粉絲里的訂閱號是什么)
- 01 訂閱鏈接轉買粉絲規則配置文件選哪個(vmess如何轉換)
热门文章
站长推荐
07 part of loading貿易術語(國際貨物買賣合同參考格式(中、英))
01 訂閱鏈接轉買粉絲軟件怎么傳到(vmess如何轉換)
01 訂閱鏈接轉換yaml(vmess如何轉換)
07 no ads on youtube(老外怎么看待中國的武俠?葵花寶典,九陰真經,降龍十八掌。。。)
01 訂閱鏈接轉買粉絲規則編寫(vmess如何轉換)
01 訂閱鏈接轉買粉絲規則配置教程來了(opencash配置訂閱失敗)
07 youtube music app download 買粉絲 pc game(幫忙翻譯一段IPHONE廣告)
07 youtube change playlist name(幫忙翻譯一段IPHONE廣告)