graphql-engine/server/benchmarks/benchmark_sets/9447_repro
kodiakhq[bot] 4d86cd3a62 Fix #9447 bad memory usage
A fix for #9447

Before this change, for the workload in the ticket, we saw a memory stay at around 4 GB an hour after the workload ended.  after this change we see both a lower memory high watermark, and also see memory come back to baseline at the end as we expect (after the `HASURA_GRAPHQL_PG_CONN_LIFETIME` and a subsequent `_idleStaleReaperThread` interval elapses).  But note the numbers given on any given machine may be slightly different, since the behavior depends on the version of glibc and processor speed (Since the test case depends on the server being overloaded).

This might also help some users commenting in https://github.com/hasura/graphql-engine/issues/9592

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/9823
GitOrigin-RevId: 5650aa42d10d46c418c21686983a982d69011884
2023-07-25 11:24:57 +00:00
..
config.query.yaml Fix #9447 bad memory usage 2023-07-25 11:24:57 +00:00
dump.sql.gz Fix #9447 bad memory usage 2023-07-25 11:24:57 +00:00
README.md Fix #9447 bad memory usage 2023-07-25 11:24:57 +00:00
replace_metadata.json Fix #9447 bad memory usage 2023-07-25 11:24:57 +00:00
SKIP_CI Fix #9447 bad memory usage 2023-07-25 11:24:57 +00:00
SKIP_PR_REPORT Fix #9447 bad memory usage 2023-07-25 11:24:57 +00:00

This is a repro case for the bad memory usage behavior scenario described in https://github.com/hasura/graphql-engine-mono/pull/9447 . see that thread for details.

This is just here as a runnable example of the workload; the numbers we get back from the benchmark are not really useful, since e.g. many of the queries actually timeout.

One thing that wasn't fixed in #9823, and for which this is a good repro case: The server has no ability to detect when a client has disconnected in the middle of an ongoing query, for example because the client library timed out, and likewise does not cancel the corresponding long-running database query.