Replies: 2 comments 1 reply
-
|
@PingXie Delightful timing. We (AWS) were going to propose a new Memory is a bit of a harder problem unless we make it "approximate". There has been some discussion about having some type of async process that incrementally scans the memory in the database and provides a better approximation, but that isn't quite point in time. It will find hot keys though. |
Beta Was this translation helpful? Give feedback.
-
|
This is great news, @madolson. Right, the per-slot memory footprint would have to be estimated. It will be hard to attribute external fragmentation to a particular key or slot IMO. I am thinking about just counting the key size, value size, and the data structure overhead while processing a "write" command and having this stat recorded in Regarding the command shape, I am concerned about the sheer size of the output if there is no way for the caller to filter hence the proposal to allow a set of slots to be specified. On a further thought, it will be nicer if a short-handed range version could be provided, such as I think an even more natural command would allow the application to provide some other filters on say memory_usage or cpu_time. We could start simple by just supporting one condition first. For instance It would be nice if the syntax would allow open range queries such as memory_usage > 10000 but I feel that could be easily worked around by providing a large (or small) enough value for the "open" end. I like the use of dict format for command output. It is very extensible. |
Beta Was this translation helpful? Give feedback.
-
|
For continuity, let's move future discussions here: #10472. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
With the new slotToKey struct, it is possible to start tracking some metrics, such as memory usage (key size + value size but not counting fragmentation) and keyspace_hits, at the slot level. I can see this information being useful for an application to understand the skew in its workload. I wonder what is the best way to expose these metrics? Should it be part
INFOorCLUSTER INFO, which would make the output explode though? Or should it be exposed via a new cluster command,CLUSTER GETSLOTINFO <slot_number_1> <slot_number_2> ... <slot_number_n>perhaps? @zuiderkwast @madolson what are your thoughts?Beta Was this translation helpful? Give feedback.
All reactions