Bug 2152156 - cockpit server monitor does not display rss
Summary: cockpit server monitor does not display rss
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Directory Server
Classification: Red Hat
Component: 389-ds-base
Version: 11.6
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: DS11.6
: dirsrv-11.7
Assignee: mreynolds
QA Contact: LDAP QA Team
Zuzana Zoubkova
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-12-09 14:10 UTC by Anton Bobrov
Modified: 2023-05-23 12:17 UTC (History)
6 users (show)

Fixed In Version: redhat-ds-11-8080020230330140549-f969626e
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-05-23 09:27:55 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Screenshot of the memory monitor (52.84 KB, image/png)
2023-04-24 09:32 UTC, Viktor Ashirov
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker IDMDS-2896 0 None None None 2023-03-30 12:00:17 UTC
Red Hat Issue Tracker IDMDS-2925 0 None None None 2023-04-04 14:46:13 UTC
Red Hat Product Errata RHBA-2023:3267 0 None None None 2023-05-23 09:28:34 UTC

Description Anton Bobrov 2022-12-09 14:10:36 UTC
Description of problem:

The cockpit Monitoring->Server Statistics->Resident Size section is broken. It either displays "NaN" or "0 Kb" (depending on the version). Underneath it is parsing the output of

top -n 1 -b -p PID | tail -1

which would be something like this

1753 dirsrv    20   0 2486224   1,6g   1,6g S   6,2   5,3  46:19.07 ns-slapd

The "1,6g" is definitely Not A Number and so it fails with NaN exception there.

Its probably not a good idea to parse top output to get these numbers bc afaik there is no API contract for these things and so if it has to parse the output from a command to get these figures it would be better to use ps where the output can be controlled explicitly.

Comment 1 mreynolds 2022-12-09 14:42:52 UTC
This is just flakely.  This has been "fixed" like 3 times.  Sometimes on the same system it works fine, and other times it does not.   The output is just inconsistent, so the parsing needs work...

Comment 2 mreynolds 2023-01-05 13:59:52 UTC
Upstream ticket:

https://github.com/389ds/389-ds-base/issues/5521

Comment 6 Viktor Ashirov 2023-04-24 09:32:42 UTC
Created attachment 1959491 [details]
Screenshot of the memory monitor

Builds tested:
389-ds-base-1.4.3.34-1.module+el8dsrv+18528+22f7779f.x86_64
cockpit-389-ds-1.4.3.34-1.module+el8dsrv+18528+22f7779f.noarch

Memory monitor numbers look correct. So I'm marking this bug as VERIFIED.

But I agree with Anton that we should not rely on top's output. Under the hood top uses /proc file system. So instead of calling top, we can access it directly:

# top -n 1 -b -p $(pidof ns-slapd) | tail -1
  17882 dirsrv    20   0 1138224 600424 144760 S   6.7  33.0   0:48.87 ns-slapd

# grep 'VmSize\|VmRSS' /proc/$(pidof ns-slapd)/status
VmSize:  1138224 kB
VmRSS:    600424 kB

Sometime ago I filed https://bugzilla.redhat.com/show_bug.cgi?id=2171421 to move some of the monitoring logic to dsconf monitor. Instead of calling top/netstat and parse/transform their output we can access the same OS primitives as these tools use from lib389 and present them in json to the WebUI directly.

Comment 8 errata-xmlrpc 2023-05-23 09:27:55 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (redhat-ds:11 bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:3267


Note You need to log in before you can comment on or make changes to this bug.