For forums, blogs and more please visit our
Developer Tools Community.
By: Quinn Wildman
Abstract: afd.sys, which is part of the TCP/IP stack in Microsoft Windows, contains a memory leak in many versions of the driver.
InterBase uses the SO_KEEPALIVE option when it opens a socket. This instructs the host TCP/IP stack to check the state of the connection at fixed intervals. These fixed intervals are governed by kernel configuration settings for Linux/Unix and Registry settings for Windows.
Traditionally, these intervals have defaulted to 1 or 2 hours on their respective operating systems. The settings can be modified by users but the new setting would affect sockets used by all applications not just InterBase. The process of making the session change isn't trivial and what would be desirable for InterBase might not be optimal for other applications.
This motivated the introduction of the DUMMY_PACKET_INTERVAL config parameter. This parameter is symmetric in nature - the client checks the server's viability by sending a dummy packet to the server while awaiting a result set and the server checks the client by sending a dummy packet to an idle client.
Since an open transaction can cause the disablement of garbage collection on a database or cause other client transactions to wait indefinitely on updates, the 1 or 2 hour wait for the SO_KEEPALIVE socket option was considered excessive. Customers with high transaction databases who set the DUMMY_PACKET_INTERVAL too high will risk the same performance degradation due to inhibiting garbage collection and have to weigh that risk against the probability of non-paged pool consumption on the client.
We have a couple of probable reasons why this might be caused.
InterBase has a notion of DUMMY_PACKET_INTERVAL (ibconfig parameter). This parameter value is set at the client side and is 60 seconds by default. The parameter informs the InterBase server, for a TCP/IP socket connection, to send dummy packets (small dummy opcode) to the client if the socket connection is idle for the specified duration.
Now consider this...
In this situation, (many) client programs may be having idle connections. All of the dummy packets sent by the server to each client application may not be read immediately. According to Microsoft's KB article, the bug in afd.sys copies the socket data to non-paged pool (which is limited to physical memory). This non-paged pool is released only when the database connection is closed (via the socket), and the system can release all the non-paged pool for that socket. Even though, MS claims this is fixed as of SP3, our testing shows otherwise. We have a Win2K SP3 system, and are able to reproduce this problem in afd.sys.
UPDATE TMP$ATTACHMENTS SET TMP$STATE = 'KEEPALIVE' [WHERE ...]
will cause dummy packets to be sent to all remote TCP/IP database connections that meet the optional WHERE clause. This allows a user to clear a dead connection immediately whenever there is a strong suspicion that a dead connection is lingering somewhere in the world.
Could not retrieve comments. Please try again later.
Free Developer Edition!
Click here to download a free non-expiring Developer Edition or 30-day trial >
More InterBase Info
InterBase XE7 Product Info
Free Developer Edition download
InterBase on Google+
Follow @InterBase on Twitter
Server Response from: ETNASC04