Diagnosing Firebird connection pool exhaustion when MON$ATTACHMENTS queries consume scarce attachments

Diagnostic paradox during pool exhaustion

Firebird's MON$ATTACHMENTS table exposes live server attachments with columns such as MON$ATTACHMENT_ID, MON$STATE, MON$REMOTE_ADDRESS, and MON$TIMESTAMP, making it the primary tool for identifying leaked or long-held connections. However, querying this monitoring table requires a separate privileged attachment, which itself counts against the server's MaxAttachments limit and any OS file-descriptor or process ceiling that applies to the chosen architecture (SuperServer, SuperClassic, or Classic). When the connection pool is genuinely exhausted, the diagnostic query can fail or worsen the contention it attempts to measure.

Client-side pools such as Jaybird enforce their own max-connection, idle-timeout, and validation settings independently of firebird.conf, so the attachment count visible in MON$ATTACHMENTS may not map directly to the pool configuration. Correlating MON$TIMESTAMP values with application logs helps determine whether attachments are created faster than they are returned, but this correlation requires the monitoring query to succeed during the exhaustion window.

Open questions

• What lightweight alternative or sampling strategy can reveal attachment-state distribution without consuming an additional attachment when the pool is at its limit?
• Which combination of firebird.conf MaxAttachments, OS limits, and client-pool settings should be compared first to isolate whether exhaustion originates on the server or the client side?