From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 1 13:23:35 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 870641065675 for ; Thu, 1 Dec 2011 13:23:35 +0000 (UTC) (envelope-from prvs=1316828ddc=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 0E0D78FC17 for ; Thu, 1 Dec 2011 13:23:34 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Thu, 01 Dec 2011 13:23:32 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 01 Dec 2011 13:23:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50016825590.msg for ; Thu, 01 Dec 2011 13:23:30 +0000 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1316828ddc=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org Message-ID: From: "Steven Hartland" To: "Damien Fleuriot" , References: <547298A3C38F407887E1AAAAC487DF6D@multiplay.co.uk><20111201065722.GA97051@DataIX.net><1A338C6C470940B386C307641E350A3E@multiplay.co.uk> <4ED77650.6050409@my.gd> Date: Thu, 1 Dec 2011 13:23:35 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: Subject: Re: Invalid memory stats from vmstat and sysctl vm.vmtotal? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 13:23:35 -0000 ----- Original Message ----- From: "Damien Fleuriot" >> I could understand a bit of overflow as stats are snapshots which may not >> be instuntanious, but 31GB instead of under 8GB is hardly a rounding >> issue / >> overflow. >> >> With respect to top showing greater than 100% by how much are you talking? >> Do your realise that each core = 100%? So if you have a quad core your >> system >> total will be 400% not 100%? >> > > That's his point, you cannot use 400% of a system as a whole, his point > is that top should report 100% where each core accounts for 25% Then I would have to disagree, keeping 100% to mean 100% of a single core is much easier to manage than 100% of a machines total capacity. If you went to 100% = the machine total capacity processes could be using a lot of cpu without even registering 1% on today's machines where 24 cores is common place. It also makes detecting single process / thread bottlenecks easier as if your seeing 100% you know its maxing a core, instead of having to calculate it once you know how many cores the machine has. If your looking for total machine usage then that's also their in the summary at the top of the screen e.g. CPU states: 13.6% user, 0.0% nice, 1.3% system, 0.0% interrupt, 85.1% idle Anyway this is quite off topic, and I don't want to loose sight of the threads goal which is to determine why we can see 31GB of usage on an 8GB machine with very little shared memory usage an no swap usage. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk.