From nobody Tue Jan 25 21:56:01 2022 X-Original-To: questions@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C62CC197DF36 for ; Tue, 25 Jan 2022 21:56:11 +0000 (UTC) (envelope-from yuri@aetern.org) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jk0zZ5GXFz3NxB for ; Tue, 25 Jan 2022 21:56:10 +0000 (UTC) (envelope-from yuri@aetern.org) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 7DD6A5C0258 for ; Tue, 25 Jan 2022 16:56:04 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 25 Jan 2022 16:56:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aetern.org; h=cc :content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; bh=zCvXVOTE5c4RnW dMpKS08U1cIcpNt68tFXqBSIDSK64=; b=eSZDSqRJ0XEZ4JqymcQxdhW8yqLXQ+ WHJ8/su7b61Hc/IHDtL+qFEwL3+mc11xP/E7j7VFkHRGeCvJRw9QomQLgGkMn1Vb LzY0+AvYX5Db6iJkGPnKdhXcnMrl5uapwajdI7y5nU3ddW9iD1puc7a8sxwVq82D B+Z8fLdl+Jemu6K0tDr2WWs9QtHXkwcZ1zwGIOyTsdMvuAPmwxYH7a4zQ9w9F6AX TCIA4pTRcPezPmf/lsEEXU9koElKVTkeo0UslGOqkGQV2Hxei4Jnaqm3P6EymE2i ju0wgHMdY1rOg8xpGCnWLIZIU+KWAx/gWSUPYAlOovt6wVpAd7hpC+PQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=zCvXVOTE5c4RnWdMpKS08U1cIcpNt68tFXqBSIDSK64=; b=dl3iinbe NCs3pfVXrJOCnlS2j6tJenTMzsS7ID5lV1XcEiPJCLNb770YWZUonGh+lsReFf3A d1VzMG1K/82WtbeFNayF9ZMcgE/sF/vBJItE2LQk9Z70ur5hBV4BEvg4c3qwJ9FU SNfiHldX29lYYFaHFIqm7nZbxk05mbHcM3A6HLIjX9Q+mwEkhiRbSch0cg4q5l0Z Jvdklu0QdmqvlMcYSjeE0PZuNRWgzL008FrHKyLlmjBQDb38H8RmgBfSdfSLtxIs A4qDY5Ie4pGQTI8HCLfhJ8bsWSQVlnO3hBQf0pMEdyssw439eOpnIEApem2lpWrw Za8NeHIzYZ9sxg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrvdelgdduheefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfgfuvfhfhfgjtgfgsehtke ertddtfeejnecuhfhrohhmpegjuhhrihcuoeihuhhrihesrggvthgvrhhnrdhorhhgqeen ucggtffrrghtthgvrhhnpefhheffgfegieejfffgvdeuiedttedvueffuedtheevhefhhe eugeekhfduffekfeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhephihurhhisegrvghtvghrnh drohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 25 Jan 2022 16:56:02 -0500 (EST) Message-ID: <32b08d62-9ecc-37e9-738c-39e5ad1a1c1c@aetern.org> Date: Wed, 26 Jan 2022 00:56:01 +0300 List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: snmp oid for memory usage, vmstat -i and others Content-Language: en-US To: questions@freebsd.org References: <0c8e1634-d4e2-2ecb-0af4-9f4eceab9124@aetern.org> <5e9eb718-0472-fba1-0880-06f539e04790@otcnet.ru> From: Yuri In-Reply-To: <5e9eb718-0472-fba1-0880-06f539e04790@otcnet.ru> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4Jk0zZ5GXFz3NxB X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=aetern.org header.s=fm2 header.b=eSZDSqRJ; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=dl3iinbe; dmarc=none; spf=pass (mx1.freebsd.org: domain of yuri@aetern.org designates 66.111.4.29 as permitted sender) smtp.mailfrom=yuri@aetern.org X-Spamd-Result: default: False [-4.60 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.29]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[aetern.org:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.29:from]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[aetern.org:s=fm2,messagingengine.com:s=fm1]; FREEFALL_USER(0.00)[yuri]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[questions@freebsd.org]; DMARC_NA(0.00)[aetern.org]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; MLMMJ_DEST(0.00)[questions]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.111.4.29:from] X-ThisMailContainsUnwantedMimeParts: N Victor Gamov wrote: > Hi Yuri > > Thanks for your reply! > > So, I can find total memory via HOST-RESOURCES-MIB::hrMemorySize.0 > > But how to calculate used memory?  I guess I need to find all > HOST-RESOURCES-MIB::hrStorageType = HOST-RESOURCES-TYPES::hrStorageRam > and then multiply corresponding hrStorageAllocationUnits * hrStorageSize > and sum all of them. > > Is it correct? If no one has any better ideas, here's a quick "fix" for bsnmpd to report physical memory instead (same as net-snmp does): https://github.com/yuripv/freebsd-src/commit/1aff8b31cfe7648667328dc3444d17eff58486e6 > On 25.01.2022 08:32, Yuri wrote: >> Yuri wrote: >>> Victor Gamov wrote: >>>> Hi All >>>> >>>> Some questions about bsnmpd. >>>> >>>> Is it possible to get memory usage via bsnmpd?  When I tried to get >>>> something like "snmpget hrStorageDescr.1 hrStorageAllocationUnits.1 >>>> hrStorageSize.1 hrStorageUsed.1" then I've got this values: >>>> >>>> ===== >>>> HOST-RESOURCES-MIB::hrStorageDescr.1 = STRING: Real Memory Metrics >>>> HOST-RESOURCES-MIB::hrStorageAllocationUnits.1 = INTEGER: 4096 Bytes >>>> HOST-RESOURCES-MIB::hrStorageSize.1 = INTEGER: 391488 >>>> HOST-RESOURCES-MIB::hrStorageUsed.1 = INTEGER: 391252 >>>> ===== >>>> >>>> How I must process it to calculate actual memory usage for machine with >>>> 4GB RAM and without swap? >>>> >>>> ===== >>>> $ sysctl hw | egrep 'hw.(phys|user|real)' >>>> hw.physmem: 4243894272 >>>> hw.usermem: 3580182528 >>>> hw.realmem: 4294967296 >>>> ===== >>> >>> Values returned by bsnmpd look weird to me as well, so I looked into it >>> a bit.  Excerpt from the snmp_hostres (as a standalone test case): >>> ---- >>> #include >>> #include >>> #include >>> >>> #include >>> >>> #include >>> #include >>> >>> static struct vmtotal mem_stats; >>> >>> int >>> main(void) >>> { >>>          int mib[2] = { CTL_VM, VM_TOTAL }; >>>          size_t len = sizeof(mem_stats); >>> >>>          if (sysctl(mib, 2, &mem_stats, &len, NULL, 0) != 0) >>>                  err(1, "sysctl"); >>> >>>          printf("real=%lu\n", mem_stats.t_rm); >>> >>>          return (0); >>> } >>> ---- >>> output: >>> real=31632 >>> ---- >>> >>> Now the sysctl output: >>> ---- >>> $ sysctl vm.vmtotal >>> vm.vmtotal: >>> System wide totals computed every five seconds: (values in kilobytes) >>> =============================================== >>> Processes:              (RUNQ: 1 Disk Wait: 0 Page Wait: 0 Sleep: 28) >>> Virtual Memory:         (Total: 547240K Active: 542480K) >>> Real Memory:            (Total: 126572K Active: 125600K) >>> Shared Virtual Memory:  (Total: 4612K Active: 0K) >>> Shared Real Memory:     (Total: 924K Active: 0K) >>> Free Memory:    3608396K >>> --- >>> I can't map the output to anything on the system (16G RAM, 16G swap) >>> except for the "Free Memory", it matches. >>> >>> 31632 ("real") * 4096 ("pagesize") matches the "Real Memory" in sysctl >>> output.  Though to get anything resembling 16G, "real" needs to be >>> multiplied by 512 (K?). >>> >>> As a wild guess, it seems that the units used are wrong here, or I >>> simply don't understand the meaning of these values. >> >> Looking at sys/vmmeter.h, my assumptions above are wrong: >> >> uint64_t        t_rm;           /* total real memory in use */ >> >> But that does not include the "wired" (and other) pages, so I'm not sure >> about this metric usefulness. >> >> In any case, you have the following: >> >> HOST-RESOURCES-MIB::hrMemorySize.0 = INTEGER: 16734232 KBytes >> >