Proof of concept on the usage of crit features for reading memory pages
#69
Conversation
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #69 +/- ##
==========================================
- Coverage 80.00% 79.51% -0.49%
==========================================
Files 3 3
Lines 435 454 +19
==========================================
+ Hits 348 361 +13
- Misses 64 70 +6
Partials 23 23
☔ View full report in Codecov by Sentry. |
|
Now that #56 is merged maybe you could extend the process view with the full command-line. Instead of: This uses the information from the core image filed You can just include go-criu with the SHA and date, not using a released version, but the current latest version from git. |
behouba
force-pushed
the
memory-pages-usage-poc
branch
2 times, most recently
from
be93462 to
9efa578
Compare
Signed-off-by: Kouame Behouba Manasse <[email protected]>
behouba
force-pushed
the
memory-pages-usage-poc
branch
from
9efa578 to
2688e3d
Compare
This commit updates the `--ps-tree` flag ouput. We are now printing the full command-line instead of core image `Comm` field value. Providing more information about arguments used to start the processes. Signed-off-by: Kouame Behouba Manasse <[email protected]>
behouba
force-pushed
the
memory-pages-usage-poc
branch
from
2688e3d to
5f24f39
Compare
|
With the introduction of the
Examples: $ checkpointctl inspect /path/to/checkpoint.tar.gz --ps-tree
counter
└── [1] bash
├── [7] bash
├── [7] counter.py
├── [8] bash
└── [8] tee$ checkpointctl inspect /path/to/checkpoint.tar.gz --ps-tree --ps-args
counter
└── [1] bash
├── [7] bash -c 'python counter.py'
├── [7] python counter.py --input data.txt --output result.txt
├── [8] bash -c 'tee output.log'
└── [8] tee output.log
Example: $ checkpointctl inspect /path/to/checkpoint.tar.gz --ps-tree --ps-env-vars
counter
└── [1] bash
├── [7] bash
│ ├── [7] counter.py
│ │ ├── [7] PYTHONPATH=/usr/local/lib/python3.9/site-packages
│ │ └── [7] DEBUG_MODE=true
│ ├── [8] bash
│ └── [8] tee
└── [8] tee
└── [8] OUTPUT_DIR=/var/log
What do you think @rst0git , @adrianreber ? |
It makes sense. For example, we can introduce something like the following two options:
The content of memory pages could be several gigabytes and it might not be appropriate to show all of it in a terminal. However, we can introduce a sub-command, for example @adrianreber What do you think? |
Looks good. |
|
@behouba A container checkpoint may include multiple processes, each with potentially large amount memory. To analyze the memory of a checkpoint it might be useful to display an overview of the memory size of each process, as well as to show the memory pages for a specific process. Would it make sense to implement this as a table showing all PIDs, process names, and memory size for each process? For example, when the We could implement this as new sub-command for checkpointctl with description "Analyze container checkpoint memory", or extend the existing ( @behouba @adrianreber What do you think? |
Implementing this as a table with PIDs, process names, and memory sizes for each process seems to me like a good approach. Also, the --pid an --output options would add flexibility and usability to view to content of the memory pages.
In my option, adding a new sub-command for this use case is more appropriate. However, I am unsure about the most suitable name for this sub-command. What about |
"parse" is defined as "to examine computer data and change it into a form that can be easily read or understood". The following wiki page has some relevant examples of the Volatility interface for memory analysis: |
I totally agree, |
|
Closing in favour of #95 |
This proof of concept introduces the following new flags:
Example output
Information about the new flags:
$ ./checkpointctl show --help Show information about available checkpoints Usage: checkpointctl show [flags] Flags: --all Display all additional information about the checkpoints --full-paths Display mounts with full paths -h, --help help for show --mounts Print overview about mounts used in the checkpoints --pid uint32 The PID of the process to display. This option should be used with [--ps-args | --ps-env-vars | --ps-memory-pages] --ps-args Display the arguments for the specified pid --ps-env-vars Display environment variables for the specified pid --ps-memory-pages Display memory pages for the specified pid in hexdump format --stats Print checkpointing statistics if availableExample of ps-args:
Example of ps-env-vars:
Example of ps-memory-pages:
I am still uncertain about the design of the new flags. 🤔
Please note that the CI is expected to fail because the version of the
critpackage used in this code is copied from checkpoint-restore/go-criu#133.