Date: Tue, 18 Mar 2014 14:36:04 -0500 From: Karl Denninger <karl@denninger.net> To: John Baldwin <jhb@freebsd.org>, freebsd-hackers@freebsd.org Cc: Alan Cox <alc@freebsd.org> Subject: Re: Tracking down what has inact pages locked up Message-ID: <5328A024.6050901@denninger.net> In-Reply-To: <201403181505.47349.jhb@freebsd.org> References: <53260B36.2070409@denninger.net> <201403181505.47349.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On 3/18/2014 2:05 PM, John Baldwin wrote: > On Sunday, March 16, 2014 4:36:06 pm Karl Denninger wrote: >> Is there a reasonable way to determine who or what has that memory >> locked up -- and thus why the vm system is not demoting that space into >> the cache bucket so it can be freed (which, if my understanding is >> correct, should be happening long before now!) > I have a hackish thing (for 8.x, might work on 10.x) to let you figure out > what is using up RAM. This should perhaps go into the base system at some > point. > > Grab the bits at http://people.freebsd.org/~jhb/vm_objects/ > > You will want to build the kld first and use 'make load' to load it. It adds > a new sysctl that dumps info about all the VM objects in the system. You can > then build the 'vm_objects' tool and run it. It can take a while to run if > you have NFS mounts, so I typically save its output to a file first and then > use sort on the results. sort -n will show you the largest consumer of RAM, > sort -n -k 3 will show you the largest consumer of inactive pages. Note > that 'df' and 'ph' objects are anonymous, and that filename paths aren't > always reliable, but this can still be useful. > Thanks. I suspect the cause of the huge inact consumption is a RAM leak in the NAT code in IPFW. It was not occurring in 9.2-STABLE, but is on 10.0-STABLE, and reverting to natd in userland stops it -- which pretty-well isolates where it's coming from. -- -- Karl karl@denninger.net [-- Attachment #2 --] 0 *H 01 0 + 0 *H O0K030 *H 01 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1/0- *H customer-service@cudasystems.net0 130824190344Z 180823190344Z0[1 0 UUS10UFlorida10UKarl Denninger1!0 *H karl@denninger.net0"0 *H 0 bi՞] MNԿawx?`)'ҴcWgR@BlWh+ u}ApdCF JVй~FOL }EW^bچYp3K& ׂ(R lxڝ.xz?6 &nsJ +1v9 v/( kqĪp[vjcK%fϻe?iq]z lyzFO'ppdX//Lw(3 JI A*S#՟H[f|CGqJKoo y.oEuOw$ /섀$삻J9b|A P~8]D1YI<"""Y^T2iQ2 b yH)] Ƶ0y$ _N 6XqMC 9 XgώjGTP"#nˋ"Bk1 00 U 0 0 `HB0 U 0, `HB OpenSSL Generated Certificate0 U |8 ˴d[20 U #0]Af4 U3x&^"408 `HB+)https://cudasystems.net:11443/revoked.crl0 *H gBwH] j\x`( &gW32"Uf^. ^Iϱ k!DQA g{(w /)\N'[ oRW @C HO>)XrTNɘ!u`xt5(=f\-l3<@C6mnhv##1ŃbH͍_Nq aʷ?rk$^9TIa!kh,D -ct1 0001 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1/0- *H customer-service@cudasystems.net0 + ;0 *H 1 *H 0 *H 1 140318193604Z0# *H 1Vuo`0l *H 1_0]0 `He*0 `He0 *H 0*H 0 *H @0+0 *H (0 +71001 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1/0- *H customer-service@cudasystems.net0 *H 101 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1/0- *H customer-service@cudasystems.net0 *H e$ Aݴ@olQv$Ht)yɩh&0'x{>20\ /[Zi-zм_8w ߛr7<Eiplda)NyQ<33"Q>>_W8l`F0%ID |jSO }jKn*n)2-B-DTnLҁ6 Up6AWq0Ÿ Fa[ 0%Q7T L#:˿rFY]P 2UXIMI+m&2E b!&6{U7EC D6O[ua6Q`y YPvAw!`ר~Nsg 4Lyj5- DLt9Q5NCI {CJWФy ;<K}7~p' Z[5,qA&Gǩ{:|kK6Uuͩi[`a@ Ș- ptHi E0_<j߯l̾gS$QvN
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5328A024.6050901>