Re: Add --human flag to slabtop
"Krzysztof Piecuch" <[email protected]> ("piecuch") Wed, 11 Oct 2023 18:44:13 +0000
| Newsgroups | gmane.linux.procps.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi Craig, thanks for merging that. Sorry I forgot to update NEWS and manpage. I'd also like to upgrade vmstat - I'd like `bi`, `bo`, `in`, `cs` fields to not mangle the rest of columns. See the end of e-mail (Supplement 1) for= en example of a garbled output on a big server. I wonder what's the best idea: - make `--wide` even wider - make `vmstat` cooperate with `column -t` - `vmstat 1 5 | column -t` gives prettier results than `vmstat --wide` except it's not real-time - add an extra switch (--unit-io) for bi/bo and an extra switch for system (--unit-system)... - make `-SM` to apply to bi, bo, in, cs as well. Minor nitpick - Currently, the docs on `-S` say > Note this does not change the block (bi/bo) fields, which are always mea= sured in blocks. which for the current code should be reworded to > Note this changes only memory and swap sections. - reorder the troublesome columns to the end of the output - `cpu` section is actually the most well-behaved because the values are bounded. If we put it next to `procs`, noise introduced by big numbers in io/system sections won't have that much of an effect. See Supplement 2 for example, which is the same data as at the end of the e-mail but "cpu" was shuffled to the left. I like it more than the original output, but there's still a problem of tracing spikes in the unaligned columns (i.e. it's not trivial to see if there was a period when `cs` or `in` showed 10x the normal value) We need to keep in mind that running vmstat on busy, multi-cpu machine for extended period of time (vmstat 60) will inflate the counters even more. The example below is for 48-logical-cpu box. I think to plan for the future, vmstat should make the table readable for 500-core box, ran at 60s interval, so we should budget for at least 3 extra orders of magnitude to the example output below. Can you please suggest the best solution here? Thanks, Kris Supplement 1: example output on a 48-core server [email protected]:~# vmstat -SM --wide 1 --procs-- -----------------------memory---------------------- ---swap-- ---= --io---- -system-- --------cpu-------- r b swpd free buff cache si so = bi bo in cs us sy id wa st 2 1 0 177010 1 42988 0 0 = 44 5877 0 0 10 5 78 7 0 3 1 0 177027 1 42988 0 0 = 75 2392 30138 38917 3 1 94 2 0 0 1 0 177026 1 42988 0 0 = 86 2080 27563 30582 4 1 93 2 0 5 2 0 177307 1 42988 0 0 = 43 1685248 33485 47178 2 7 88 3 0 0 2 0 176895 1 42988 0 0 = 22 1820964 35203 65599 2 4 89 4 0 1 0 0 177004 1 42988 0 0 = 21 126812 34613 57499 3 2 93 2 0 2 0 0 177007 1 42988 0 0 = 0 280 30083 35506 4 2 95 0 0 2 0 0 177011 1 42988 0 0 = 0 0 34153 34912 2 1 96 0 0 3 1 0 177268 1 42988 0 0 = 0 1613456 31176 41964 2 7 90 1 0 ^c Supplement 2: reordered columns for readability [email protected]:~# vmstat -SM --wide 1 --procs-- --------cpu-------- -----------------------memory----------------= ------ ---swap-- -----io---- -system-- =20 r b us sy id wa st swpd free buff = cache si so bi bo in cs =20 2 1 10 5 78 7 0 0 177010 1 = 42988 0 0 44 5877 0 0 =20 3 1 3 1 94 2 0 0 177027 1 = 42988 0 0 75 2392 30138 38917 =20 0 1 4 1 93 2 0 0 177026 1 = 42988 0 0 86 2080 27563 30582 =20 5 2 2 7 88 3 0 0 177307 1 = 42988 0 0 43 1685248 33485 47178=20 0 2 2 4 89 4 0 0 176895 1 = 42988 0 0 22 1820964 35203 65599=20 1 0 3 2 93 2 0 0 177004 1 = 42988 0 0 21 126812 34613 57499 =20 2 0 4 2 95 0 0 0 177007 1 = 42988 0 0 0 280 30083 35506 =20 2 0 2 1 96 0 0 0 177011 1 = 42988 0 0 0 0 34153 34912 =20 3 1 2 7 90 1 0 0 177268 1 = 42988 0 0 0 1613456 31176 41964=20 ^C