Всем привет!
Есть компонента (в dll, то есть in-proc, сконфигурена запускаться через dllhost), поточная модель Both. В ней реализован свой пул коннекций к БД и клиенты периодически дергают через нее запросы к БД (работа через ADO) и получают результаты в виде ADOD.Recordset-ов. Проблема в следующем — при одновременной работе порядка 40 клиентов со временем (3-4дня) кол-во потоков у процесса dllhost выростает до 1000 и более , работа постепенно замедляется и в итоге впадает в ступор, после пристрела процесса сервера (dllhost) и повторного захода всех клиентов все ОК, но позже история повторяется . Дело втом что в самой этой компоненте я не работаю с потоками , те не создаю их сам ни где. В чем косяк , почему растет кол-во потоков?

Здравствуйте, <Аноним>, Вы писали:

А>Всем привет!
А>Есть компонента (в dll, то есть in-proc, сконфигурена запускаться через dllhost), поточная модель Both. В ней реализован свой пул коннекций к БД и клиенты периодически дергают через нее запросы к БД (работа через ADO) и получают результаты в виде ADOD.Recordset-ов. Проблема в следующем — при одновременной работе порядка 40 клиентов со временем (3-4дня) кол-во потоков у процесса dllhost выростает до 1000 и более , работа постепенно замедляется и в итоге впадает в ступор, после пристрела процесса сервера (dllhost) и повторного захода всех клиентов все ОК, но позже история повторяется . Дело втом что в самой этой компоненте я не работаю с потоками , те не создаю их сам ни где. В чем косяк , почему растет кол-во потоков?

Ну количество потоков может расти по целому ряду причин. Возможно ошибся ты сам при реализации пула ? Или сам забываешь освобождать ссылки на используемые обьекты ?

Здравствуйте, Tom, Вы писали:


Tom>Ну количество потоков может расти по целому ряду причин. Возможно ошибся ты сам при реализации пула ?

В пуле коннекций я не создаю потоки, у меня вообще нет ни строчки кода в компоненте где бы я их создавал, грубо говоря пул коннекций у меня просто массив ADO коннекций. При реальной работе 40 клиентов в нем стабильно сидит около 30 адо-шных коннекций (происходит в первые 3-4 часа работы) и их количиство более не растет, но тем не менее в процессе dllhost количество потоков растет

Tom>Или сам забываешь освобождать ссылки на используемые обьекты ?
Очень наврядли, тк хорошо тестировал (вставлены логи в места создания и разрушения объектов — все четко) и если бы было так, то была бы значительная утечка памяти, а память практически не течет. А с внешними объектами (адо рекордсеты и тп) работаю только через интерфейсные переменные (реализовано на Delphi), те подсчет ссылок происходит автоматический.

Здравствуйте, Аноним, Вы писали:

У меня нечто подобное было, при этом в Event Viewer выходило характерное сообщение.

Здравствуйте, Maxim111, Вы писали:

M>У меня нечто подобное было, при этом в Event Viewer выходило характерное сообщение.
А что было в сообщении? Вроде бы я в таких случаях ничего подозрительного в Event Viewer не видел, хотя может и незаметил.
И чем у тебя это закончилось, нашли что-то?

Может это адо как-то косячит? К примеру если создать адо-коннекцию к SQL Server-у то сразу создается с дестяток потоков, у меня обычно 30 коннекций ну ладно 300потоков но не за 1000 же!!!

Hello

> Tom>Ну количество потоков может расти по целому ряду причин. Возможно ошибся ты сам при реализации пула ?
>
> В пуле коннекций я не создаю потоки, у меня вообще нет ни строчки кода в компоненте где бы я их создавал, грубо говоря пул коннекций у меня просто массив ADO коннекций. При реальной работе 40 клиентов в нем стабильно сидит около 30 адо-шных коннекций (происходит в первые 3-4 часа работы) и их количиство более не растет, но тем не менее в процессе dllhost количество потоков растет
>

Вообще-то для Both объектов хранить внутреннее состояние не рекомендуется.
Так-же учитывая, что у ADODB.Connection потоковая модель Appartment и если Both компонент будет создаваться в MTA (для COM+ так скорее всего и произойдет), то получится то, что все объекты ADODB.Connection будут созданы в специальном "STA Host" который будет один на весь процесс и потенциально окажется одним из узких мест.

А чем не устроили стандартные возможности по созданию пулов?

Tom>>Или сам забываешь освобождать ссылки на используемые обьекты ?
А>Очень наврядли, тк хорошо тестировал (вставлены логи в места создания и разрушения объектов — все четко) и если бы было так, то была бы значительная утечка памяти, а память практически не течет. А с внешними объектами (адо рекордсеты и тп) работаю только через интерфейсные переменные (реализовано на Delphi), те подсчет ссылок происходит автоматический.
хм... ещё предположение. всегда ли ты корректно закрываешь ADO Connection. (или ты его вообще не закрываешь м всё 30 соединений всегда открыты ?) Может просто потоки — это потоки которые создаёт сам ADO, и если у тебя клиент отваливается, то соединение не закрывается ? или что то в этом роде.

Здравствуйте, TK, Вы писали:

TK>Вообще-то для Both объектов хранить внутреннее состояние не рекомендуется.
Это c чего? невижу никаких проблем. У меня компонента работает не под COM+, а под сурогтным процессом dllhost, обычный DCOM.

TK>Так-же учитывая, что у ADODB.Connection потоковая модель Appartment и если Both компонент будет создаваться в MTA (для COM+ так скорее всего и произойдет), то получится то, что все объекты ADODB.Connection будут созданы в специальном "STA Host" который будет один на весь процесс и потенциально окажется одним из узких мест.

Как бы оно так, но есть один нюанс .
Дело в том что в адошных объектах (коннекция рекордсет команда) реализован FTM , и тем самым реально создавая в MTA адо коннекцию в итоге мы все равно получим на нее прямую ссылку, проверрено именно так.


TK>А чем не устроили стандартные возможности по созданию пулов?
Вот некоторые из причин почему не стал исполььзовать стандартный OLE DB-шный пулинг коннекций: не все коннекции пулятся, к примеру к Accessy не пулятся, создается каждый раз а это окло 50-100мс, при времени работы запроса 10мс это более чем заметно в приложеняих. Были и другие проблемы связанные с управлениями транзакциями на клиентских сессиях, но не будем в это углубляться, скажем так свой пул оказался более удобным.

Здравствуйте, Tom, Вы писали:

Tom>>>Или сам забываешь освобождать ссылки на используемые обьекты ?
А>>Очень наврядли, тк хорошо тестировал (вставлены логи в места создания и разрушения объектов — все четко) и если бы было так, то была бы значительная утечка памяти, а память практически не течет. А с внешними объектами (адо рекордсеты и тп) работаю только через интерфейсные переменные (реализовано на Delphi), те подсчет ссылок происходит автоматический.
Tom>хм... ещё предположение. всегда ли ты корректно закрываешь ADO Connection. (или ты его вообще не закрываешь м всё 30 соединений всегда открыты ?)
Да постоянно открыты.

Tom>Может просто потоки — это потоки которые создаёт сам ADO, и если у тебя клиент отваливается, то соединение не закрывается ? или что то в этом роде.
Ну не за 1000 же потоков , сам видел было 1300 потоков (через Task manger). Когда клиент отваливается по DCOM-скому таймауту через какое-то время отваливатеся и его сессия (экземпляр моего компонента), проверял действительно нормально дестроится примерно через 5-10минут.
Те у меня примерно живет в среднем 40 сессий и они юзают в среднем 30коннекий из пула. 30 это потому что достаточно интенсивно но не очень работают иначе бы и коннекций было все 40.

Здравствуйте, Аноним, Вы писали:

А>Ну не за 1000 же потоков , сам видел было 1300 потоков (через Task manger). Когда клиент отваливается по DCOM-скому таймауту через какое-то время отваливатеся и его сессия (экземпляр моего компонента), проверял действительно нормально дестроится примерно через 5-10минут.

Проверь, все ли ресурсы ты освобождаешь, когда отваливается клиент. Было бы хорошо, если бы ты привел код.

Tom>>Может просто потоки — это потоки которые создаёт сам ADO, и если у тебя клиент отваливается, то соединение не закрывается ? или что то в этом роде.
А>Ну не за 1000 же потоков , сам видел было 1300 потоков (через Task manger). Когда клиент отваливается по DCOM-скому таймауту через какое-то время отваливатеся и его сессия (экземпляр моего компонента), проверял действительно нормально дестроится примерно через 5-10минут.
А>Те у меня примерно живет в среднем 40 сессий и они юзают в среднем 30коннекий из пула. 30 это потому что достаточно интенсивно но не очень работают иначе бы и коннекций было все 40.
ок. уговорил. всё у тебя написано правильно. тогда сделай следующее. приатачся к процессу дебугером с сделай break одному из потоков и посмотри хоть примерно callstack и чего он делает.

Здравствуйте, MaximE, Вы писали:

ME>Здравствуйте, Аноним, Вы писали:

А>>Ну не за 1000 же потоков , сам видел было 1300 потоков (через Task manger). Когда клиент отваливается по DCOM-скому таймауту через какое-то время отваливатеся и его сессия (экземпляр моего компонента), проверял действительно нормально дестроится примерно через 5-10минут.

ME>Проверь, все ли ресурсы ты освобождаешь, когда отваливается клиент. Было бы хорошо, если бы ты привел код.
На сессии ничего такого не хранится, хранится идентификатор сессии и подключенного юзера (Integer-ы) , те даже освобождать то нечего. Вот код деструктора

destructor TDataservice.Destroy;
begin
  {$ifdef DebugLog} WriteToLog(rkMessage,'TDataservice.Destroy'); {$endif}
  if dsLoginOK in FStatus then
    try
      //откатываем транзакции которые возможно были на этой сессии, чтоб освободить их в пуле для использования
      //другими сессиями
      RollBack;
    except
    end;

  FreeAndNil(FTranLock); //это крит. секция
  inherited; // унаследован от TAutoObject
  with SessionList.LockList do
  try
    Remove(Self); //удаляю сессию из списка
  finally
    SessionList.UnlockList;
  end;
  if ComServer.ObjectCount=0 then
  begin
    {$ifdef DebugLog} WriteToLog(rkMessage,'Разрушен последний экземпляр TDataservice'); {$endif}
    //без этого при завершении приложения были проблемы. страшный непонятный завал при освобождении ConnectionPool
    //завал были при попытке освободить ADO.Connection, адошные библиотеки к этому времени уже оказывались выгруженные!!!???
    //после переноса разрушения пула сюда (при освобождении последнего Dataservice) стало нормально!
    FreeConnectionPool;
  end;
end;

вот что хрантся в объекте сесии

   private
    FUserID: OleVariant;
    FUserName: string;
    FTranLock: TCriticalSection;
    FTranLevel,
    FSessionID: Integer; // SessionID для рулежа с транзакциями в пуле коннекций
    FConfigName: string;
    FStatus: set of TDataserviceStatus; //просто перечисление

Здравствуйте, Tom, Вы писали:

Tom>ок. уговорил. всё у тебя написано правильно. тогда сделай следующее. приатачся к процессу дебугером с сделай break одному из потоков и посмотри хоть примерно callstack и чего он делает.

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

Здравствуйте, Аноним, Вы писали:

ME>>Проверь, все ли ресурсы ты освобождаешь, когда отваливается клиент. Было бы хорошо, если бы ты привел код.

[]

Прости, такой код я не понимаю (delphi?).

Коллеги!
У кого-нибидь в подобной схеме есть работающее приложение, без вышеупомянутой проблемы роста потоков?

Уточню схему: 3-уровневая архитектура, на выделенной машине под стандартным сурогатным процессом dllhost (те просто по DCOM-у без всяких COM+) работает сервис (назовем его дата-сервис), возвращающий клиентам по их запросам адо-рекордсеты. Дата-сервис реализован с потоковой моделью Both те клиентские сессии (экземпляры coclass-а Dataservice) живут в MTA. Всеми сессиями используется общий (свой) пул коннекций.