From owner-freebsd-stable@FreeBSD.ORG Thu Mar 26 21:03:46 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 99C65505; Thu, 26 Mar 2015 21:03:46 +0000 (UTC) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5EC17A06; Thu, 26 Mar 2015 21:03:46 +0000 (UTC) Received: by igcau2 with SMTP id au2so3650765igc.0; Thu, 26 Mar 2015 14:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lm6YCH4QGKFXtMhAQGYmxRQgkPvXVbfYDgUI/PEqNqc=; b=qKFaSTeOyJbwquO4GtB8cq8XMNrRtGmtHK/JVgqc6qTKcWd4Fgjb4NsyDTgs0OLl3b JJPp9LebaLREtf/QQEajud6Ohu4Mh7SGjVtErh6LfUcJqzsODhCfsUIUiP7ojwDL6d6p i7QabMObIDam2HC3qkgld73tMmVfHTSFpPmzPBwbYwW1OxYC3a/SxBq/aBGbJeef+sJv bBmM5c4Psglh+JILrsaPyPlvYxgm6g3yNVvKk5Ps+kr2T5gFCyn94gEXIW+JX5T178hr LEGHObhBrGpEcm0fOJ66xJwCn0J/vVisO4cxynfYlwfdYgUqe+Ttndrk7Zg7XxpudvWC Vy1A== MIME-Version: 1.0 X-Received: by 10.50.29.68 with SMTP id i4mr3769987igh.35.1427403825652; Thu, 26 Mar 2015 14:03:45 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.174.86 with HTTP; Thu, 26 Mar 2015 14:03:45 -0700 (PDT) In-Reply-To: References: <20150316232404.GM2379@kib.kiev.ua> Date: Thu, 26 Mar 2015 14:03:45 -0700 X-Google-Sender-Auth: qnnW-2Iq4OeJGmyAGshRxGHbcLg Message-ID: Subject: Re: Significant memory leak in 9.3p10? From: Kevin Oberman To: J David Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-stable , "freebsd-questions@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 21:03:46 -0000 On Thu, Mar 26, 2015 at 12:46 PM, J David wrote: > On Mon, Mar 16, 2015 at 7:52 PM, J David wrote: > > On Mon, Mar 16, 2015 at 7:24 PM, Konstantin Belousov > > wrote: > >> There are a lot of possibilities to create persistent anonymous shared > >> memory objects. Not complete list is tmpfs mounts, swap-backed md > disks, > >> sysv shared memory, possibly posix shared memory (I do not remember > which > >> implementation is used in stable/9). > > > > If that's the explanation, how could it be > > detected/measured/investigated/resolved/prevented? > > > > Under ordinary circumstances, machines will go run like this for > days/weeks: > > > > Mem: 549M Active, 3623M Inact, 567M Wired, 3484K Cache, 827M Buf, 3156M > Free > > Swap: 1024M Total, 1024M Free > > > > Then, when this happens, it rapidly degrades from that to so bad that > > processes start getting killed for being out of swap space. > > These FreeBSD machines running out of swap space and dying continues > to be a daily problem causing outages and unscheduled reboots. Is > there really no way to even research what might be causing the > problem? > > (Widening the cross-posting in the hopes of eliciting more help, so > the brief summary of the problem orginally posted to freebsd-stable is > that an unknown actor consumes all the user-space memory in the > system, including swap space, to the point where processes are killed > for being out of swap space, but if every process on the machine is > stopped, very little of the user-space memory in use is freed. > Original message with more details is here: > https://lists.freebsd.org/pipermail/freebsd-stable/2015-March/081986.html > .) > > There are no tmpfs mounts or md disks, so it would have to be one of > the other causes. How can FreeBSD's use of persistent, anonymous > shared memory objects be investigated, measured, or controlled so we > can get a handle on this issue? > This is just a shot in the dark and not a really likely one, but I have had issues with Firefox leaking memory badly. I can free the space by killing firefox and restarting it. It seems to be linked to certain web sites, probably javascript. I have not been able to confirm which one does it. It just will start growing until the system slows to a crawl as too many things are swapped out. Normally my system does not touch swap. If it is in user space, top should show it under RES. -- Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com