[GHC] #13288: Resident set size exceeds +RTS -M limit with large nurseries

#13288: Resident set size exceeds +RTS -M limit with large nurseries -------------------------------------+------------------------------------- Reporter: j6carey | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.2 System | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We observed high resident set size well in excess of the `+RTS -M` limit in a long-running, high data-volume Haskell application that Awake Networks is deploying on a network appliance. We think that the current `GC.c` code has two bugs that, at least in combination with each other, become significant when high `+RTS -N` and very high `+RTS -A` values are used. 1. As we approach the `-M` limit, the computation of the new size for generation 1 appears to be based on an incorrect figure for the total size of the nursery. The `-A` value is used instead of the product of that value with `-N`. This problem could lead to the total heap size exceeding the `-M` limit. 2. Memory allocated from the operating system is freed only if the RTS thinks that it would not be reallocated soon. The estimate for what will be needed soon is based on fewer inputs than the actual resizing logic, and in particular it is not affected by `-M`. Thus it might keep free mblocks in excess of the `-M` limit, based on an expected heap growth that would be forbidden by `-M`. We are preparing a patch to address these issues; it will point out the particular lines of code. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13288 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13288: Resident set size exceeds +RTS -M limit with large nurseries -------------------------------------+------------------------------------- Reporter: j6carey | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by j6carey: Old description:
We observed high resident set size well in excess of the `+RTS -M` limit in a long-running, high data-volume Haskell application that Awake Networks is deploying on a network appliance.
We think that the current `GC.c` code has two bugs that, at least in combination with each other, become significant when high `+RTS -N` and very high `+RTS -A` values are used.
1. As we approach the `-M` limit, the computation of the new size for generation 1 appears to be based on an incorrect figure for the total size of the nursery. The `-A` value is used instead of the product of that value with `-N`. This problem could lead to the total heap size exceeding the `-M` limit.
2. Memory allocated from the operating system is freed only if the RTS thinks that it would not be reallocated soon. The estimate for what will be needed soon is based on fewer inputs than the actual resizing logic, and in particular it is not affected by `-M`. Thus it might keep free mblocks in excess of the `-M` limit, based on an expected heap growth that would be forbidden by `-M`.
We are preparing a patch to address these issues; it will point out the particular lines of code.
New description: We observed high resident set size well in excess of the `+RTS -M` limit in a long-running, high data-volume Haskell application that Awake Networks is deploying on a network appliance. We think that the current `GC.c` code has two bugs that, at least in combination with each other, become significant when high `+RTS -N` and very high `+RTS -A` values are used. 1. As we approach the `-M` limit, the computation of the new size for generation 1 appears to be based on an incorrect figure for the total size of the nursery. The `-A` value is used instead of the product of that value with `-N`. This problem could lead to the total heap size exceeding the `-M` limit. 2. Memory allocated from the operating system is freed only if the RTS thinks that it would not be reallocated soon. The estimate for what will be needed soon is based on fewer inputs than the actual resizing logic, and in particular it is not affected by `-M`. Thus it might keep free mblocks in excess of the `-M` limit, based on an expected heap growth that would be forbidden by `-M`. We prepared to address these issues; it points out the particular lines of code: https://phabricator.haskell.org/D3143 -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13288#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13288: Resident set size exceeds +RTS -M limit with large nurseries -------------------------------------+------------------------------------- Reporter: j6carey | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by j6carey: Old description:
We observed high resident set size well in excess of the `+RTS -M` limit in a long-running, high data-volume Haskell application that Awake Networks is deploying on a network appliance.
We think that the current `GC.c` code has two bugs that, at least in combination with each other, become significant when high `+RTS -N` and very high `+RTS -A` values are used.
1. As we approach the `-M` limit, the computation of the new size for generation 1 appears to be based on an incorrect figure for the total size of the nursery. The `-A` value is used instead of the product of that value with `-N`. This problem could lead to the total heap size exceeding the `-M` limit.
2. Memory allocated from the operating system is freed only if the RTS thinks that it would not be reallocated soon. The estimate for what will be needed soon is based on fewer inputs than the actual resizing logic, and in particular it is not affected by `-M`. Thus it might keep free mblocks in excess of the `-M` limit, based on an expected heap growth that would be forbidden by `-M`.
We prepared to address these issues; it points out the particular lines of code: https://phabricator.haskell.org/D3143
New description: We observed high resident set size well in excess of the `+RTS -M` limit in a long-running, high data-volume Haskell application that Awake Networks is deploying on a network appliance. We think that the current `GC.c` code has two bugs that, at least in combination with each other, become significant when high `+RTS -N` and very high `+RTS -A` values are used. 1. As we approach the `-M` limit, the computation of the new size for generation 1 appears to be based on an incorrect figure for the total size of the nursery. The `-A` value is used instead of the product of that value with `-N`. This problem could lead to the total heap size exceeding the `-M` limit. 2. Memory allocated from the operating system is freed only if the RTS thinks that it would not be reallocated soon. The estimate for what will be needed soon is based on fewer inputs than the actual resizing logic, and in particular it is not affected by `-M`. Thus it might keep free mblocks in excess of the `-M` limit, based on an expected heap growth that would be forbidden by `-M`. We prepared a fix to address these issues; it points out the particular lines of code: https://phabricator.haskell.org/D3143 -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13288#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13288: Resident set size exceeds +RTS -M limit with large nurseries -------------------------------------+------------------------------------- Reporter: j6carey | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3143 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3143 * milestone: => 8.2.1 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13288#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13288: Resident set size exceeds +RTS -M limit with large nurseries
-------------------------------------+-------------------------------------
Reporter: j6carey | Owner: (none)
Type: bug | Status: patch
Priority: normal | Milestone: 8.2.1
Component: Runtime System | Version: 8.0.2
Resolution: | Keywords:
Operating System: Linux | Architecture: x86_64
Type of failure: Runtime | (amd64)
performance bug | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s): Phab:D3143
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by Ben Gamari

#13288: Resident set size exceeds +RTS -M limit with large nurseries -------------------------------------+------------------------------------- Reporter: j6carey | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3143 Wiki Page: | -------------------------------------+------------------------------------- Comment (by j6carey): Thank you for committing this fix. We still see RSS growth beyond the -M limit, but that is due to having a large number of partially-used megablocks involved in the free block group list. They cannot be returned to the operating system because they are still partly in use, and yet their free space is not counted as heap size, and therefore is not limited by -M. We have not yet figured out why there is such high fragmentation in our application. But clearly that is a distinct issue. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13288#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13288: Resident set size exceeds +RTS -M limit with large nurseries -------------------------------------+------------------------------------- Reporter: j6carey | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3143 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Alright, I will close this in that case. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13288#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC