Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Log live_bytes and heap_size as reported by GHC.Stats #1508

Merged
merged 6 commits into from
Dec 20, 2021

Conversation

mpickering
Copy link
Contributor

@mpickering mpickering commented Mar 6, 2021

A thread is spawned which at a prespecified interval will report the
live bytes and heap size at the last major collection.

Live bytes corresponds to how much live data a program has and should
match closely the value reported during heap profiling.

Heap size reports the total amount of memory the RTS is using, which
corresponds more closely to OS memory usage.

[INFO] Live bytes: 367.45MB Heap size: 676.33MB

Closes #1493

ghcide/ghcide.cabal Outdated Show resolved Hide resolved
@pepeiborra
Copy link
Collaborator

Do either of these values include the bytes allocated in the foreign heap?

Comment on lines +15 to +17
heapStatsInterval :: Int
heapStatsInterval = 60_000_000 -- 60s

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should be a config option

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A command line option? I am not sure configuring this is very useful,

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

60s seems arbitrary. A config or command line option would make the choice available to the user

format m = T.pack (printf "%.2fMB" (fromIntegral @Word64 @Double m / 1e6))
message = "Live bytes: " <> format live_bytes <> " " <>
"Heap size: " <> format heap_size
logInfo l message
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is Info the right severity? Telemetry?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I choose Info so that it would show up in any logs that users posted. I can change it to something else if you think it's appropriate (and would show up in logs somewhere under "normal" usage).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess it depends what the purpose of this logging is.

@mpickering
Copy link
Contributor Author

Do either of these values include the bytes allocated in the foreign heap?

Do you mean allocations due to mallocBytes? Or by which means exactly? Allocations due to mallocBytes just call malloc so are not tracked by the RTS.

@pepeiborra
Copy link
Collaborator

Do either of these values include the bytes allocated in the foreign heap?

Do you mean allocations due to mallocBytes? Or by which means exactly? Allocations due to mallocBytes just call malloc so are not tracked by the RTS.

What is the purpose of this logging? If it is to make bug reports then it would be better to show the full RSS or similar, the GHC heap alone is just a fraction of the total memory used by the process

@mpickering
Copy link
Contributor Author

Do you think that a significant amount of RSS for ghcide is off-heap allocations? I would expect the "heap size" number to be quite close to RSS (and this patch would allow people to check easily).

@pepeiborra
Copy link
Collaborator

Do you think that a significant amount of RSS for ghcide is off-heap allocations? I would expect the "heap size" number to be quite close to RSS (and this patch would allow people to check easily).

Around half and half.

@mpickering
Copy link
Contributor Author

Do you think that a significant amount of RSS for ghcide is off-heap allocations? I would expect the "heap size" number to be quite close to RSS (and this patch would allow people to check easily).

Around half and half.

I just tried loading ghcide into ghcide and then looked at reported VmRSS and how much was heap allocated.

Total VmRSS:   1658008 kB from /proc/pid/status
Heap Rss:         1548084 kB from /proc/pid/smaps in 42000* range

The mem_in_use figure reports "Heap size: 1620.05MB", which is quite close to the /proc/pid/status value.

@mpickering
Copy link
Contributor Author

The numbers I see for my test of loading ghcide into ghcide are:

[INFO] Live bytes: 317.73MB Heap size: 1617.95MB

Which makes sense, as there is 8 * 128mb for the nursery(!) + 317 * 2 for the live data and copying overhead ~1650mb.

If I reenable idle GC then I get probably more accurate numbers

[INFO] Live bytes: 417.13MB Heap size: 1862.27MB

= 128 * 8 + 417*2 = 1858
If I re-enable the idle GC and set -A32M then I get

[INFO] Live bytes: 417.89MB Heap size: 1059.06MB
= 32 * 8 + (4 * 417) ~= 1090

Basically, I think these numbers allow you to work out Rss accurately and the Rss makes sense relative to the live bytes.

@pepeiborra
Copy link
Collaborator

Does the space used by StringBuffers, FastStrings, ByteStrings and Linkables get included in the "Heap size" number?
Does the Heap size figure stay representative of RSS when multiple components are loaded?

Copy link
Collaborator

@pepeiborra pepeiborra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In any case, there is no reason to not merge this already and it can always be made more accurate later on. Thanks!

@mpickering
Copy link
Contributor Author

Does the space used by StringBuffers, FastStrings, ByteStrings and Linkables get included in the "Heap size" number?
Does the Heap size figure stay representative of RSS when multiple components are loaded?

At least FastString and ByteString are heap allocated (using newByteArray#/newPinnedByteArray#)

@mpickering
Copy link
Contributor Author

Does the space used by StringBuffers, FastStrings, ByteStrings and Linkables get included in the "Heap size" number?
Does the Heap size figure stay representative of RSS when multiple components are loaded?

I didn't test with multiple components but I don't see why it would report incorrect numbers.

@mpickering
Copy link
Contributor Author

Anyone want to merge this?

@wz1000

This comment has been minimized.

A thread is spawned which at a prespecified interval will report the
live bytes and heap size at the last major collection.

Live bytes corresponds to how much live data a program has and should
match closely the value reported during heap profiling.

Heap size reports the total amount of memory the RTS is using, which
corresponds more closely to OS memory usage.

```
[INFO] Live bytes: 367.45MB Heap size: 676.33MB
```

Closes haskell#1493
@mpickering

This comment has been minimized.

@jneira jneira added the merge me Label to trigger pull request merge label Mar 20, 2021
ghcide/ghcide.cabal Outdated Show resolved Hide resolved
@jneira

This comment has been minimized.

@jneira

This comment has been minimized.

@jneira jneira removed the merge me Label to trigger pull request merge label May 31, 2021
@Anton-Latukha

This comment has been minimized.

@Anton-Latukha

This comment has been minimized.

@Anton-Latukha
Copy link
Collaborator

Anton-Latukha commented Dec 20, 2021

As #1493 is still open (so still needed) & people proclaimed PR ready & awaiting merge several times, and my additions to it were simple (just a join of IO (IO ...) basically). Merging it on CI success.

@Anton-Latukha Anton-Latukha added merge me Label to trigger pull request merge and removed pr: needs rebase labels Dec 20, 2021
@mergify mergify bot merged commit e1949dd into haskell:master Dec 20, 2021
@Anton-Latukha
Copy link
Collaborator

Anton-Latukha commented Dec 20, 2021

Thanks everybody, especially @mpickering @pepeiborra (& with that sending the additional notice that this statistic is merged).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merge me Label to trigger pull request merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add memory usage logs
7 participants