ES是當(dāng)前阿里云的核心產(chǎn)品，又是很多云服務(wù)的基座產(chǎn)品，隨著集團(tuán)內(nèi)部上云，越來越多的應(yīng)用和服務(wù)構(gòu)建在ECSCS而廣，為了更好地服務(wù)用戶，并使得越來越多的用戶能夠“自ECSTSCS系統(tǒng)售后團(tuán)隊(duì)根據(jù)多年的豐富排查經(jīng)驗(yàn)，總結(jié)并選取出一些可以拋磚引玉的處理思路和方案，希望可以Linux啟動(dòng)與登錄問 超詳細(xì)系統(tǒng)啟動(dòng)與登陸異常排查 grub.conf文件內(nèi)容被清空了怎么 小心PAM不讓你登 CentOS登錄卡住的原因被我找到 Linux性能問 找到Linux虛機(jī)Load高的“元兇 OOMkiller是被誰觸發(fā) 我的服務(wù)器內(nèi)存去哪兒 CPU占用不高但網(wǎng)絡(luò)性能很差的一個(gè)原 一次IO異常捕獲過 Linux主機(jī)網(wǎng)絡(luò)問 TIME_WAIT&CLOSE_WAIT的討論總 一次網(wǎng)絡(luò)抖動(dòng)經(jīng)典案例分 Linux系統(tǒng)服務(wù)與參數(shù)問 4個(gè)limits生效的問 6步排查ss&netstat統(tǒng)計(jì)結(jié)果不一樣的原 請不要忽略min_free_kbytes的設(shè) 最后的彩 某地區(qū)口罩項(xiàng)目架構(gòu)演進(jìn)及優(yōu)化經(jīng) Linux啟動(dòng)與登錄問題LLiuxECSES硬件、系統(tǒng)與文件異常等等，本文僅從系統(tǒng)與文件本身角度，在大量處理經(jīng)驗(yàn)的基礎(chǔ)上，歸納總結(jié)了一些可能會(huì)引起系統(tǒng)啟動(dòng)與登錄問題的排查點(diǎn)，并給出幾個(gè)比較常見的典型案例來具體展示和說明。CentOSfsckinode(mkinitrdvirtiogrub/boot（demo，不同系統(tǒng)內(nèi)核版booti386。超詳細(xì)系統(tǒng)啟動(dòng)與登陸異常排查點(diǎn)超詳細(xì)系統(tǒng)啟動(dòng)與登陸異常排查點(diǎn)< PAGE6>/boot/grub/device.maphdavdafstab/grubuuid/dev/vda1的啟動(dòng)項(xiàng)嘗試，也適用于系統(tǒng)盤快照創(chuàng)建云盤掛載后，uuid一致導(dǎo)致的啟動(dòng)異UUID的掛載即可。/dev/vda1/dev/vda1/ext4defaults1777（777）ssh\h/bin/bin/sbin/lib/lib32/lib64/etc/boot/usr/bin/usr/sbin/usr/lib的配置，profileCentOSselinux#ThisfilecontrolsthestateofSELinuxonthesystem. enforcing-SELinuxsecuritypolicyis permissive-SELinuxprintswarningsinsteadofenforcing. SELINUX=disabled把這一行改成#SELINUXTYPE=cantakeoneofthree targeted-Targetedprocessesare minimum-Modificationoftargetedpolicy.Onlyselectedprocessesareprotected. mls-MultiLevelSecurityprotection.root/etc/passwd/etc/shadowrootpoliktdbus/etc/pam.d目錄下是否有為空的文件及參數(shù)設(shè)置是否正常，如常見的sys-tem-authpasswd。/etc/pam.dso/etc/lib64/bin/sbin/usr/bin/usr/sbinsize0/etc/profile/etc/profile.d(打印列表)/etc/bashrc/root/.bash_profile/root/.bashrcUbuntu12.04/etc/login.defsERASECHAR0177configurationconfigurationerror-cannotparseerasecharrpmlogin[root@iZbp1cabe6lyx26ikmjie2Z[root@iZbp1cabe6lyx26ikmjie2Zpam.d]#rpm-Vutil-linux c/etc/pam.d/login[root@iZbp1cabe6lyx26ikmjie2Zpam.d]#rpm-qlutil-linux|egrep-vi/etc/pam.d/runuser-/etc/pam.d/su-/etc/ssh/sshd_config相關(guān)參數(shù)如LoginGraceTime/Allowusers/Permit-問題不好確認(rèn)的時(shí)候，可以將shadw以判斷是否到密碼驗(yàn)證階段了。ssh\hLiveCDchrootECSISO\hOOS運(yùn)維編排創(chuàng)建一個(gè)新實(shí)例，把有問題的實(shí)例系統(tǒng)盤掛載到新實(shí)例為~LinuxLinux\h\hOS優(yōu)化腳本OSS鏈接：\hhttps://xiaoling-public.oss-cn-hangzhou.aliyuncs.\hOS離線修復(fù)腳本：\h/oos/\hgrub.confgrub.conf文件內(nèi)容被清空了怎么辦 PAGE11 PAGE12>grub.confgrub.confgrub，grub>grub>root(hd0,0)1find出來的那grub>kernel/boot/vmlinuz-2.6.32-696.3.2.el6.x86_64roroot=/dev/vda1指grub>initrd/boot/initramfs-2.6.32-696.3.2.el6.x86_64.imggrub>bootreboot就等于重啟整個(gè)系統(tǒng)了，剛才的設(shè)置就失mounteremount,rwlsmod|grepnet~ssh，找個(gè)同版本系統(tǒng)的grub.conf，拷貝一份過來，不然重啟之后又進(jìn)grub\h巧妙利用巧妙利用strace查找丟失的文件 PAGE13 PAGE14>巧妙利用stracestraceuserchrootihavenoname，這里本身就是有問題了，說明系統(tǒng)內(nèi)缺少stracechrootstracestrace-F-ff-t-tt-s256-och.outchroot/mntifconfigifconfigeth1IP>netmask>routeadddefaultgwIP>小心小心PAM不讓你登錄 PAGE15 PAGE16>CentOSPAMcatJun209:26:48iZbp1begsz1x269nxhtip4ZcatJun209:26:48iZbp1begsz1x269nxhtip4Zlogin:FAILEDLOGIN1FROMtty1FOR#cat/etc/pam.d/login#cat/etc/pam.d/loginauthrequiredpam_succeed_if.souser!=rootauth[user_unknown=ignoresuccess=okignore=ignoredefault=bad]pam_#pam_selinux.socloseshouldbethefirstsessionrule pam_selinux.soclose #pam_selinux.soopenshouldonlybefollowedbysessionstobeexecutedtheusersystem-system-system-pam_selinux.sopam_keyinit.soforcesystem--authauthrequiredpam_succeed_if.souser!=rootCentOSCentOS登錄卡住的原因被我找到了 17 /etc/profile里面有source/etc/profileLinuxLLnux性能問題的排查和處理一直是系統(tǒng)管理和運(yùn)維人員的“心頭之患UOOutofMmr只會(huì)一味地增大內(nèi)存容量，而沒有很好地理解和分析問題背后產(chǎn)生的根因。而這些都對(duì)線上業(yè)務(wù)的可靠和穩(wěn)定性提出了挑戰(zhàn)。本文將阿里云售后遇到的較為常見的幾個(gè)系統(tǒng)性能問題進(jìn)行展分析，并給出一些合理的改進(jìn)和優(yōu)化方案。找到LinuxLoadECSloadLinuxloadLinuxtopLoadLoadaveragetopLoadaverages字段，但是這個(gè)CPU的繁忙程度，而是度量系統(tǒng)整體負(fù)載。找到找到Linux虛機(jī)Load高的“元兇” PAGE19 PAGE20LinuxLoad0.000.000.010.051/161lavg_15(0.05)15假設(shè)當(dāng)前有兩個(gè)CPU，則每個(gè)CPU的當(dāng)前任務(wù)數(shù)為0.00/2=0.00loadaverage1010CPUCPUstaticstaticintloadavg_proc_show(structseq_file*m，voidseq_printf(m，"%lu.%02lu%lu.%02lu%lu.%02lu%ld/%dreturnLoadstaticunsignedcalc_load(unsignedlongload，unsignedlongexp，unsignedlongload*=load+=active*(FIXED_1-exp);returnload>>FSHIFT;calc_load-updatetheavenrunloadestimates10ticksafterCPUshaveupdatedvoidvoidunsignedlongupd=calc_load_update+10;longactive;if(time_before(jiffies，upd))active=atomic_long_read(&calc_load_tasks);avenrun[0]=calc_load(avenrun[0]，EXP_1，active);avenrun[1]=calc_load(avenrun[1]，EXP_5，active);avenrun[2]=calc_load(avenrun[2]，EXP_15，active);calc_load_update+=Thesearetheconstantusedtofakethefixed-pointload-counting.Some-11bitfractionsexpandto22bitsbythemultiplies:thisaload-averageprecisionof10bitsinteger+11bits-ifyouwanttocountload-averagesmoreoften，youneedprecision，orroundingwillgetyou.With2-secondcountingtheEXP_nvalueswouldbe1981，2034and2043ifstillusing11bitexternunsignedlong /*Loadaveragesexternvoidget_avenrun(unsignedlong*loads，unsignedlongoffset，int/*nrofbitsofprecision/*1.0asfixed-point/*5secintervals/*1/exp(5sec/1min)asfixed-/*1/exp(5sec/5min)/*1/exp(5sec/15min)#defineCALC_LOAD(load,exp,n)\load*=exp;\load+=n*(FIXED_1-exp);\load>>=FSHIFT;loadLinux進(jìn)程，不是指正在運(yùn)行的進(jìn)程。即進(jìn)程的狀態(tài)是TASK_RUNNINGTASK_Linux3avenrun1121CPUCPU50。1、5、15load1、load5load15，那么下一個(gè)load1-=load1-exp(-5/60)-+n(1-exp(-5/60))load5-=load5-exp(-5/300)+n(1-exp(-5/300))load15=load15exp(-5/900)+n(1-exp(-5/900))其中，exp(xexnload通過前面的講解，我們已經(jīng)明白有可能系統(tǒng)有很高的負(fù)載但是CUCU運(yùn)行隊(duì)列的進(jìn)程呢？1sforiin$(seq1$(expr${length}/${interval}));doLANG=Cps-eTostat,pid,tid,ppid,comm--no-header|sed-e's/^\*//'|cat/proc/loadavgecho-e"\n"sleep${interval}atatJan2015:54:12CSTSatJan2015:54:12CST25.7620.6019.0012/404注：R代表運(yùn)行中的隊(duì)列，DloadnginxRDload最后也給大家share一下查CPUforiin$(seq1$(expr${length}/${interval}));doLANG=Ccatecho'0';}|bc-lsleep${interval}fuser-kOOMOOMkiller是被誰觸發(fā)的 PAGE25 PAGE24>OOMkillerOOMkiller用戶發(fā)現(xiàn)自己的服務(wù)器CPU在某一時(shí)刻陡然升高，但從監(jiān)控上看，同一時(shí)刻的業(yè)務(wù)經(jīng)過我們的排查，發(fā)現(xiàn)cpu的兩次間歇飆高是由于客戶系統(tǒng)當(dāng)時(shí)發(fā)生了OOM（outofmemory）oom-killercpucpuoomcpuoom誰為因果這件事上，客戶和我們持完全相反的態(tài)度。oomcpuoomPageZone有些硬件設(shè)備只能對(duì)特定的內(nèi)存地址執(zhí)行DMA（directmemoryaccess）ZONE_DMA—pageDMA操作。這部分區(qū)域的大CPUx8616MB。ZONE_DMA32—類似于ZOME_DMA，這個(gè)區(qū)也包含可以執(zhí)行DMA操page6432ZONE_NORMAL—這個(gè)區(qū)包含可以正常映射到地址空間中的page，或者說這個(gè)區(qū)包含了除了DMA和HIGHMEM以外的內(nèi)存。許多內(nèi)核操作都僅ZONE_HIGHMEM—這個(gè)區(qū)包含的是highmemory，也就是那些不能被永32x86，ZONE_DMA，ZONE_NORMAL，1）1G/3G<>24G/4G<>64igmem64DMA，DMA32L<>2orderunsignedunsignedlongget_free_pages(gfp_tgfp_mask，unsignedint內(nèi)核空間的內(nèi)存分配函數(shù)和用戶空間最大的不同就是每個(gè)函數(shù)會(huì)有一個(gè)gfp_maskgfpget_free_pages()gfp_mask可以分成三種：行為修飾符（actionmodifier）,區(qū)修飾符（zone行為修飾符是用來指定內(nèi)核該如何分配內(nèi)存的。比如分配內(nèi)存時(shí)是否可io，是否可以進(jìn)行文件系統(tǒng)操作，內(nèi)核是否可以睡眠（sleep）類型是行為修飾符和區(qū)修飾符結(jié)合之后的產(chǎn)物。在一些特定的內(nèi)存分配場合下，我們可能需要同時(shí)指定多個(gè)行為修飾符和區(qū)修飾符，而tpe針對(duì)這些固定的場合，將所需要的行為修飾符和區(qū)修飾符都整合到了一起，etype下面是從oomkiller被觸發(fā)到進(jìn)程到被殺掉的一個(gè)大概過程，我們來具體看nginxinvokedoom-killer:gfp_mask=0x200daorder=0oom_score_adj=0CPU:1PID:10242Comm:nginxNottainted3.13.0-86-generic#130-Ubuntu0000000000000000ffff880070611a00ffffffff8172a3b4ffff88012af6c8000000000000000000ffff880070611a88ffffffff8172495dffffffff81069b76ffff880070611a60ffffffff810ca5acffff88020fff7e380000000000000000Node0DMAfree:15908kBmin:128kBlow:160kBhigh:192kBactive_anon:0kBinactive_anon:0kBactive_file:0kBinactive_file:0kBunevictable:0kBisolated(anon):0kBisolated(file):0kBpresent:15992kBmanaged:15908kBmlocked:0kBdirty:0kBwriteback:0kBmapped:0kBshmem:0kBslab_reclaimable:0kBslab_unreclaimable:0kBkernel_stack:0kBpagetables:0kBunstable:0kBbounce:0kBfree_cma:0kBwriteback_tmp:0kBpages_scanned:0all_unreclaimable?yeslowmem_reserve[]:037467968Node0DMA32free:48516kBmin:31704kBlow:39628kBhigh:47556kBactive_anon:3619272kBinactive_anon:216kBactive_file:556kBinactive_file:1516kBunevictable:0kBisolated(anon):0kBisolated(file):0kBpresent:3915776kBmanaged:3836724kBmlocked:0kBdirty:4kBwriteback:0kBmapped:324kBshmem:1008kBslab_reclaimable:67136kBslab_unreclaimable:67488kBkernel_stack:1792kBpagetables:14540kBunstable:0kBbounce:0kBfree_cma:0kBwriteback_tmp:0kBpages_scanned:7365all_unreclaimable?yesNode0Normalfree:35640kBmin:35748kBlow:44684kBhigh:53620kBactive_anon:4019124kBinactive_anon:292kBactive_file:1292kBinactive_file:2972kBunevictable:0kBisolated(anon):0kBisolated(file):0kBpresent:4456448kBmanaged:4322984kBmlocked:0kBdirty:24kBwriteback:4kBmapped:1296kBshmem:1324kBslab_reclaimable:81196kBslab_unreclaimable:83432kBkernel_stack:3392kBpagetables:20252kBunstable:0kBbounce:0kBfree_cma:0kBwriteback_tmp:0kBpages_scanned:7874all_unreclaimable?yeslowmem_reserve[]:00001*256kB(U)0*512kB1*1024kB(U)1*2048kB(R)3*4096kB(M)=15908kB(UEM)25*128kB(E)12*256kB(EM)6*512kB(E)7*1024kB(EM)0*2048kB0*4096kB=Node0Normal:5769*4kB(EM)1495*8kB(EM)24*16kB(UE)0*32kB0*64kBNode0hugepages_total=0hugepages_free=0hugepages_surp=0hugepages_2273totalpagecache0pagesinswapSwapcachestats:add0，delete0，find0/0Freeswap=0kB2097054pages0pagesupstart-udev-[-systemd-[upstart-[[[10410410410433366pages33366pages[uidtgidrssnr_ptesswapentsoom_score_adjupstart-file-...（此處有省略Killedprocess10366(nginx)total-vm:84784kB，anon-rss:49156kB，file-nginxnginxinvokedoom-killer:order=0nginx20pagepage，4KB。gfp_maskbitzonemask，也就是說它指明內(nèi)存應(yīng)該從哪Flagvalue 0implicitlymeansallocatefromGFP_HIGHMEM0x02uAllocatefromZONE_HIGHMEMif（這里有一點(diǎn)需要注意，在64x86highmem區(qū)的，64系統(tǒng)中的normal區(qū)就對(duì)應(yīng)上表中的highmem在本案例中，zonemask2nginxzonenormal（64Canwaitandreschedule?Shouldaccessemergencypools?CanstartphysicalIO?Cancalldowntolow-levelFS?Cache-coldpagerequiredSuppresspageallocationfailureRetrytheallocation.MightfailRetryforever.CannotfailSlabinternalusageAddcompoundpagemetadataReturnzeroedpageonsuccess#defineGFP_NOMEMALLOC0x10000u/*Don’tuseemergencyreserves*/allocation*/AIM，GFP_FS，GP_IO，GFP_WAT，都是比較正常的幾個(gè)標(biāo)志，那么我們這個(gè)請求為什么會(huì)有問題呢？繼續(xù)往下看，可以看到下面的信息：Node0Normalfree:35640kBmin:35748kBlow:44684kBhigh:53620kBactive_anon:4019124kBNode0Normalfree:35640kBmin:35748kBlow:44684kBhigh:53620kBactive_anon:4019124kBinactive_anon:292kBactive_file:1292kBinactive_file:2972kBunevictable:0kBisolated(anon):0kBisolated(file):0kBpresent:4456448kBmanaged:4322984kBmlocked:0kBdirty:24kBwriteback:4kBmapped:1296kBshmem:1324kBslab_reclaimable:81196kBslab_unreclaimable:83432kBkernel_stack:3392kBpagetables:20252kBunstable:0kBbounce:0kBfree_cma:0kBwriteback_tmp:0kBpages_scanned:7874all_unreclaimable?yesoomkiller問題的罪魁禍?zhǔn)?，比如我們這個(gè)例子中的這個(gè)nginx進(jìn)程。其實(shí)日志中invokeoomkiller的這個(gè)進(jìn)程有時(shí)候可能只是一個(gè)受害者，因?yàn)槠渌麘?yīng)用／進(jìn)程已將invokeoomkilleroomkiller[uidtgidrss[uidtgidrssnr_ptesswapentsoom_score_adjupstart-udev-[-systemd-[upstart-[[[upstart-file-104104104104nginxKilledprocess10366(nginx)total-vm:84784kB，anon-rss:49156kB，了cpucpu需求，建議用戶升級(jí)內(nèi)存來避免oom的情況發(fā)生，因?yàn)閲?yán)重的oom情況是可我的服務(wù)器內(nèi)存去哪兒了我的服務(wù)器內(nèi)存去哪兒了 PAGE33 PAGE32toptopfree-cache1.7G，slab，4.4G，slabslabtop看到proc_inode_cache使用的最多，這個(gè)代表是proc文件系統(tǒng)的inodepsps-socketllll/proc/22360/task/*/fd/|grepsocket|wc-llll/proc/22360/task/*/fd/|wc-socketinodefdsocketinodeprocslabproc_inode_cacheserverCPUCPU占用不高但網(wǎng)絡(luò)性能很差的一個(gè)原因 PAGE37 PAGE38>CPUCPUcpuCPU處中斷。該中斷通知CPU發(fā)生了某些事情并且CPU應(yīng)該放下當(dāng)前的工作去處理這個(gè)事情。為了防止多個(gè)設(shè)置發(fā)送相同的中斷，Linux設(shè)計(jì)了一套中斷請求系統(tǒng)，使得計(jì)CPU0負(fù)載過高，而無法有效快速的處理網(wǎng)絡(luò)數(shù)據(jù)包，導(dǎo)致了瓶頸。SMPIRQaffinityCPUCPUmp_affnity則設(shè)置才有作用，網(wǎng)卡有多隊(duì)列，才會(huì)有多個(gè)中斷號(hào)，這樣就可以把不同的中斷號(hào)分CPUCPURPS/RFS來模擬多隊(duì)列的情況，但是該效果并不如網(wǎng)卡本身多隊(duì)列+啟RPSRFS來的有效。什么是RPS（ReceivePacketSteering）主要是把軟中斷的負(fù)載均衡到各個(gè)cpu，簡單來說，是網(wǎng)卡驅(qū)動(dòng)對(duì)每個(gè)流生成一個(gè)hash標(biāo)識(shí)，這個(gè)HASH值得計(jì)算可以通過四元標(biāo)識(shí)分配到相應(yīng)的CPU上去，這樣就可以比較充分的發(fā)揮多核的能力了。通俗點(diǎn)來話RPS就不會(huì)有任何的作用。該功能主要針對(duì)單隊(duì)列網(wǎng)卡多CPU環(huán)境，如網(wǎng)卡支SMPirqaffinity1只有RPS（來源網(wǎng)絡(luò)RScpcpu和軟中斷處理的pupuccheFS（Receiveflowsteering）cpucpu這樣就充分利用cpu的cache，這兩個(gè)補(bǔ)丁往往都是一起設(shè)置，來達(dá)到最好的優(yōu)化效CPU環(huán)境。rps_flow_cnt，rps_sock_flow_entries，參數(shù)的值會(huì)被進(jìn)位到最近的2的冪次方值，對(duì)于單隊(duì)列設(shè)備，單隊(duì)列的rps_flow_cnt值被配置成與rps_sock_flow_entriesRFS依靠RPS的機(jī)制插入數(shù)據(jù)包到指定CPU的backlog隊(duì)列，并喚醒那個(gè)CPU默認(rèn)情況下，啟irqbalance是足夠用的，但是對(duì)于一些對(duì)網(wǎng)絡(luò)性能要求比較高的開啟開啟irqbalance有時(shí)候計(jì)算出來的值不合理，導(dǎo)致CPUIRQPower-savemode時(shí)，irqbalanceCPU，CPU的睡眠時(shí)間，降低能耗。如果壓力突然上升，可能會(huì)由于調(diào)整的滯后性帶來性能d）也存在一些情況，啟動(dòng)了irqbalance，但是并沒有生效，沒有真正去設(shè)置處理中斷的cpuCombined代表隊(duì)列個(gè)數(shù)，說明我的測試機(jī)有4個(gè)隊(duì)列。##ethtool-lChannelparametersforeth0:Pre-setmaximums: Currenthardwaresettings: #catvirtio1-#catvirtio1-IO-APIC- IO-APIC- IO-APIC- IO-APIC- IO-APIC- IO-APIC- IO-APIC-IO-APIC- IO-APIC- IO-APIC- IO-APIC- PCI-MSI- Posted-interrupt PCI-MSI-virtio2- PCI-MSI-virtio2- PCI-MSI-virtio0- PCI-MSI-virtio2- PCI-MSI-virtio2- PCI-MSI-virtio0- PCI-MSI-virtio2- PCI-MSI-virtio2- PCI-MSI-virtio2- PCI-MSI-virtio2- PCI-MSI-virtio2- PCI-MSI-ecscpu#foriin$(egrep"\-input."/proc/interrupts|awk-F":"$1}');docat/proc/irq/$i/smp_affinity_list;donesar#foriin$(egrep"\-input."/proc/interrupts|awk-F":"$1}');docat/proc/irq/$i/smp_affinity_list;done|tr-s'\n'','#sarP5,7,1,31cpu5,7,1,3cpusarPALL1CPU核心的監(jiān)控，這樣我們就可以知道處理慢的原Linux3.10.0-957.5.1.el7.x86_64 05/26/202005:10:06 05:10:07 05:10:07 05:10:07 05:10:07 05:10:07 05:10:07 05:10:08 05:10:08 05:10:08 05:10:08 05:10:08 saridle10sar-P1,3,5,71|tail-n+3|awk'$NF<10{print看所有核心是否有單核打滿的把1357換成ALLsar-PALL1|tail-n+3|awk'$NF<10{print4c8g規(guī)格的配置（ecs.c6.xlarge4ccpu0和2#grep-i"input" PCI-MSI-virtio2- PCI-MSI-virtio2- PCI-MSI-virtio2- PCI-MSI-virtio2-#foriin$(egrep"\-input."/proc/interrupts|awk-F":"$1}');docat/proc/irq/$i/smp_affinity_list;donecpu是超線程的，vCPUCPU4# CPUop- 32-bit，64-Byte Little On-lineCPU(s) 3Thread(s)per Core(s)per NUMA 關(guān)閉IRQbalance##serviceirqbalanceRedirectingto/bin/systemctlstatusirqbalance.service-irqbalanceLoaded:loaded(/usr/lib/systemd/system/irqbalance.service;enabled;Process:1832ExecStart=/usr/sbin/irqbalance--foreground$IRQBALANCE_ARGSMainPID:1832May2714:11:40iZbp1ee4vpiy3w4b8y2m8qZsystemd[1]:StartedirqbalanceMay2714:39:28iZbp1ee4vpiy3w4b8y2m8qZsystemd[1]:StoppingirqbalanceMay2714:39:28iZbp1ee4vpiy3w4b8y2m8qZsystemd[1]:Stoppedirqbalance手動(dòng)設(shè)置RPS手動(dòng)設(shè)置之前我們需要先了解下面的文件（IRQ_numbergrepinput。/proc/irq/${IRQ_number}/，關(guān)注兩個(gè)文件：smp_affinitysmp_smp_affinitybitmask+16/proc/interrupts/proc/interrupts#foriin$(egrep"\-input."/proc/interrupts|awk-F":"'{print$1}');cpu0空出來#echo0>>/proc/irq/27/smp_affinity_listCPU.CPUCPUCPUCPUCPUeth00echoechoff>/sys/class/net/eth0/queues/rx-CPU設(shè)置進(jìn)入，如：0cpu##cat/sys/class/net/eth0/queues/rx-0/rps_cpus#echof>>/sys/class/net/eth0/queues/rx-0/rps_cpus#cat/sys/class/net/eth0/queues/rx-0/rps_cpus設(shè)置RFS的方式。全局表：rps_sock_flow_table##sysctl-a|grepnet.core.rps_sock_flow_entries#sysctl-wnet.core.rps_sock_flow_entries=1024hash##cat/sys/class/net/eth0/queues/rx-0/rps_flow_cnt#echo256>>/sys/class/net/eth0/queues/rx-0/rps_flow_cnt需要啟動(dòng)RFS，建議機(jī)器上所有的網(wǎng)卡隊(duì)列設(shè)置的rps_flow_cnt相加應(yīng)該小于或者等于rps_sock_flow_entries。因?yàn)槭?個(gè)隊(duì)列，因此每個(gè)隊(duì)列設(shè)置256，可一次一次IO異常捕獲過程 PAGE47 PAGE46>一次IOIOIOIO無法定位問題，檢查對(duì)應(yīng)時(shí)間點(diǎn)應(yīng)用日志也沒有發(fā)現(xiàn)異常的訪問，這種問題怎么06/12/201809:52:3306/12/201809:52:36avgqu-awaitwkB/savgrq-avgqu-awaitwkB/savgrq-3io3030磁盤的IOPS（ wkB/sIOIOiotop10:18:417024be/4 0.00 2.64M/s0.00%93.18%-direct=1-iodepth=128-rw=randwrite-ioengine=libaio-bs=1k--numjobs=1-runtime=1000-group_reporting-filename=iotest-name=Rand_每隔3秒采集一次，一共采集30次，靜默模式，只顯示有ioIOid以及進(jìn)程參數(shù)進(jìn)程產(chǎn)生的吞吐量（如果有多個(gè)可以把qqq去掉可顯示總量進(jìn)程占用當(dāng)前IOfio\h##fio-direct=1-iodepth=128-rw=randwrite-ioengine=libaio-bs=1k--numjobs=1-runtime=1000-group_reporting-filename=iotest-name=Rand_Rand_Write_Testing:(g=0):rw=randwrite，bs=1K-1K/1K-1K/1K-Starting1^Cbs:1(f=1):[w][8.5%done][0K/2722K/0K/s][0/2722/0iops][etafio:terminatingonsignalRand_Write_Testing:(groupid=0，jobs=1):err=0:pid=11974:TueJun1210:36:302018write:io=88797KB，bw=2722.8KB/s，iops=2722，runt=iotop10:36:0311974be/4 0.00 2.63M/s0.00%93.95%-direct=1-iodepth=128-rw=randwrite-ioengine=libaio-bs=1k--numjobs=1-runtime=1000-group_reporting-filename=iotest-name=Rand_10:36:0611974be/4 0.00 2.64M/s0.00%92.68%-direct=1-iodepth=128-rw=randwrite-ioengine=libaio-bs=1k--numjobs=1-runtime=1000-group_reporting-filename=iotest-name=Rand_#iostat#iostat-d3-k-x-tLinux2.6.32-431.23.3.el6.x86_64(test) 0.3706/12/201810:36:06 0.3706/12/201810:36:03awaitwkB/savgrq-avgqu-awaitwkB/savgrq-通過輸出結(jié)果的時(shí)間點(diǎn)進(jìn)行對(duì)比分析，相對(duì)于fioIOPS，吞吐量跟iotopiostatIO**bs1k，這樣執(zhí)行的時(shí)間會(huì)比較久，fioiotop24##iotop-b-o-d1-qqq|awk'{print$0"\t"strftime("%Y-%m-%d-%H:%M:%S",systime())}'16209be/4 0.00 2.64M/s0.00%93.72%fio--iodepth=128-rw=randwrite-ioengine=libaio-bs=1k-size=1G--runtime=1000-group_reporting-filename=iotest-name=Rand_Write_Testing16209be/4 0.00 2.63M/s0.00%93.61%fio--iodepth=128-rw=randwrite-ioengine=libaio-bs=1k-size=1G--runtime=1000-group_reporting-filename=iotest-name=Rand_Write_Testing詳細(xì)參數(shù)就不講了，大家可以看下輸出結(jié)果行最后一列是年月日時(shí)分秒，那么IO消Linux主機(jī)網(wǎng)絡(luò)問題ifdownifupifdownifdownifup命令丟失處理 PAGE51 PAGE52>網(wǎng)絡(luò)不通？straceifconfigIP>routerouteaddnet/0gwrouteaddnet/10gw>stracenetwork網(wǎng)絡(luò)不通？網(wǎng)絡(luò)不通？strace二度出手 PAGE53 PAGE54>網(wǎng)絡(luò)不通？stracestracefeopenifupeth0|more打/etc/sysconfig/networkGATEWAYDEV=eth0注釋/etc/sysconfig/network文件的GATEWAYDEV=eth0，TIME_WAITTIME_WAIT&CLOSE_WAIT的討論總結(jié) PAGE57 PAGE58>TIME_WAIT&CLOSE_WAITTIME_WAIT是TCPAFIN，F(xiàn)IN-WAIT-1PFINACK，進(jìn)入CLOSE_WAIT狀態(tài)，并等AACKFIN-WAIT-2被動(dòng)關(guān)閉端P：FIN，進(jìn)入LAST_ACK狀態(tài)，并等待主動(dòng)關(guān)閉端A：收到FIN后必須立即發(fā)ACK，進(jìn)入TIME_WAIT狀態(tài)，等待2MSLSocket。被動(dòng)關(guān)閉端P：收到ACK后結(jié)束Socket因此，TIE_ATclientserverTIME_WAITCLOSED狀態(tài)，有一個(gè)超時(shí)設(shè)置，這個(gè)超時(shí)設(shè)置是TIME_WAITABTM_AIT狀態(tài)，AAKCKAKI，此時(shí)連接關(guān)閉，NACK，TIME_WAIT，ACK，確保對(duì)端能正常關(guān)閉連接。剛才提到主動(dòng)端進(jìn)入TIME_WAIT后，等待2MSLCLOSE，這里的MSL是指（maximumsegmentlifetime，我們內(nèi)核一般是30s，2MSL1鐘，網(wǎng)絡(luò)上數(shù)據(jù)包最大的生命周期。這是為了使網(wǎng)絡(luò)上由于重傳出現(xiàn)的oldduplicatesegment（IP/PORTIP/PORT）相同的連接，如果等待時(shí)間不夠長，又創(chuàng)建好了一樣的連接，再收到oldduplicatesegment，數(shù)據(jù)就錯(cuò)亂了。TIME_WAITTIME_WAITCLOSED，2MSL=60s連接在業(yè)務(wù)結(jié)束之后，需要60s的時(shí)間才能完全釋放。如果業(yè)務(wù)上采用的是短連接的方式，會(huì)導(dǎo)致非常多的TIME_WAIT狀態(tài)的連接，會(huì)占用一些資源，主sysctlnet.ipv4.ip_local_port_rangenet.ipv4.ip_local_port_range=32768IE_AIT發(fā)起新的連接去連其他服務(wù)器了。serverclient端建立的連接產(chǎn)生了大量的TIME_WAIT連接，這是不會(huì)出現(xiàn)這個(gè)問題的。除非是其中涉及到的某個(gè)客戶端的TIME_WAITTIME_WAITsysctlnet.ipv4.tcp_max_tw_bucketsnet.ipv4.tcp_max_tw_buckets=超出了這個(gè)限制會(huì)報(bào)一條INFO級(jí)別的內(nèi)核日志，然后繼續(xù)關(guān)閉掉連接。并沒有另外的風(fēng)險(xiǎn)就是，關(guān)閉掉TIME_WAIT連接后，剛剛發(fā)出的ACK如果對(duì)端沒有收到，重發(fā)FIN包出來時(shí)，不能正確回復(fù)ACK，只是回復(fù)一個(gè)RST包，導(dǎo)致connectionreset。因此net.ipv4.tcp_max_tw_buckets風(fēng)險(xiǎn)，沒有什么收益，只是表面上通過netstat看到的TIME_WAIT少了些而net.ipv4.tcp_timestampsnet.ipv4.tcp_timestamps=net.ipv4.tcp_tw_recycle=如果這兩個(gè)參數(shù)同時(shí)啟，會(huì)校驗(yàn)源ip過來的包攜帶的tmsamp是否遞增，syn，serversynack。sysctlnet.ipv4.ip_local_port_rangenet.ipv4.ip_local_port_range=32768time_waitsysctlnet.ipv4.tcp_max_tw_bucketsnet.ipv4.tcp_max_tw_buckets=net.ipv4.tcp_max_tw_bucketsecs簡單來說net.ipv4.tcp_max_tw_bucketstwTCP:timewaitbuckettableoverflowtw_bucketestablishedfinackclosedtw_buckettw_buckettime_wait（LRU），time_Waitclosedestablishedfinacktime_wait。twtw放大的話需要更多的內(nèi)存銷，但是幾乎可以忽略不計(jì)占用更多的本地端口，需要適當(dāng)?shù)姆糯蟊镜囟丝诜秶?，端口范圍?jīng)過簡單的測w1.5netstatsocket（ssssslabtw，local_port_rangesnatsynnginxphp-fpmtcp_tw_reusenet.ipv4.tcp_timestamps1servertp_tw_reseIE_WIT字。注意，重用的是AIT套接字占用的端口號(hào)，而不是TIME_WAITnet_)TIME_WAITESTALIHEDI、端口號(hào)是相同的，沒有重用的概念。但并不是說服務(wù)器TIME_WAIT狀態(tài)套接字。net.ipv4.tcp_tw_reuse=1 net.ipv4.ip_local_port_range=1500065000放大本地端口范圍Total:15254(kernel 15169(estab5，closed15158，orphaned0，synrecv0，timewait3/0)，ports015000socket30m關(guān)于如上所示，CLOSE_WAITFINACK包，之后就進(jìn)入了CLOSE_WAIT狀態(tài)。一般來說，如果一切正?？蛻舳顺绦蛐枰l(fā)出FIN包，進(jìn)而遷移到LAST_ACK狀態(tài)，收ACKTCP連接關(guān)閉的整個(gè)過程。注：不管是服務(wù)器還是客戶端，只要是被動(dòng)接收第一個(gè)FIN的那一方才會(huì)進(jìn)入CLOSE_WAIT狀態(tài)。一次網(wǎng)絡(luò)抖動(dòng)經(jīng)典案例分析一次網(wǎng)絡(luò)抖動(dòng)經(jīng)典案例分析 PAGE65 PAGE66\h\h\h網(wǎng)絡(luò)抖動(dòng)案例是一類處理難度較大的問題，原因主要是很多抖動(dòng)發(fā)生的頻率不高，且10ms求非常高，因此對(duì)此類在百毫秒的延遲也會(huì)非常敏感。本文記錄的是一次多團(tuán)隊(duì)協(xié)作處理的抖動(dòng)問題的過程，由于用戶的執(zhí)著，也使得我們在這個(gè)案例分析得較為深入，希望對(duì)大家今后的此類案例的處理有所啟發(fā)。1-2而且發(fā)生較為頻繁，由于業(yè)務(wù)的實(shí)時(shí)性要求較高，因此對(duì)業(yè)務(wù)的影響較大，當(dāng)然其中也影響到了用戶對(duì)遷云的信心。有非常深入的了解，所以用戶的應(yīng)用日志具體含義和記錄方式對(duì)我們來說更像黑盒。ping。所以pigpngpnging容易說明問題。pingping來看看上面的ping測試結(jié)果吧，初看也僅僅是一些百毫秒延遲的集中發(fā)生而已，但是仔細(xì)觀察就會(huì)發(fā)現(xiàn)每次發(fā)生都有這樣的情況，就是延遲在一組連續(xù)的ping上發(fā)生ICMP請求都被沒有被第一時(shí)間處理，而是突然在800ms之后系統(tǒng)處理了所有之前發(fā)生回復(fù)，因此才會(huì)產(chǎn)生這樣的現(xiàn)象。那么我們此時(shí)可以有一個(gè)假設(shè)，在這800ms之前系統(tǒng)停止了系統(tǒng)的軟中斷和中斷都不能在CPU上發(fā)生，從而使得當(dāng)前在CPU上運(yùn)行的指令是timer然而問題就隱藏在一類系統(tǒng)的內(nèi)存資源上，即系統(tǒng)的slab占用量相比正常系統(tǒng)要高dentryslabdentry中表示目錄和文件的對(duì)象，作為與inodedentry項(xiàng)可能代表這系統(tǒng)有大量被打的文件。然而此時(shí)我們首先需要解釋大量的dentry2.6slabslabspin_lock_irqstaticstaticinlinevoidspin_lock_irq(spinlock_t于是我們可以確認(rèn)在統(tǒng)計(jì)slab信息的時(shí)候，系統(tǒng)的行為是首先禁用中斷，然后遍歷以上函數(shù)也將會(huì)被調(diào)用，同時(shí)觀察ping測試輸出符合以上問題點(diǎn)的情況，即可以大此時(shí)我們已經(jīng)有了可以暫時(shí)緩解問題的方法了，對(duì)dentry項(xiàng)是作為文件系統(tǒng)緩存的dentryecho2>/proc/sys/vm/drop_caches&&syncdentrydropcacheLinux系統(tǒng)服務(wù)與參數(shù)問題云結(jié)合多年云上ECS運(yùn)維經(jīng)驗(yàn)和用戶業(yè)務(wù)反饋，不斷優(yōu)化ECS系統(tǒng)鏡像以limits.conf/proc/pid/limitsSoftHardMaxMaxopenlimits.conf44個(gè)limits生效的問題 PAGE71 PAGE72>4limits/etc/security/limits.confPAMsystemdservice的資源限制不生效。因此登錄用戶的限制，通過/etc/security/limits.conf/etc/security/limits.dsystemdservice/etc/systemd/system.conf.conf/etc/systemd/system.conf.d/.conf/etc/systemd/user.conf.d/.conf。system.conf，user.confvimvim/etc/systemd/system.confSoftHardMaxMaxopen65536[root@iZwz98aynkjcxvtra0f375Z[root@iZwz98aynkjcxvtra0f375Z~]#cat/etc/systemd/system/multi-user.Description=DockerDescription=DockerApplicationContainerEngineAfter=network-online.targetfirewalld.servicecontainerd.serviceExecStart=/usr/bin/dockerd-Hfd://ExecStartPost=/usr/sbin/iptables-PFORWARDACCEPTExecReload=/bin/kill-sHUP$MAINPIDWantedBy=multi-SoftHardMaxcpuMaxfileMaxdataMaxstackMaxcorefileMaxresidentMaxMaxopenMaxlockedMaxaddressMaxfileMaxpendingMaxmsgqueueMaxniceMaxrealtimeMaxrealtimesystemdbug，240[root@iZwz98aynkjcxvtra0f375Z[root@iZwz98aynkjcxvtra0f375Z~]#ulimit-n[root@iZwz98aynkjcxvtra0f375Z~]#ulimit-n-bash:ulimit:openfiles:cannotmodifylimit:OperationnotCentOS7openfilenr_open[root@iZwz98aynkjcxvtra0f375Z[root@iZwz98aynkjcxvtra0f375Z~]#cat/proc/sys/fs/nr_open[root@iZwz98aynkjcxvtra0f375Z~]#ulimit-n-bash:ulimit:openfiles:cannotmodifylimit:Operationnotpermitted#cat#cat/etc/supervisor/supervisord.conflogfile=/var/log/supervisor/supervisord.log;(mainlogfile;default$CWD/pidfile=/var/run/supervisord.pid;(supervisordpidfile;default ;('AUTO'childlogdir,MaxcpuMaxfileMaxdataMaxstackMaxcorefileMaxresidentsetMaxprocessesMaxopenMaxlockedMaxaddressMaxfileMaxpendingMaxmsgqueueMaxnice;min.availstartupfile;min.availprocess;min.availstartupfile;min.availprocessdescriptors;default SoftHardMaxrealtimeMaxrealtime\h66步排查ss&netstat統(tǒng)計(jì)結(jié)果不一樣的原因 PAGE75 PAGE76>6ss&netstat6ss&netstatTotal:Total:30756(kernel 34076(estab9，closed34011，orphaned0，synrecv0，timewait4184/0)，ports0Transport netstat##netstat-n|awk'/^tcp/{++S[$NF]}END{for(ainS)printa，S[a]}'ESTABLISHED9TIME_WAITstrace##strace-F-ff-t-tt-s4096-os.outss-1563360794.995285open("/proc/net/sockstat"，O_RDONLY)=1563360794.995358fstat(3，{st_mode=S_IFREG|0444，st_size=0，...})=1563360794.995417mmap(NULL，4096，PROT_READ|PROT_WRITE，MAP_PRIVATE|MAP_1563360794.995470read(3，"sockets:used30741\nTCP:inuse11orphan0tw4671alloc29878mem847\nUDP:inuse9mem2\nUDPLITE:inuse0\nRAW:inuse2\nFRAG:inuse0memory0\n"，1024)=strace-F-ff-t-tt-s4096-on.outnetstat-1563360883.910941open("/proc/1500/attr/current"，O_RDONLY|O_CLOEXEC)=1563360883.910993read(5，0x56114ec94ba0，4095)=-1EINVAL1563360883.911051 =1563360883.911106readlink("/proc/1500/fd/6"，"socket:[38288]"，29)=1563360883.911159open("/proc/1500/attr/current"，O_RDONLY|O_CLOEXEC)=1563360883.911209read(5，0x56114ec94c00，4095)=-1EINVAL1563360883.911257 =1563360883.911304readlink("/proc/1500/fd/7"，"socket:[38289]"，29)=1563360883.911357open("/proc/1500/attr/current"，O_RDONLY|O_CLOEXEC)=1563360883.911407read(5，0x56114ec94c60，4095)=-1EINVAL1563360883.911454 =1563360883.911502readlink("/proc/1500/fd/8"，"socket:[38290]"，29)=1563360883.911554open("/proc/1500/attr/current"，O_RDONLY|O_CLOEXEC)=1563360883.911604read(5，0x56114ec94cc0，4095)=-1EINVAL1563360883.911651 =1563360883.911699readlink("/proc/1500/fd/9"，"socket:[38291]"，29)=1563360883.911751open("/proc/1500/attr/current"，O_RDONLY|O_CLOEXEC)=1563360883.911801read(5，0x56114ec94d20，4095)=-1EINVAL1563360883.911848 =1563360883.911919readlink("/proc/1500/fd/10"，"socket:[38292]"，29)=1563360883.911972open("/proc/1500/attr/current"，O_RDONLY|O_CLOEXEC)=5#grep-csocket1.out.764netstatsocket，為什么輸出的時(shí)候沒ByBydefault，netstatdisplaysalistofopensockets.Ifyoudon’tspecifywillbe找出來哪個(gè)pidsocket/proc/pid/fdsocket|wc-l2>/dev/null);[-n"$s"]&&echo"$s$pid";done|sort-n|tail-20/proc/7136/目錄查看cmdlineps-|greppid為什么明明內(nèi)存很充足但是為什么明明內(nèi)存很充足但是java程序仍申請不到內(nèi)存 PAGE79 PAGE78javajava8G（7G）java4GOOM。oom4g4294967296/1024/10244096M第一反應(yīng)是想起來之前的vm.min_free_kbytes&nr_hugepagefreeavailablecentos7centos7memavailable小于MemFree:Thesumof+MemAvailable:Anestimateofhowmuchmemoryisavailableforstarting applications，withoutswapping.Calculatedfrom SReclaimable，thesizeofthefileLRUlists，andthe watermarksineach Theestimatetakesintoaccountthatthesystemneeds pagecachetofunctionwell，andthatnotallslabwillbereclaimable，duetoitemsbeinginuse.impactofthosefactorswillvaryfromsystemtomemfree統(tǒng)計(jì)的是所有內(nèi)存的free內(nèi)存，而memavailablenr_hugepage跟客戶要freem&&sysctlp&&/proc/meminfoHugePages_Total0nr_hugepage。MemAvailable:7418172kB#sysctl-pnet.ipv4.ip_forward#sysctl-pnet.ipv4.ip_forward=0net.ipv4.conf.default.accept_source_route=kernel.sysrq=kernel.core_uses_pid=net.ipv4.tcp_syncookies=kernel.msgmnb=kernel.msgmax=kernel.shmmax=kernel.shmmni=kernel.shmall=net.ipv4.conf.all.arp_filter=1net.ipv4.ip_local_port_range=1025kernel.msgmni=2048net.ipv4.tcp_max_tw_buckets=5000net.ipv4.tcp_max_syn_backlog=net.ipv4.tcp_keepalive_time=600#cat/proc/meminfo 8009416 34359738367 21452 34359707388 0 126976 0 0 2048 114560 4079616 6291456memifo已經(jīng)說明了問題，但是由于經(jīng)驗(yàn)不足，一時(shí)沒有看明白怎[root@test~]#java-Xmx8192M-versionOpenJDK64-BitServerVM(build25.242-b08，mixedmode)memory(0x00000005c0000000，5726797824，0)failed;error='Cannotallocatememory'(errno=12)#Anerrorreportfilewithmoreinformationissavedas:[root@test~]#java-Xms4096M-versionOpenJDK64-BitServerVM(build25.242-b08，mixedmode)memory(0x0000000687800000，3495428096，0)failed;error='Cannotallocatememory'(errno=12)SYSTEOS:CentOSLinuxrelease7.4.1708uname:Linux3.10.0-693.2.2.el7.x86_64#1SMPTueSep1222:26:13UTClibc:glibc2.17NPTLrlimit:STACK8192k，CORE0k，NPROC15088，NOFILE65535，ASinfinityloadaverage:0.050.050.05 34359738367 14280 34359715580 0 30720 2048 57216 3088384 3145728kBcontainer(cgroup)information:container_type:cgroupv1cpu_cpuset_cpus:0-1cpu_memory_nodes:active_processor_count:cpu_quota:-cpu_period:cpu_shares:-memory_limit_in_bytes:-memory_and_swap_limit_in_bytes:-memory_soft_limit_in_bytes:-memory_usage_in_bytes:memory_max_usage_in_bytes:CPU:total2(initialactive2)(1corespercpu，2threadspercore)6model79stepping1，cmov，cx8，fxsr，mmx，sse，sse2，sse3，ssse3，sse4.1， : : Intel(R)Xeon(R)CPUE5-2682v4@ cpu 40960physicalid core cpu initialapicid:0 :yes cpuidlevel:13 : popcnttsc_deadline_timeraesxsaveavxf16crdrandhypervisorlahf_lmabmbmi1hleavx2smepbmi2ermsinvpcidrtmrdseedadxsmapxsaveopt :5000.07clflushsize cache_alignment:address :46bitsphysical，48bitspower Intel(R)Xeon(R)CPUE5-2682v4@ cpu 40960physicalid core cpu initialapicid:1 :yes cpuidlevel:13 : :fpuvmedepsetscmsrpaemcecx8apicsepmtrrpgemcapatpatpse36clflushmmxfxsrssesse2sshtsyscallnxpdpe1gbrdtscplmconstant_tscrep_goodnoplpopcnttsc_deadline_timeraesxsaveavxf16crdrandhypervisorlahf_lmabm3dnowprefetchfsgsbasetsc_adjustbmi1hleavx2smepbmi2ermsinvpci