SYSDBA в 16:18, 11 января 2012

2012-01-11T16:18:55Z

SYSDBA в 17:32, 27 ноября 2007

2007-11-27T17:32:52Z

SYSDBA в 17:31, 27 ноября 2007

2007-11-27T17:31:27Z

Новая страница

При использовании сервера Firebird классической архитектуры может возникнуть такая проблема: клиент обновил записи, но не закрыл транзакцию, после чего завершился аварийно (выключилось питание, сняли задачу, пропало сетевое соединение и т.п.). Обновленные записи будут заблокированы для изменений другими клиентами, пока не завершится обслуживающий мертвое соединение процесс. Firebird использует функции операционной системы для определения жив еще конект или нет. По умолчанию, Windows начинает проверку через 2 часа после того, как от клиента был принят последний пакет. Параметры ОС можно изменить. Для этого следует зайти в редактор реестра, в раздел:

\HKEY_LOCAL_MACHINE
\System
\CurrentControlSet
\Services
\TCPIP
\Parameters

Создаем (если его еще нет, конечно) следующий параметр:

'''KeepAliveTime''', тип DWORD, значение 300000 -- т.е. проверка будет выполняться через 5 минут с того момента, как клиент послал нам последний запрос.

Остальные параметры, регулирующие определение мертвого конекта, можно не трогать. Их значения по-умолчанию нас устраивают. На всякий случай приведем их наименования и значения по-умолчанию:

'''KeepAliveInterval''', DWORD, 1000 -- интервал между проверочными пакетами. Пакеты начнут посылаться через KeepAliveTime с момента приема последнего пакета от этого клиента. Максимальное количество проверочных пакетов задается параметром TcpMaxDataRetransmissions. Если ни на один из проверочных пакетов не пришло ответа -- соединение считается потерянным.

'''TcpMaxDataRetransmissions''', DWORD, 5 -- максимальное количество проверочных пакетов.

Таким образом, если прописать KeepAliveTime=300000 и перезагрузить систему, то в случае зависания клиента, максимум через 5 минут и 5 секунд, соединение закроется и блокировка с записей снимется.

Останется проинструктировать пользователей сколько времени стоит ждать прежде чем поднимать тревогу.

PS: конечно нагрузка на сеть увеличится. Если зарегистрировано 50 подключений, и все операторы ушли на обед, то за час обеда будет
разослано туда: 50 * 12 = 600 и принято 600 пакетов. Всего 1200. Пропускная способность 100 Мб сети -- порядка 1250 восьмикилобайтных
пакетов в секунду. Т.е. такая рассылка заберет одну секунду из часа или 1/3600 от общей максимальной пропускной способности сети.

Читать по теме:

[http://support.microsoft.com/kb/120642/EN-US/ TCP/IP and NetBT configuration parameters for Windows]
[http://support.microsoft.com/default.aspx?kbid=140325 How to Determine Loss of Client/Server Connection]

@@ Строка 28: / Строка 28: @@
 Читать по теме:
-[http://support.microsoft.com/kb/120642/EN-US/ TCP/IP and NetBT configuration parameters for Windows]
+* [http://support.microsoft.com/kb/120642/EN-US/ TCP/IP and NetBT configuration parameters for Windows]
-[http://support.microsoft.com/default.aspx?kbid=140325 How to Determine Loss of Client/Server Connection]
+[[Category:Школа системного администратора]]

← Предыдущая		Версия 17:32, 27 ноября 2007
Строка 29:		Строка 29:

	[http://support.microsoft.com/kb/120642/EN-US/ TCP/IP and NetBT configuration parameters for Windows]		[http://support.microsoft.com/kb/120642/EN-US/ TCP/IP and NetBT configuration parameters for Windows]
		+
	[http://support.microsoft.com/default.aspx?kbid=140325 How to Determine Loss of Client/Server Connection]		[http://support.microsoft.com/default.aspx?kbid=140325 How to Determine Loss of Client/Server Connection]

Определение мертвых конектов в классике - История изменений

SYSDBA в 16:18, 11 января 2012

SYSDBA в 17:32, 27 ноября 2007

SYSDBA в 17:31, 27 ноября 2007