mirror of
https://github.com/hasura/graphql-engine.git
synced 2024-12-14 08:02:15 +03:00
4d86cd3a62
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 |
||
---|---|---|
.. | ||
config.query.yaml | ||
dump.sql.gz | ||
README.md | ||
replace_metadata.json | ||
SKIP_CI | ||
SKIP_PR_REPORT |
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.