Question
Diagnosing Firebird connection pool exhaustion when MON$ATTACHMENTS queries consume scarce attachments
Kavi Atlas
0 reputation · 17 Dec 2020, 04:13 UTC
79.7K views1
Loading…
0 reputation · 17 Dec 2020, 04:13 UTC
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.
35775 reputation · 17 Dec 2020, 06:57 UTC
Querying MON$ATTACHMENTS requires a new privileged attachment. When the pool is already at the server’s MaxAttachments limit (or an OS file-descriptor/process ceiling), that diagnostic query itself fails or pushes the system deeper into exhaustion.
firebirdfirebird.conf set TraceConfigFile to a configuration that logs only attachment lifecycle events:database=(CONNECTIONS=TRUE TRANSACTIONS=FALSE)
time_threshold=0
log_connections=true
log_disconnections=truefbsvcmgr so the monitoring connection comes from a dedicated machine with its own small allowance:fbsvcmgr localhost:service_mgr user sysdba password <pwd> \
action_trace_start name=diag trace_config=/etc/firebird/trace_diag.confMON$DATABASE table (e.g., SELECT MON$PAGE_BUFFERS FROM MON$DATABASE) from an existing application connection to confirm the server is responsive before committing to a full trace.MaxAttachments must exceed maxPoolSize by at least 5–10 slots to leave room for monitoring and administrative connections.ulimit -n (file descriptors) and ulimit -u (processes) for the Firebird user; both should exceed MaxAttachments + 50. On Windows use Process Explorer to view handle count.idleTimeout is shorter than DummyPacketInterval, the server-side attachment lingers after the client returns it, inflating MON$ATTACHMENTS counts.MaxAttachments = maxPoolSize + 5, restart Firebird.org.firebirdsql.jdbc.pool) checkout/checkin timestamps with trace output MON$TIMESTAMP values to spot leaks.One missing detail that changes the recommendation: Which Firebird architecture (SuperServer, SuperClassic, or Classic) are you running? Classic/SuperClassic hit per-user process limits (ulimit -u) before MaxAttachments, so the OS limit check moves higher in priority.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.