Сброс таблицы дескрипторов

← →
StanislavB (2003-07-19 08:32) [0]

Есть проблема для систем реального времени. По некоторым причинам растет таблица дескрипторов, что очевидно видно в TaskMenager. При переполнении таблицы приложения и операционная система начинают глючить. Необходимо перезагружать все. Знает ли кто нибудь из мастеров способ очистки таблицы из проги от неиспользованных, и некорректно освобожденных дескрипторов. Заранее благодарен.

← →
mzu (2003-07-19 11:27) [1]

Про какую ОС идёт разговор?

← →
Anatoly Podgoretsky © (2003-07-19 11:39) [2]

mzu (19.07.03 11:27)
ОС указана в заголовке.

← →
Nucl © (2003-07-19 12:06) [3]

Не проще ли перестартовать прогу скажем в 24.00 ?

← →
StanislavB (2003-07-19 17:00) [4]

Разговор идет не о проге. Таблица может быть заполнена многими процессами за длительное время. Но сделать "перестарт" всей системы как обязательную процедуру нельзя. Ведь речь идет о системе реального времени, например одна из систем электростанции. Нуно искать выход из положения.

← →
AlexR © (2003-07-19 22:45) [5]

Помоему, StanislavB что путает, так как W2K/XP не являются системами реальног времени в принципе!

А убрать дескрипторы (при этом не о их ненужности можно толко догадываться) можно из Process Explorer от Sysinternals. Как он это делает, пока не знаю, но можно поискать в недокументированных API и NTDDK что-то на ту тему.

← →
StanislavB (2003-07-20 08:20) [6]

AlexR. Согласен, операционные системы не совсем реального времени, но на их основе приходится делать системы реального времени. И хорошо получается. Есть проблемы, но они решаются. И обсуждаемая проблема одна из них. Например одна прога на олном узле пытается, с помощью сокета, законектиться с прогой на другом узле. А он выключен. Все, дискриптор в таблице остался. Это один из реальных примеров. Я думаю, что все таки эту проблему можно, хотя бы частично решить без перезапуска ОС, или хотя бы продлить жизнь сессии.

← →
ValeraVV © (2003-07-21 07:40) [7]

На этой "системе реального времени" обычно крутится постоянно одна прога - скорее всего написанная StanislavB, так нельзя ли проверить как эта прога освобождает дескрипторы

← →
mzu (2003-07-21 09:56) [8]

Можеть быть вопрос в стиле программирования: типа жизнь всех дескрипторов должна быть однозначно привязана к жизни объектов. Или к количеству instances этого объекта (Не знаю как по-русски сказать, извините).

А если не переписывать программу заново, то в MS Windows Resource Kit есть замечательная программулинка (oh.exe) которая
позволяет видеть список открытых дескрипторов любого процесса с указанием на что они ссылаются. Может это поможет найти место, где дескриптор создаётся и не удаляется.

← →
mzu (2003-07-21 09:57) [9]

Кстати, для уточнения. Под дескрипторами уважаемый StanislavB имеет в виду handles?

← →
StanislavB (2003-07-25 09:16) [10]

Для уточнения. На "системе реального времени" крутится не одна прога, а система прог, вызываемых в решение автоматически, обменивающихся информацией между собой через зашаренную память.
Действительно, под дескрипторами имеею в виду handles.

← →
Polevi © (2003-07-25 09:51) [11]

если не было вызова CloseHandle кто знает что дескриптор "неиспользуется" ??? на основании чего какаято ф-ия или утилита может сделать такой вывод ?

← →
StanislavB (2003-07-26 20:12) [12]

Спасибо, коллеги. Очевидно проблема не рразрешимая. Я очень внимательно слежу за освобождением памяти и дескрипторов. Но бывают ситуации, когда CloseHandle не приводит к желаемому результату, и дескриптор не освобождается. Это особенно характерно для сетевых интерфейсов. Еще раз спасибо, буду дальше искать выход, возможно не стандартный.

← →
panov © (2003-07-27 15:21) [13]

>StanislavB (26.07.03 20:12)

Увеличение количества дескрипторов - однозначно в ошибке в программе.
Недавно боролся с такой же проблемой при программировании сокетов в Socket API.

Дай более подробную информацию о коде...

← →
Morfein © (2003-07-27 18:50) [14]

>> Но бывают ситуации, когда CloseHandle не приводит к желаемому результату, и дескриптор не освобождается. Это особенно характерно для сетевых интерфейсов.
Это бывает только в том случае, если ему передают кривой дескриптор. А для сетевых интерфейсов существуют хорошие функции shutdown() и CloseSocket()

← →
StanislavB (2003-07-28 08:39) [15]

Я не понял, что такое кривой дескриптор. Я их не создаю. Например. Поставил компонент ClientSocket и делаю коннект по необходимому порту и хосту. Все в порядке. идет обмен информацией. Нет проблем. Таблица дескрипторов не растет. Но в конце рабочего дня. Клиент, который находится в другом конце города, выключил компьютер. Сокет периодически пытается наладить коннект и генерит сообщение об ошибке коннекта. Когда утром включается удаленный узел, сокет радостно сообщает об этом факте и передает этому узлу информацию. А за это время таблица дескрипторов увеличилась на несколько сотен или тысяч. Это один из примеров. Сейчас я делаю систему на основе WebAplication. Там начинаю сталкиваться с похожей проблемой. Системы должны работать круглосуточно и без перезагрузок многие месяцы, пока не получается.

← →
Polevi © (2003-07-28 11:58) [16]

неправильно обрабатываешь disconnect, там нужно освобождать handle

← →
StanislavB (2003-07-28 22:11) [17]

Для Polevi. Освобождать handle какого объекта? Я не встречал в литературе ни намека на необходимость этого действия, считая, что компонент сам делает все необходимое. Мною делались подобные попытки, но они ни к чему не приводили.

← →
Morfein © (2003-07-28 22:29) [18]

Ну так а что же ты тогда на "кривую систему" валишь, рассказываешь нам про какие-то переполненные таблицы дескрипторов, если ты на элементарном уровне не можешь отследить отсутствие клиента и освободить ресурсы?

Под кривым дескриптром я понимаю дескриптор, который никаким образом не связан с реальными ресурсами.

← →
StanislavB (2003-07-29 08:41) [19]

В том то и дело, что я "на элементарном уровне" отслеживаю отсутствие "сервера", а не "клиента", мне в этом помогает компонент ClientSocket, но делать Disconnect не имеет смысла, так как Connecta то и не было. И освобождать ресурсы то же нечего. Открытого сокета не было. Очевидно, TCP/IP пытается найти серверный сокет и где то бродит, занимая дескриптор для не открытого сокета. Возможно так. Очевидно как то можно остановить этот процесс и осводить дескриптор. Тайм аут не помогает. Или я действительно ничего не понимаю. Завал.

2StanislavB (29.07.03 08:41)
ты исходный код TClientSocket смотрел ?
ты делаешь Socket.Close в обработчике OnError ?

← →
StanislavB (2003-07-29 22:03) [21]

Нет.

продолжай в том же духе, пусть плодятся и множаться дескприпторы !

← →
mzu (2003-07-30 11:43) [23]

проверь при помощи oh.exe - какие дескрипторы не закрыты. В соответствии с этим и действовать

← →
StanislavB (2003-07-30 22:39) [24]

"ты делаешь Socket.Close в обработчике OnError ?"
Кажется делал. Точно не помню, но кажется нарывался на исключение. Попробую еще, имеет смысл. Сейчас не могу, надо ехать на объект в командировку. Если это то, что нужно, то я должник.
oh.exe не могу найти. Это интересно и для других целей. Например закрывать не нужные процессы.

StanislavB

> oh.exe не могу найти.

%Delphi%\Bin\OH.EXE

← →
StanislavB (2003-07-31 23:14) [26]

Спасибо, нашел. Только что это за проекты ".ohp"?

Сброс таблицы дескрипторов Найти похожие ветки