Capture data for huge page bloat monitoring#204
Conversation
|
@arthurp this PR also requires on container startup. I could add this to the setup script for benchmarking, but how can I just add nc to the container image itself? |
Let's just add it to the container. You can add it to the Dockerfile. We need to update the image version and the images we use for the builds anyway, so as soon as you add it, I can update the image in dockerhub and the version used by the build. |
arthurp
left a comment
arthurp
left a comment
There was a problem hiding this comment.
This is all written against the old data capture framework. The update in #206 changes things. I think the best approach is to remove the BinarySerde derives and the actual capture code (replacing it with TODOs so it's easy to find and fix), leaving the new OQueues. Then, you or I can add the actual data capture back in after merging #206. In fact, with the socket code removed and the data capture removed, this PR might end up effectively empty. In that case, we can just redo the capture after #206 lands.
| static SOCKET_OQUEUE: Once<Arc<MPMCOQueue<SocketOQueueMessage>>> = Once::new(); | ||
|
|
||
| pub fn get_socket_oqueue() -> Arc<MPMCOQueue<SocketOQueueMessage>> { | ||
| SOCKET_OQUEUE.wait().clone() | ||
| } |
There was a problem hiding this comment.
I think it should be pretty straightforward to pull the socket OQueues into a separate PR. Doing so is worth it I think.
| println!("huge_mapping_enabled={}", huge_mapping_enabled); | ||
| println!( | ||
| "huge_mapping_preserve_on_dontneed={}", | ||
| huge_mapping_preserve_on_dontneed | ||
| ); |
There was a problem hiding this comment.
I think these are debug prints. But I could be convinced otherwise.
2 participants
This PR adds the necessary infrastructure to monitor the memory subsystem to determine if bloat is occurring when using huge pages.