teads-lionel-ngo opened a new issue, #1133: URL: https://github.com/apache/pekko-http/issues/1133
Hello there, I am considering switching the gc used in production to zgc for my app but it constantly crashed with a OOM error. I have been actively chasing the root cause of the OOM and I believe there may be some issues when using pekko http with some garbage collectors. To make it short, ZGC doesn't reclaim off-heap memory because my app has a fairly large heap with very moderate pressure. My app uses `decodeRequest` & `encodeResponse`. For example, `decodeRequest` uses a [GZipCompressor](https://github.com/apache/pekko-http/blob/fad7678899cf1ed36cc4921ecf0d421a69f980ae/http/src/main/scala/org/apache/pekko/http/scaladsl/coding/GzipCompressor.scala#L71) and from my understanding for every incoming request, it creates a new [Inflater](https://github.com/apache/pekko-http/blob/fad7678899cf1ed36cc4921ecf0d421a69f980ae/http/src/main/scala/org/apache/pekko/http/scaladsl/coding/GzipCompressor.scala#L74). The issue for my use case is that there is no explicit call `.end()` to properly release the resource leaving it to the garbage collector to reclaim it. Same goes for `encoreResponse`. One workaround I found is using the flag `ZCollectionInterval` to force the gc to release off-heap memory but at the expense of CPU. I also tried to do a custom hacky `decoderRequest` and it also worked. So here's my question: is it an intended behaviour in pekko http to let the gc handle this? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
