Remove client->buf from output buffers in client info.
Technically it is correct that we count that, but the sense of the field
is more the *overhead* of the client compared to the baseline. So we
want to see idle clients at 0.
client argv mem reporting: less precise and expansive.
Avoid doing efforts to include fragmentation and just count the bulk
size: enough to give an hint about clients doing huge argv allocations
(the gist of the original patch was such detection), without risks of
performances impacts.
track and report memory used by clients argv.
this is very usaful in case clients started sending a command and didn't
complete it. in which case the first args of the command are already
trimmed from the query buffer.
fe43406...
by
Salvatore Sanfilippo <email address hidden>
Merge pull request #5397 from bmerry/fix-bad-zmalloc-size
Fix invalid use of sdsZmallocSize on an embedded string
9ce6386...
by
Salvatore Sanfilippo <email address hidden>
Merge pull request #5398 from bmerry/fix-zrealloc-accounting
Fix incorrect memory usage accounting in zrealloc
cd2ee8b...
by
Salvatore Sanfilippo <email address hidden>
Merge pull request #5396 from oranagra/cmdstats_exec
fix #5024 - commandstats for multi-exec were logged as EXEC.
1da93f8...
by
Salvatore Sanfilippo <email address hidden>
Merge pull request #5400 from halaei/fix-dict-get-on-not-found
When HAVE_MALLOC_SIZE is false, each call to zrealloc causes used_memory
to increase by PREFIX_SIZE more than it should, due to mis-matched
accounting between the original zmalloc (which includes PREFIX size in
its increment) and zrealloc (which misses it from its decrement).
I've also supplied a command-line test to easily demonstrate the
problem. It's not wired into the test framework, because I don't know
TCL so I'm not sure how to automate it.
