Check memory and parallelism settings against the machine.
promptread-only tools
capacity-check([connection])The text below is exactly what prompts/get returns for the example arguments. A client inserts it as the opening message of a conversation, and the model then calls the tools it names.
Check server capacity settings for connection shop_prod. 1. Call hostCapacity. If it reports that host RAM and vCPU count are unknown, say so and stop with a partial answer: PostgreSQL cannot see the machine it runs on, and those values have to be declared per connection in the config file. Do not guess them. 2. Read derived.committed_worst_case_percent_of_ram. This is work_mem times max_connections plus maintenance_work_mem times autovacuum_max_workers, and it is the number that decides whether the OOM killer is a risk. Read overrides beside it before believing any memory figure. settings is what pg_settings reports for THIS session, so an ALTER ROLE ... SET work_mem made for the application role is not in it -- and that is the role with the connections. The worst case already uses the largest work_mem any role carries, and work_mem_is_overridden says whether that differs from the session value you can see. An override here also explains a statement that is slow only from the application, and a statement_timeout or search_path set per role explains a good deal more, so read the whole list rather than only the memory entries. 3. Compare shared_buffers and effective_cache_size against RAM. 4. Check parallelism: max_parallel_workers_per_vcpu above 1 means a single query can oversubscribe the machine. That is the setting; triage-active-sessions is where the consequence is observed, and it collapses parallel workers into their leaders so the concurrency is counted in queries rather than in backends. 5. Call databaseStats and read numbackends against max_connections to see how much of the worst case is actually reached. Read temp_files and temp_bytes on the same call: everything above is the worst case arithmetic, and these two are the only evidence of what actually happened. Temporary files are sorts and hashes that did not fit in work_mem and went to disk, so a large temp_bytes is work_mem being too small in practice however comfortable step 2 looked -- and a temp_bytes of zero is the argument against raising it. The two readings pull in opposite directions and the answer needs both. sessions_abandoned, sessions_fatal and sessions_killed say whether connections are churning. Sizing max_connections against a count that is high because sessions keep dying is sizing for the symptom. 6. Report each finding with the reading behind it, and name the setting to change.
{
"jsonrpc": "2.0",
"id": 1,
"method": "prompts/get",
"params": {
"name": "capacity-check",
"arguments": {
"connection": "shop_prod"
}
}
}