docs(onprem): document the web-request statement_timeout settings

docs/content/get_started/pro/onprem/hardware_sizing.md

@@ -102,6 +102,18 @@ These four decide how many database connections the application holds open, so t
 
 Change either one with `dojo-compose-cli environment add` and restart, as above. A harakiri restart frees the process but does not remove the cause. If one shows up in the log, send the stack traces that come with it to support, since they show where the process was stuck.
 
+**Slow database statements.** A harakiri restart stops the web process, but not the database query it was running: PostgreSQL keeps working on that query until it finishes. From 3.5.0, PostgreSQL itself stops any single statement of a web request that runs past 30 seconds under that service's harakiri (870 seconds on `dojo`, 1740 seconds on `dojo-import-scan`), and the request answers with a 503 that says it took too long. Where harakiri is unset or `0`, the limit is 1740 seconds. Imports and exports may get a higher limit than other requests, but never more than 30 seconds under their own service's harakiri, because harakiri ends the request at that point anyway: with the defaults they get the same limit as everything else on that service. Background tasks, migrations and management commands are never limited.
+
+The limit is sent to PostgreSQL as a connection startup option. If DefectDojo reaches PostgreSQL through PgBouncer or another connection pooler, the pooler may refuse those connections or drop the option; set the limits below to `0` there.
+
+| Setting | Service | Default | Notes |
+| --- | --- | --- | --- |
+| `DD_DATABASE_WEB_STATEMENT_TIMEOUT` | `dojo` (web) | 30 seconds under `DD_UWSGI_HARAKIRI`, or 1740 when that is unset or `0` | Seconds; `0` turns the limit off. |
+| `DD_DATABASE_IMPORT_STATEMENT_TIMEOUT` | `dojo-import-scan` (imports) | 30 seconds under `DD_UWSGI_IMPORT_HARAKIRI`, or 1740 when that is unset or `0` | Docker Compose only. Seconds; `0` turns the limit off. |
+| `DD_DATABASE_WEB_LONG_STATEMENT_TIMEOUT` | `dojo` (web) | 30 seconds under the service's harakiri, or 1740 when that is unset or `0` | The limit for imports and exports. A value above the default is capped at it; `0` means the default. |
+
+On Kubernetes, the limit follows each uWSGI pool's harakiri from the chart values: 870 seconds on the web pool and 1740 seconds on the import pool, or 1740 seconds on the web pool when `django.uwsgiImport.enabled` is `false`. To change it, set `DD_DATABASE_WEB_STATEMENT_TIMEOUT` in `config.extra` or `django.extraEnv`. The chart has no separate setting for the import pool, so a value set there applies to the web and import pools alike. If a request answers with this 503, the log names the request: send it to support, since a statement that runs this long is a performance problem to fix.
+
 **Import memory and shutdown.** uWSGI also replaces a process whose memory grows too large. `DD_UWSGI_RELOAD_ON_RSS` (MB) replaces it after a request leaves it above the limit: it stops taking requests, and the ones still running on its other threads get `DD_UWSGI_WORKER_RELOAD_MERCY` seconds before uWSGI kills it, failing them with a 502 (the log says `NO MERCY`). `DD_UWSGI_EVIL_RELOAD_ON_RSS` (MB) is a safety limit: a process that passes it is killed within about a second, and every request it is serving fails with a 502. The log says `EVIL RELOAD`, and Docker shows no restart. Imports need far more memory than pages, so from 3.4.300 the import service can be set on its own:
 
 | Setting | Service | Default | Notes |