服務(wù)器病了嗎? Linux 服務(wù)器的那些性能參數(shù)指標(biāo)

發(fā)表于 討論求助 2023-05-10 14:56:27

來(lái)源:Linux愛(ài)好者

ID:LinuxHub

一個(gè)基于 Linux 操作系統(tǒng)的服務(wù)器運(yùn)行的同時(shí),也會(huì)表征出各種各樣參數(shù)信息。通常來(lái)說(shuō)運(yùn)維人員、系統(tǒng)管理員會(huì)對(duì)這些數(shù)據(jù)會(huì)極為敏感,但是這些參數(shù)對(duì)于開(kāi)發(fā)者來(lái)說(shuō)也十分重要,尤其當(dāng)你的程序非正常工作的時(shí)候,這些蛛絲馬跡往往會(huì)幫助快速定位跟蹤問(wèn)題。

這里只是一些簡(jiǎn)單的工具查看系統(tǒng)的相關(guān)參數(shù),當(dāng)然很多工具也是通過(guò)分析加工 /proc、/sys 下的數(shù)據(jù)來(lái)工作的,而那些更加細(xì)致、專業(yè)的性能監(jiān)測(cè)和調(diào)優(yōu),可能還需要更加專業(yè)的工具(perf、systemtap 等)和技術(shù)才能完成哦。畢竟來(lái)說(shuō),系統(tǒng)性能監(jiān)控本身就是個(gè)大學(xué)問(wèn)。



一、CPU和內(nèi)存類

1.1?top

? ~ top

第一行后面的三個(gè)值是系統(tǒng)在之前 1、5、15 的平均負(fù)載,也可以看出系統(tǒng)負(fù)載是上升、平穩(wěn)、下降的趨勢(shì),當(dāng)這個(gè)值超過(guò) CPU 可執(zhí)行單元的數(shù)目,則表示 CPU 的性能已經(jīng)飽和成為瓶頸了。


第二行統(tǒng)計(jì)了系統(tǒng)的任務(wù)狀態(tài)信息。running 很自然不必多說(shuō),包括正在 CPU 上運(yùn)行的和將要被調(diào)度運(yùn)行的;sleeping 通常是等待事件(比如 IO 操作)完成的任務(wù),細(xì)分可以包括 interruptible 和 uninterruptible 的類型;stopped 是一些被暫停的任務(wù),通常發(fā)送 SIGSTOP 或者對(duì)一個(gè)前臺(tái)任務(wù)操作 Ctrl-Z 可以將其暫停;zombie 僵尸任務(wù),雖然進(jìn)程終止資源會(huì)被自動(dòng)回收,但是含有退出任務(wù)的 task descriptor 需要父進(jìn)程訪問(wèn)后才能釋放,這種進(jìn)程顯示為 defunct 狀態(tài),無(wú)論是因?yàn)楦高M(jìn)程提前退出還是未 wait 調(diào)用,出現(xiàn)這種進(jìn)程都應(yīng)該格外注意程序是否設(shè)計(jì)有誤。

第三行 CPU 占用率根據(jù)類型有以下幾種情況:

  • (us) user:CPU 在低 nice 值(高優(yōu)先級(jí))用戶態(tài)所占用的時(shí)間(nice<=0)。正常情況下只要服務(wù)器不是很閑,那么大部分的 CPU 時(shí)間應(yīng)該都在此執(zhí)行這類程序

  • (sy) system:CPU 處于內(nèi)核態(tài)所占用的時(shí)間,操作系統(tǒng)通過(guò)系統(tǒng)調(diào)用(system call)從用戶態(tài)陷入內(nèi)核態(tài),以執(zhí)行特定的服務(wù);通常情況下該值會(huì)比較小,但是當(dāng)服務(wù)器執(zhí)行的 IO 比較密集的時(shí)候,該值會(huì)比較大

  • (ni) nice:CPU 在高 nice 值(低優(yōu)先級(jí))用戶態(tài)以低優(yōu)先級(jí)運(yùn)行占用的時(shí)間(nice>0)。默認(rèn)新啟動(dòng)的進(jìn)程 nice=0,是不會(huì)計(jì)入這里的,除非手動(dòng)通過(guò) renice 或者 setpriority() 的方式修改程序的nice值

  • (id) idle:CPU 在空閑狀態(tài)(執(zhí)行 kernel idle handler )所占用的時(shí)間

  • (wa) iowait:等待 IO 完成做占用的時(shí)間

  • (hi) irq:系統(tǒng)處理硬件中斷所消耗的時(shí)間

  • (si) softirq:系統(tǒng)處理軟中斷所消耗的時(shí)間,記住軟中斷分為 softirqs、tasklets (其實(shí)是前者的特例)、work queues,不知道這里是統(tǒng)計(jì)的是哪些的時(shí)間,畢竟 work queues 的執(zhí)行已經(jīng)不是中斷上下文了

  • (st) steal:在虛擬機(jī)情況下才有意義,因?yàn)樘摂M機(jī)下 CPU 也是共享物理 CPU 的,所以這段時(shí)間表明虛擬機(jī)等待 hypervisor 調(diào)度 CPU 的時(shí)間,也意味著這段時(shí)間 hypervisor 將 CPU 調(diào)度給別的 CPU 執(zhí)行,這個(gè)時(shí)段的 CPU 資源被“stolen”了。這個(gè)值在我 KVM 的 VPS 機(jī)器上是不為 0 的,但也只有 0.1 這個(gè)數(shù)量級(jí),是不是可以用來(lái)判斷 VPS 超售的情況?


CPU 占用率高很多情況下意味著一些東西,這也給服務(wù)器 CPU 使用率過(guò)高情況下指明了相應(yīng)地排查思路:

  1. 當(dāng) user 占用率過(guò)高的時(shí)候,通常是某些個(gè)別的進(jìn)程占用了大量的 CPU,這時(shí)候很容易通過(guò) top 找到該程序;此時(shí)如果懷疑程序異常,可以通過(guò) perf 等思路找出熱點(diǎn)調(diào)用函數(shù)來(lái)進(jìn)一步排查;

  2. 當(dāng) system 占用率過(guò)高的時(shí)候,如果 IO 操作(包括終端 IO)比較多,可能會(huì)造成這部分的 CPU 占用率高,比如在 file server、database server 等類型的服務(wù)器上,否則(比如>20%)很可能有些部分的內(nèi)核、驅(qū)動(dòng)模塊有問(wèn)題;

  3. 當(dāng) nice 占用率過(guò)高的時(shí)候,通常是有意行為,當(dāng)進(jìn)程的發(fā)起者知道某些進(jìn)程占用較高的 CPU,會(huì)設(shè)置其 nice 值確保不會(huì)淹沒(méi)其他進(jìn)程對(duì) CPU 的使用請(qǐng)求;

  4. 當(dāng) iowait 占用率過(guò)高的時(shí)候,通常意味著某些程序的 IO 操作效率很低,或者 IO 對(duì)應(yīng)設(shè)備的性能很低以至于讀寫(xiě)操作需要很長(zhǎng)的時(shí)間來(lái)完成;

  5. 當(dāng) irq/softirq 占用率過(guò)高的時(shí)候,很可能某些外設(shè)出現(xiàn)問(wèn)題,導(dǎo)致產(chǎn)生大量的irq請(qǐng)求,這時(shí)候通過(guò)檢查 /proc/interrupts 文件來(lái)深究問(wèn)題所在;

  6. 當(dāng) steal 占用率過(guò)高的時(shí)候,黑心廠商虛擬機(jī)超售了吧!


第四行和第五行是物理內(nèi)存和虛擬內(nèi)存(交換分區(qū))的信息:
total = free + used + buff/cache,現(xiàn)在buffers和cached Mem信息總和到一起了,但是buffers和cached

Mem 的關(guān)系很多地方都沒(méi)說(shuō)清楚。其實(shí)通過(guò)對(duì)比數(shù)據(jù),這兩個(gè)值就是 /proc/meminfo 中的 Buffers 和 Cached 字段:Buffers 是針對(duì) raw disk 的塊緩存,主要是以 raw block 的方式緩存文件系統(tǒng)的元數(shù)據(jù)(比如超級(jí)塊信息等),這個(gè)值一般比較小(20M左右);而 Cached 是針對(duì)于某些具體的文件進(jìn)行讀緩存,以增加文件的訪問(wèn)效率而使用的,可以說(shuō)是用于文件系統(tǒng)中文件緩存使用。

而 avail Mem 是一個(gè)新的參數(shù)值,用于指示在不進(jìn)行交換的情況下,可以給新開(kāi)啟的程序多少內(nèi)存空間,大致和 free + buff/cached 相當(dāng),而這也印證了上面的說(shuō)法,free + buffers + cached Mem才是真正可用的物理內(nèi)存。并且,使用交換分區(qū)不見(jiàn)得是壞事情,所以交換分區(qū)使用率不是什么嚴(yán)重的參數(shù),但是頻繁的 swap in/out 就不是好事情了,這種情況需要注意,通常表示物理內(nèi)存緊缺的情況。


最后是每個(gè)程序的資源占用列表,其中 CPU 的使用率是所有 CPU core 占用率的總和。通常執(zhí)行 top 的時(shí)候,本身該程序會(huì)大量的讀取 /proc 操作,所以基本該 top 程序本身也會(huì)是名列前茅的。

top 雖然非常強(qiáng)大,但是通常用于控制臺(tái)實(shí)時(shí)監(jiān)測(cè)系統(tǒng)信息,不適合長(zhǎng)時(shí)間(幾天、幾個(gè)月)監(jiān)測(cè)系統(tǒng)的負(fù)載信息,同時(shí)對(duì)于短命的進(jìn)程也會(huì)遺漏無(wú)法給出統(tǒng)計(jì)信息。


1.2?vmstat


vmstat 是除 top 之外另一個(gè)常用的系統(tǒng)檢測(cè)工具,下面截圖是我用-j4編譯boost的系統(tǒng)負(fù)載。

r 表示可運(yùn)行進(jìn)程數(shù)目,數(shù)據(jù)大致相符;而b表示的是 uninterruptible 睡眠的進(jìn)程數(shù)目;swpd 表示使用到的虛擬內(nèi)存數(shù)量,跟 top-Swap-used 的數(shù)值是一個(gè)含義,而如手冊(cè)所說(shuō),通常情況下 buffers 數(shù)目要比 cached Mem 小的多,buffers 一般20M這么個(gè)數(shù)量級(jí);io 域的 bi、bo 表明每秒鐘向磁盤(pán)接收和發(fā)送的塊數(shù)目(blocks/s);system 域的 in 表明每秒鐘的系統(tǒng)中斷數(shù)(包括時(shí)鐘中斷),cs表明因?yàn)檫M(jìn)程切換導(dǎo)致上下文切換的數(shù)目。

說(shuō)到這里,想到以前很多人糾結(jié)編譯 linux kernel 的時(shí)候 -j 參數(shù)究竟是 CPU Core 還是 CPU Core+1?通過(guò)上面修改 -j 參數(shù)值編譯 boost 和 linux kernel 的同時(shí)開(kāi)啟 vmstat 監(jiān)控,發(fā)現(xiàn)兩種情況下 context switch 基本沒(méi)有變化,且也只有顯著增加 -j 值后 context switch 才會(huì)有顯著的增加,看來(lái)不必過(guò)于糾結(jié)這個(gè)參數(shù)了,雖然具體編譯時(shí)間長(zhǎng)度我還沒(méi)有測(cè)試。資料說(shuō)如果不是在系統(tǒng)啟動(dòng)或者 benchmark 的狀態(tài),參數(shù) context switch>100000 程序肯定有問(wèn)題。


1.3?pidstat


如果想對(duì)某個(gè)進(jìn)程進(jìn)行全面具體的追蹤,沒(méi)有什么比 pidstat 更合適的了——??臻g、缺頁(yè)情況、主被動(dòng)切換等信息盡收眼底。這個(gè)命令最有用的參數(shù)是-t,可以將進(jìn)程中各個(gè)線程的詳細(xì)信息羅列出來(lái)。


-r: 顯示缺頁(yè)錯(cuò)誤和內(nèi)存使用狀況,缺頁(yè)錯(cuò)誤是程序需要訪問(wèn)映射在虛擬內(nèi)存空間中但是還尚未被加載到物理內(nèi)存中的一個(gè)分頁(yè),缺頁(yè)錯(cuò)誤兩個(gè)主要類型是

  1. minflt/s 指的 minor faults,當(dāng)需要訪問(wèn)的物理頁(yè)面因?yàn)槟承┰?比如共享頁(yè)面、緩存機(jī)制等)已經(jīng)存在于物理內(nèi)存中了,只是在當(dāng)前進(jìn)程的頁(yè)表中沒(méi)有引用,MMU 只需要設(shè)置對(duì)應(yīng)的 entry 就可以了,這個(gè)代價(jià)是相當(dāng)小的

  2. majflt/s 指的 major faults,MMU 需要在當(dāng)前可用物理內(nèi)存中申請(qǐng)一塊空閑的物理頁(yè)面(如果沒(méi)有可用的空閑頁(yè)面,則需要將別的物理頁(yè)面切換到交換空間去以釋放得到空閑物理頁(yè)面),然后從外部加載數(shù)據(jù)到該物理頁(yè)面中,并設(shè)置好對(duì)應(yīng)的 entry,這個(gè)代價(jià)是相當(dāng)高的,和前者有幾個(gè)數(shù)據(jù)級(jí)的差異


-s:棧使用狀況,包括 StkSize 為線程保留的??臻g,以及 StkRef 實(shí)際使用的棧空間。使用ulimit -s發(fā)現(xiàn)CentOS 6.x上面默認(rèn)棧空間是10240K,而 CentOS 7.x、Ubuntu系列默認(rèn)??臻g大小為8196K

-u:CPU使用率情況,參數(shù)同前面類似


-w:線程上下文切換的數(shù)目,還細(xì)分為cswch/s因?yàn)榈却Y源等因素導(dǎo)致的主動(dòng)切換,以及nvcswch/s線程CPU時(shí)間導(dǎo)致的被動(dòng)切換的統(tǒng)計(jì)

如果每次都先ps得到程序的pid后再操作pidstat會(huì)顯得很麻煩,所以這個(gè)殺手锏的-C可以指定某個(gè)字符串,然后Command中如果包含這個(gè)字符串,那么該程序的信息就會(huì)被打印統(tǒng)計(jì)出來(lái),-l可以顯示完整的程序名和參數(shù)
? ~ pidstat -w -t -C “ailaw” -l?

這么看來(lái),如果查看單個(gè)尤其是多線程的任務(wù)時(shí)候,pidstat比常用的ps更好使!


1.4?其他


當(dāng)需要單獨(dú)監(jiān)測(cè)單個(gè) CPU 情況的時(shí)候,除了 htop 還可以使用 mpstat,查看在 SMP 處理器上各個(gè) Core 的工作量是否負(fù)載均衡,是否有某些熱點(diǎn)線程占用 Core。
? ~ mpstat -P ALL 1

如果想直接監(jiān)測(cè)某個(gè)進(jìn)程占用的資源,既可以使用top -u taozj的方式過(guò)濾掉其他用戶無(wú)關(guān)進(jìn)程,也可以采用下面的方式進(jìn)行選擇,ps命令可以自定義需要打印的條目信息:


while :; do ps -eo user,pid,ni,pri,u,psr,comm | grep 'ailawd'; sleep 1; done


如想理清繼承關(guān)系,下面一個(gè)常用的參數(shù)可以用于顯示進(jìn)程樹(shù)結(jié)構(gòu),顯示效果比pstree詳細(xì)美觀的多

? ~ ps axjf


二、磁盤(pán)IO類


iotop 可以直觀的顯示各個(gè)進(jìn)程、線程的磁盤(pán)讀取實(shí)時(shí)速率;lsof 不僅可以顯示普通文件的打開(kāi)信息(使用者),還可以操作 /dev/sda1 這類設(shè)備文件的打開(kāi)信息,那么比如當(dāng)分區(qū)無(wú)法 umount 的時(shí)候,就可以通過(guò) lsof 找出磁盤(pán)該分區(qū)的使用狀態(tài)了,而且添加 +fg 參數(shù)還可以額外顯示文件打開(kāi) flag 標(biāo)記。


2.1?iostat


? ~ iostat -xz 1


其實(shí)無(wú)論使用 iostat -xz 1 還是使用 sar -d 1,對(duì)于磁盤(pán)重要的參數(shù)是:

  • avgqu-s:發(fā)送給設(shè)備 I/O 請(qǐng)求的等待隊(duì)列平均長(zhǎng)度,對(duì)于單個(gè)磁盤(pán)如果值>1表明設(shè)備飽和,對(duì)于多個(gè)磁盤(pán)陣列的邏輯磁盤(pán)情況除外

  • await(r_await、w_await):平均每次設(shè)備 I/O 請(qǐng)求操作的等待時(shí)間(ms),包含請(qǐng)求排列在隊(duì)列中和被服務(wù)的時(shí)間之和;

  • svctm:發(fā)送給設(shè)備 I/O 請(qǐng)求的平均服務(wù)時(shí)間(ms),如果 svctm 與 await 很接近,表示幾乎沒(méi)有 I/O 等待,磁盤(pán)性能很好,否則磁盤(pán)隊(duì)列等待時(shí)間較長(zhǎng),磁盤(pán)響應(yīng)較差;

  • %util:設(shè)備的使用率,表明每秒中用于 I/O 工作時(shí)間的占比,單個(gè)磁盤(pán)當(dāng) %util>60% 的時(shí)候性能就會(huì)下降(體現(xiàn)在 await 也會(huì)增加),當(dāng)接近100%時(shí)候就設(shè)備飽和了,但對(duì)于有多個(gè)磁盤(pán)陣列的邏輯磁盤(pán)情況除外;


還有,雖然監(jiān)測(cè)到的磁盤(pán)性能比較差,但是不一定會(huì)對(duì)應(yīng)用程序的響應(yīng)造成影響,內(nèi)核通常使用 I/O asynchronously 技術(shù),使用讀寫(xiě)緩存技術(shù)來(lái)改善性能,不過(guò)這又跟上面的物理內(nèi)存的限制相制約了。


上面的這些參數(shù),對(duì)網(wǎng)絡(luò)文件系統(tǒng)也是受用的。


三、網(wǎng)絡(luò)類


網(wǎng)絡(luò)性能對(duì)于服務(wù)器的重要性不言而喻,工具 iptraf 可以直觀的現(xiàn)實(shí)網(wǎng)卡的收發(fā)速度信息,比較的簡(jiǎn)潔方便通過(guò) sar -n DEV 1 也可以得到類似的吞吐量信息,而網(wǎng)卡都標(biāo)配了最大速率信息,比如百兆網(wǎng)卡千兆網(wǎng)卡,很容易查看設(shè)備的利用率。

通常,網(wǎng)卡的傳輸速率并不是網(wǎng)絡(luò)開(kāi)發(fā)中最為關(guān)切的,而是針對(duì)特定的 UDP、TCP 連接的丟包率、重傳率,以及網(wǎng)絡(luò)延時(shí)等信息。


3.1?netstat


? ~ netstat -s

顯示自從系統(tǒng)啟動(dòng)以來(lái),各個(gè)協(xié)議的總體數(shù)據(jù)信息。雖然參數(shù)信息比較豐富有用,但是累計(jì)值,除非兩次運(yùn)行做差才能得出當(dāng)前系統(tǒng)的網(wǎng)絡(luò)狀態(tài)信息,亦或者使用 watch 眼睛直觀其數(shù)值變化趨勢(shì)。所以netstat通常用來(lái)檢測(cè)端口和連接信息的:


netstat –all(a) –numeric(n) –tcp(t) –udp(u) –timers(o) –listening(l) –program(p)


–timers可以取消域名反向查詢,加快顯示速度;比較常用的有


? ?~ netstat -antp ?#列出所有TCP的連接

? ?~ netstat -nltp ? #列出本地所有TCP偵聽(tīng)套接字,不要加-a參數(shù)


3.2?sar


sar 這個(gè)工具太強(qiáng)大了,什么 CPU、磁盤(pán)、頁(yè)面交換啥都管,這里使用 -n 主要用來(lái)分析網(wǎng)絡(luò)活動(dòng),雖然網(wǎng)絡(luò)中它還給細(xì)分了 NFS、IP、ICMP、SOCK 等各種層次各種協(xié)議的數(shù)據(jù)信息,我們只關(guān)心 TCP 和 UDP。下面的命令除了顯示常規(guī)情況下段、數(shù)據(jù)報(bào)的收發(fā)情況,還包括

TCP
? ~ sudo sar -n TCP,ETCP 1?

  • active/s:本地發(fā)起的 TCP 連接,比如通過(guò) connect(),TCP 的狀態(tài)從CLOSED -> SYN-SENT

  • passive/s:由遠(yuǎn)程發(fā)起的 TCP 連接,比如通過(guò) accept(),TCP 的狀態(tài)從LISTEN -> SYN-RCVD

  • retrans/s(tcpRetransSegs):每秒鐘 TCP 重傳數(shù)目,通常在網(wǎng)絡(luò)質(zhì)量差,或者服務(wù)器過(guò)載后丟包的情況下,根據(jù) TCP 的確認(rèn)重傳機(jī)制會(huì)發(fā)生重傳操作

  • isegerr/s(tcpInErrs):每秒鐘接收到出錯(cuò)的數(shù)據(jù)包(比如 checksum 失敗)


UDP
? ~ sudo sar -n UDP 1?

  • noport/s(udpNoPorts):每秒鐘接收到的但是卻沒(méi)有應(yīng)用程序在指定目的端口的數(shù)據(jù)報(bào)個(gè)數(shù)

  • idgmerr/s(udpInErrors):除了上面原因之外的本機(jī)接收到但卻無(wú)法派發(fā)的數(shù)據(jù)報(bào)個(gè)數(shù)

當(dāng)然,這些數(shù)據(jù)一定程度上可以說(shuō)明網(wǎng)絡(luò)可靠性,但也只有同具體的業(yè)務(wù)需求場(chǎng)景結(jié)合起來(lái)才具有意義。


3.3?tcpdump


tcpdump 不得不說(shuō)是個(gè)好東西。大家都知道本地調(diào)試的時(shí)候喜歡使用 wireshark,但是線上服務(wù)端出現(xiàn)問(wèn)題怎么弄呢?


附錄的參考文獻(xiàn)給出了思路:復(fù)原環(huán)境,使用 tcpdump 進(jìn)行抓包,當(dāng)問(wèn)題復(fù)現(xiàn)(比如日志顯示或者某個(gè)狀態(tài)顯現(xiàn))的時(shí)候,就可以結(jié)束抓包了,而且 tcpdump 本身帶有 -C/-W 參數(shù),可以限制抓取包存儲(chǔ)文件的大小,當(dāng)達(dá)到這個(gè)這個(gè)限制的時(shí)候保存的包數(shù)據(jù)自動(dòng) rotate,所以抓包數(shù)量總體還是可控的。此后將數(shù)據(jù)包拿下線來(lái),用 wireshark 想怎么看就怎么看,豈不樂(lè)哉!tcpdump 雖然沒(méi)有 GUI 界面,但是抓包的功能絲毫不弱,可以指定網(wǎng)卡、主機(jī)、端口、協(xié)議等各項(xiàng)過(guò)濾參數(shù),抓下來(lái)的包完整又帶有時(shí)間戳,所以線上程序的數(shù)據(jù)包分析也可以這么簡(jiǎn)單。

下面就是一個(gè)小的測(cè)試,可見(jiàn) Chrome 啟動(dòng)時(shí)候自動(dòng)向 Webserver 發(fā)起建立了三條連接,由于這里限制了 dst port 參數(shù),所以服務(wù)端的應(yīng)答包被過(guò)濾掉了,拿下來(lái)用 wireshark 打開(kāi),SYNC、ACK 建立連接的過(guò)程還是很明顯的!在使用 tcpdump 的時(shí)候,需要盡可能的配置抓取的過(guò)濾條件,一方面便于接下來(lái)的分析,二則 tcpdump 開(kāi)啟后對(duì)網(wǎng)卡和系統(tǒng)的性能會(huì)有影響,進(jìn)而會(huì)影響到在線業(yè)務(wù)的性能。

本文完!

來(lái)源:taozj

https://taozj.org/201701/linux-performance-basic.html


《Linux云計(jì)算及運(yùn)維架構(gòu)師高薪實(shí)戰(zhàn)班》2018年07月16日即將開(kāi)課中,120天沖擊Linux運(yùn)維年薪30萬(wàn),改變速約~~~~

    *聲明:推送內(nèi)容及圖片來(lái)源于網(wǎng)絡(luò),部分內(nèi)容會(huì)有所改動(dòng),版權(quán)歸原作者所有,如來(lái)源信息有誤或侵犯權(quán)益,請(qǐng)聯(lián)系我們刪除或授權(quán)事宜。

    - END -



    更多Linux好文請(qǐng)點(diǎn)擊【閱讀原文】

    ↓↓↓

    發(fā)表
    26906人 簽到看排名