Unexpected Compute Usage
Hi Team,
I'm currently on the free plan as we work through a PoC, and expect to upgrade in the future. I've just received a notification: "You've used 95% of your compute allowance this month." I find this odd, as we have not been active in using Neon over the holiday period. I'm not (necessarily) saying you're wrong but I'm trying to better understand how I'm logging compute hours. When I look Monitoring->System Operations, I see a steady stream of Start Compute/Suspend Compute, every couple of seconds. It's never idle for more than 3 seconds! I do have an integration with Ingest? Could this be the cause, perhaps?
Thanks for your assistance,
Simon
8 Replies
deep-jade•8mo ago
Hi Simon, can you say more about the integration with Inngest? Are you using the Inngest database events system?
xenial-blackOP•8mo ago
Hi @bryan, I thought I was but then remembered it doesn't work for local dev, so I'm using http requests, so I suspect that is not the cause?
deep-jade•8mo ago
If there's an LR connection to a Postgres on Neon it won't go to sleep despite being idle as it would drop the LR connection. That can often burn through your compute unexpectedly.
xenial-blackOP•8mo ago
Ah, I think you may be right, if LR = Logical Replication? I'm guessing when I first connected inngest it turned on LR. How do I go about turning LR off?
deep-jade•8mo ago
Yes, sorry Logical Replication. You'll need to drop the connections
SELECT * FROM pg_replication_slots;
To terminate PostgreSQL logical replication connections, you need to manage replication slots and subscriptions appropriately. Here's how you can proceed:
Identify Active Replication Slots: First, list all replication slots to determine which ones are active:
SELECT * FROM pg_replication_slots;
This query will display details of all replication slots, including their names and activity status.
Terminate Active Replication Connections: If a replication slot is active, you must terminate the associated replication connection before dropping the slot. To do this, identify the process ID (PID) of the active replication connection:
SELECT pid FROM pg_stat_activity WHERE backend_type = 'walsender' AND application_name = '<slot_name>';
Replace <slot_name> with the name of your replication slot. Once you have the PID, terminate the connection:
SELECT pg_terminate_backend(<pid>);
Replace <pid> with the process ID obtained from the previous query.
Drop the Replication Slot: After terminating the replication connection, you can safely drop the replication slot:
SELECT pg_drop_replication_slot('<slot_name>');
Replace <slot_name> with the name of the replication slot you wish to drop. Ensure that the slot is no longer active before attempting to drop it.
Remove Subscriptions: If you're managing logical replication subscriptions, you might need to drop them as well:
DROP SUBSCRIPTION <subscription_name>;
Replace <subscription_name> with the name of the subscription you want to remove. Note that dropping a subscription may also attempt to drop the associated replication slot on the publisher.xenial-blackOP•8mo ago
Hi @bryan, thanks so much for detailed response. I have two replication slots, "inngest_cdc" this is not active, and "wal_proposer_slot" which is active. This slot type is "physical". before I proceed I want to make sure that the steps you've given are intended for this slot? Thanks again for your time/assistance.
deep-jade•8mo ago
I don't believe you're allowed to remove the physical slot, that's Neon consuming the WAL from your system. You can remove the inngest_cdc one.
xenial-blackOP•8mo ago
Thanks, I'll do that and see if it makes any difference to the compute usage.