Удалось отыскать ссылку на статью, которая на мой взгляд раскрывает тему с per-process и per-station ограничениями по объектам в windows

http://www.sybase.com/detail?id=1019174

Вот с такими кучами

SharedSection=2048,24576,2048


ограничение win2k3 svr на общее число USER объектов около 30K.

мне хватает

---

добавка от fez:
Данная тема возникла в том числе и потому что в плагине vis1cpp существует утечка объектов GDI и USER.

trdm писал(а) 16. Мая 2007 :: 12:55:

В смысле? Надо подробнее?

В этой статье описаны ограничения на процесс, и где они устанавливаются.
Секция Desktop Heap отвечает за ограничения в общем на станцию.

Вообще, вся статья полезная и подтверждается результатами тестов.

Я в свое время развернуто ее комментировал на тех форуме, но интереса не это вызвало.

trdm писал(а) 16. Мая 2007 :: 13:11:

Будем говорить прямо: я тоже уверен, что утонет Да и х. с ней

А по объектам:
В свое время, кажется, я менял значения

HKLM/Software/Microsoft/Windows NT/CurrentVersion/Windows/USERProcessHandleQuota


А сегодня выставил значение в ветке

HKLM/SYSTEM/CurrentControlSet/Control/Session Manager/SubSystems/Windows


в части SharedSection в


SharedSection=2048,24576,2048


Это увеличило лимит объектов в общем на станцию.
Если, конечно, у меня не стало двоиться в глазах с чего-нибудь такого того чего-нибудь

ИМХО, для обхода этих ограничений можно терминал-сервер использовать. Серверная компонента может запускать одинэсы кучками. Каждую кучку в отдельной терминальной сессии примерно таким образом:
1) Создать терминальную сессию и запустить в ней некий специальный процесс.
2) Специальный процесс запускает по OLE сколько надо одинэсов в кучке.
3) Взаимодействие с главным сервисом происходит либо через TCP/IP, либо через пайпы, либо общую память и т.д.
4) Удаленные машины взаимодействуют с сервисом, который взаимодействует с "сервисом кучки", который уже передает запрос свободному одинэсу из кучки

Миш, я помню в свое время тема GDI обсуждалась на форуме...
Но я не могу понять откуда ноги растут у моей проблемы: под конец дня кол-во GDI объектов для моей сессии приближается к трем тысячам.
Захожу в журнал документов - увеличивается, выхожу - уменьшается, НО на показатель на 1 больше чем перед заходом.

У меня Win2003 TS, несколько сессий пользуют 1С очень активно, к концу дня иногда винды встают колом. Сперва перестает работать отображение тулбаров в любых приложениях, потом винды окончательно нагибаются и вылазит окошко в стиле Win 3.11 с надписью "Requested resource not awailible" и пипец.
Закрываю все приложения жрущие GDI, и все встает на свои места. В основном это Miranda и 1C.

Кто что посоветует?

Может у меня утечка где идет. Где копать?

У меня активно используются активиксы. Предполагаю что в них.
Но в журнале их нет!

А утечки при использовании классов могут влиять на использование GDI?

Степ, ну не до 3000 объектов же
Я просто пытаюсь найти откуда все это ползет у меня. При старте у меня те же 200-300.

Вообще терять объекты можно в разных местах и это очень очень просто
Даже в svcsvc в свое время была утечка в FilterValue...

Я вроде прямых утечек в самом 1С не нашел, хотя говорят, что они есть.
Мне казалось, что это не утечки, а некий механизм повторного использования хендлов.
Но здесь, конечно, могу запросто ошибаться.

А уж в АктивИксах так и вообще поймать такую штуку проще простого.

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

Если именно перманентно растет, надо, видимо, убирать последовательно компоненты и смотреть, что будет.
Поддержу Диму со Степаном, путь это ни разу не легкий

А вообще как же так?
У тебя юзеры под разными именами в терминалке работают?
Не должны они друг на друга влиять...

А в пределах одной сессии можно попробовать увеличить Desktop Heap, как я написал.
Это в данном случае не спортивно, но зато очень быстро.

Проблема у меня оказывается гораздо интереснее.
Судя по таскманагеру кол-во GDI объектов увеличивается на один примерно каждые тридцать секунд. При этом 1С находится в фоне и ничего не делает.
В обработке ожидания никаких форм не открывается, только создаются объекты MetaDataWork, ODBCRecordSet.
Засада в общем

20 сек. примерно так и растут объекты.
Но в обработке у меня ничего нет.
Делается запрос к базе и если есть изменения в некоторых местах, то мне посылается письмо. Но изменений нет, соответственно код не выполняется.

Вот только в глобальнике вызов обработки идет так:
Служебное = СоздатьОбъект("Служебное");
Служебное.глОбработкаОжидания();

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

Arta писал(а) 18. Мая 2007 :: 08:54:

Это чистый объект или все-таки есть визуальная форма?

Arta писал(а) 18. Мая 2007 :: 09:19:

Я, конечно, не Альф, но скажу. Косяк в отсутствии вызова Сервис.УдалитьШрифт.

Также косяк в том, что Сервис.СоздатьШрифт возвращает не объект, который сам удалит шрифт при собственном уничтожении, а код шрифта. А обязанность удаления возлагается на пользователя.

Приехали. Сам дурак получается. Видел же оговорку


Всем спасибо, посыпаю голову пеплом.

А его можно подставлять в Сервис.ВыбратьЗначение? 

Ясно. Вопрос исчерпан.

Хотя может вставить это свойство?

А... вон оно как устроено
Тады ой...

Мне помогло вот это решение - добавить ТЗ на форму отчета - для устранения проблемы вылетов 1С, связанных с превышением количества объектов USER. Решение взято отсюда:

trad писал(а) 30. Августа 2007 :: 07:23:


В течение года не мог разобраться, почему вылетают роботы на 1С (у меня их было 3 штуки). Эти роботы периодически запускали отчеты для всяхк нужд. Соответственно каждый запуск увеличивал число USER и в неопределенный момент происходил вылет базы. Пришлось тогда даже сделать проверку на "живость" (в смысле - живой-не живой) робота - кажый робот проверял двух остальных. В случае "неответа" - робот перезапускал базу другого.

Хочу вернуться к больной теме - утечке по GDI при использовании активиксов.

При использовании активиксов на форме после закрытия формы счетчик объектов GDI стабильно растет.
Величина прироста зависит только от навороченности активикса и является постоянной. Ну не могут же активиксы от разных производителей все поголовно течь.
Грешу все-таки на АктивИкс (Степан, прости, если не прав ).
При очень активной работе юзеров с такими формами ситуация получается очень нехорошая.
В клинических случаях даже пришлось увеличить лимит на количество объектов GDI.

Очень хочется проблему решить. Прошу помощи у тех, кому это тоже мешает.
И еще. Чем можно посмотреть количество объектов GDI в чужой терминальной сессии?

vip писал(а) 31. Июля 2008 :: 11:33:


Парт задание - опоить Степана пывом до синих огурцов. После этого на утро сказать ему, что он поклялся к вечеру все исправить.

P.S. GDI тоже уже в печенках

Arta писал(а) 31. Июля 2008 :: 12:13:

Последний раз он меня самого видел в форме синего огурца

И еще раз приведу ссылку на статью в MS KB: В компьютерах под управлением Windows XP приложения MFC вызывают утечку памяти в объектах GDI
Цитата:

Нашел временное решение - если в конфигураторе, после открытия конфигурации, запустить процедуру Intellisense Update1CppInts (которая просто открывает и закрывает формы модулей КОП), то количество GDI объектов резко падает до 300-400 штук.

Bob писал(а) 10. Февраля 2011 :: 08:16:

Ну если это сделать перед открытием в ПриОткрытии(), то конечно не растет, т.к. обработка не откроется
Подробней, пожалуйста.