Date: Tue, 3 Dec 2019 11:32:53 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: Peter Eriksson <pen@lysator.liu.se>, FreeBSD FS <freebsd-fs@freebsd.org> Subject: Re: Slow reboots due to ZFS cleanup in kern_shutdown() .. zio_fini() Message-ID: <381ab886-fc3b-75e9-afa7-7bde1f712055@FreeBSD.org> In-Reply-To: <DAD21732-AB7C-4B8D-99BF-25C7DD238A31@lysator.liu.se> References: <AD17E454-6A51-436D-A853-07F04A406EC9@lysator.liu.se> <D2A11CE9-9B24-4E40-A51A-8D318E0288C9@lysator.liu.se> <20191202225424.GG43802@raichu> <3b71fe37-c29f-e3e5-ff96-5dce15cc7553@FreeBSD.org> <DAD21732-AB7C-4B8D-99BF-25C7DD238A31@lysator.liu.se>
next in thread | previous in thread | raw e-mail | index | archive | help
On 03/12/2019 11:29, Peter Eriksson wrote: > It’s a fairly standard Dell PowerEdge R730xd server with Intel Xeon E5-2620v4 > CPUs & 256GB of RAM… (and an LSI SAS3 HBA and Intel 10GE ethernet) > > CPU: Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz (2100.04-MHz K8-class CPU) > Origin="GenuineIntel" Id=0x406f1 Family=0x6 Model=0x4f Stepping=1 > > Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > > Features2=0x7ffefbff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND> > AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM> > AMD Features2=0x121<LAHF,ABM,Prefetch> > Structured Extended > Features=0x21cbfbb<FSGSBASE,TSCADJ,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,NFPUSG,PQE,RDSEED,ADX,SMAP,PROCTRACE> > Structured Extended Features3=0x9c000400<MD_CLEAR,IBPB,STIBP,L1DFL,SSBD> > XSAVE Features=0x1<XSAVEOPT> > VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr > TSC: P-state invariant, performance statistics > real memory = 274869518336 (262136 MB) > avail memory = 267244859392 (254864 MB) > Event timer "LAPIC" quality 600 > ACPI APIC Table: <DELL PE_SC3 > > FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs > FreeBSD/SMP: 2 package(s) x 8 core(s) x 2 hardware threads > > - Peter > >>> >>> uma_destroy() frees all of the memory cached in the zone back to the >>> page allocator. This operation takes time proportional to the number of >>> cached items. I would expect most of the time to be spent in >>> zone_reclaim(), called by zone_dtor(). >> >> But spending *minutes* there is really unexpected. >> I have never seen anything like that. >> I wonder if there is anything untypical about the system's hardware (like a very >> big number of processors) or configuration. Yes, this is pretty typical. If you don't have root on ZFS (or can arrange that) maybe you can experiment with kldunload-ing of zfs. That way you will have more tools at your disposal for diagnosing the problem. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?381ab886-fc3b-75e9-afa7-7bde1f712055>