Форум: "Система";
Текущий архив: 2003.10.13;
Скачать: [xml.tar.bz2];
ВнизСброс таблицы дескрипторов Найти похожие ветки
← →
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 пытается найти серверный сокет и где то бродит, занимая дескриптор для не открытого сокета. Возможно так. Очевидно как то можно остановить этот процесс и осводить дескриптор. Тайм аут не помогает. Или я действительно ничего не понимаю. Завал.
← →
Polevi (2003-07-29 10:12) [20]2StanislavB (29.07.03 08:41)
ты исходный код TClientSocket смотрел ?
ты делаешь Socket.Close в обработчике OnError ?
← →
StanislavB (2003-07-29 22:03) [21]Нет.
← →
Polevi (2003-07-30 09:36) [22]продолжай в том же духе, пусть плодятся и множаться дескприпторы !
← →
mzu (2003-07-30 11:43) [23]проверь при помощи oh.exe - какие дескрипторы не закрыты. В соответствии с этим и действовать
← →
StanislavB (2003-07-30 22:39) [24]"ты делаешь Socket.Close в обработчике OnError ?"
Кажется делал. Точно не помню, но кажется нарывался на исключение. Попробую еще, имеет смысл. Сейчас не могу, надо ехать на объект в командировку. Если это то, что нужно, то я должник.
oh.exe не могу найти. Это интересно и для других целей. Например закрывать не нужные процессы.
← →
AlexKniga (2003-07-31 13:42) [25]StanislavB
> oh.exe не могу найти.
%Delphi%\Bin\OH.EXE
← →
StanislavB (2003-07-31 23:14) [26]Спасибо, нашел. Только что это за проекты ".ohp"?
Страницы: 1 вся ветка
Форум: "Система";
Текущий архив: 2003.10.13;
Скачать: [xml.tar.bz2];
Память: 0.5 MB
Время: 0.011 c