Memory increasing
in [Visual Objects]
|
From: Arne Ortlinghaus on 6 Aug 2010 03:12 Hi Bernhard, it could be interesting to look also at the following values in the Task Manager: - Handles - GDI Object - User Handles May there are other windows resources not released correctly. Arne Ortlinghaus
From: Bernhard Mayer on 6 Aug 2010 03:22 Hi Arne, thanks for your answer; Dirk already told me in the vops newsgroup to watch these values in the task manager. All of these values are constant. BR, Bernhard "Arne Ortlinghaus" <Arne.Ortlinghaus(a)acs.it> schrieb im Newsbeitrag news:i3gckt$h6u$1(a)news.eternal-september.org... > Hi Bernhard, > > it could be interesting to look also at the following values in the Task > Manager: > > - Handles > - GDI Object > - User Handles > > May there are other windows resources not released correctly. > > Arne Ortlinghaus
From: Bernhard Mayer on 6 Aug 2010 03:54 Hi Geoff! The problem emerged at one of our customers' Terminal Server; after a few hours our application raised up to nearly 2 GB RAM - and of course, this slowed down all other users. So far this happened "only" at one customer to this extend but I can watch the RAM rise for a few KB every timer intervall even on my PC - and there is no rise if the timer with its function is not set. BR, Bernhard "Geoff Schaller" <geoffx(a)softwarexobjectives.com.au> schrieb im Newsbeitrag news:4c5b36ae$0$34569$c30e37c6(a)exi-reader.telstra.net... > Bernhard. > > But why do you say you have a problem? Does the app crash? How much memory > is assigned that you are worried over? Did you watch your app for 10 hrs? > Basically, this is entirely normal windows behaviour. Usually the OS will > not request dynamic memory back from an application unless it really needs > it. It is often cheaper to let an application keep the memory space it > used than reduce it, thus forcing the application to continually > reallocate. > > The second thing to remember (from a TS perspective) is that your VO > application is restricted to 16MB of dyn RAM unless you did something to > increase that deliberately. So no matter what, your app has a natural > ceiling. The rest is OS management and I wouldn't bother worrying. > > Geoff > > > > "Bernhard Mayer" <Idonotexisthere(a)nowhere.com> wrote in message > news:4c5a64ba$0$19172$91cee783(a)newsreader03.highway.telekom.at: > >> Dear fellow VO'ers! >> >> In my application I have a timer function doing some import work; every >> time >> the timer is fired (~ 10 seconds) I can see that the application's used >> memory increases in the task manager whereas the VO functions >> >> Memory(MEMORY_REGISTERAXIT) >> DynInfoUsed() >> >> show constant values. What can I do to force VO to release the used >> memory? >> I tried CollectForced() and DynShrink() with no success. >> >> It is definitely a problem if the application runs for a few hours on >> terminal server systems. Writing a service doing this job is planned in >> the >> future but is not possible now. >> >> Using VO 2.831 >> >> TIA, >> Bernhard >
From: Geoff Schaller on 6 Aug 2010 07:55 It sounds like you have several things going wrong here. Firstly, the VO shouldn't just go on rising. You need to set the TS environment up correctly. Such growth is entirely preventable. Read the docs. Secondly, if every timer call raise a few KB an I now beginning to wonder what is in your timer code! Geoff "Bernhard Mayer" <Idonotexisthere(a)nowhere.com> wrote in message news:4c5bbfca$0$15760$91cee783(a)newsreader04.highway.telekom.at: > Hi Geoff! > > The problem emerged at one of our customers' Terminal Server; after a few > hours our application raised up to nearly 2 GB RAM - and of course, this > slowed down all other users. So far this happened "only" at one customer to > this extend but I can watch the RAM rise for a few KB every timer intervall > even on my PC - and there is no rise if the timer with its function is not > set. > > BR, > Bernhard
From: Bernhard Mayer on 6 Aug 2010 08:27
Hi Geoff! > It sounds like you have several things going wrong here. Firstly, the VO > shouldn't just go on rising. You need to set the TS environment up > correctly. Such growth is entirely preventable. Read the docs. Ok, I'll ask the administrator to see to it. > Secondly, if every timer call raise a few KB an I now beginning to wonder > what is in your timer code! It is a function calling an order import class which instantiates an order object in turn - and this classes have > 100.000 lines of source code, so "show us the code" will not be possible. But if these classes have some memory leaks, why do the functions Memory(MEMORY_REGISTERAXIT) DynInfoUsed() Memory(MEMORY_STACK_FREE) not show any increasing values? Nor does CreateGCDump() show me any undestroyed objects/arrays etc - and so far this function had proven very helpful to detect memory leaks. BR, Bernhard "Geoff Schaller" <geoffx(a)softwarexobjectives.com.au> schrieb im Newsbeitrag news:4c5bf82a$0$34572$c30e37c6(a)exi-reader.telstra.net... > It sounds like you have several things going wrong here. Firstly, the VO > shouldn't just go on rising. You need to set the TS environment up > correctly. Such growth is entirely preventable. Read the docs. Secondly, > if every timer call raise a few KB an I now beginning to wonder what is in > your timer code! > > Geoff > > > "Bernhard Mayer" <Idonotexisthere(a)nowhere.com> wrote in message > news:4c5bbfca$0$15760$91cee783(a)newsreader04.highway.telekom.at: > >> Hi Geoff! >> >> The problem emerged at one of our customers' Terminal Server; after a few >> hours our application raised up to nearly 2 GB RAM - and of course, this >> slowed down all other users. So far this happened "only" at one customer >> to >> this extend but I can watch the RAM rise for a few KB every timer >> intervall >> even on my PC - and there is no rise if the timer with its function is >> not >> set. >> >> BR, >> Bernhard > |