| Subject | RE: [IB-Architect] trouble with sweep |
|---|---|
| Author | Jim Starkey |
| Post date | 2002-10-18T21:40:11Z |
At 05:10 PM 10/18/02 -0400, Leyne, Sean wrote:
single mutex on the engine. Perhap Charlies addressed the
problem. But the gc thread must lock pages and fetch meta-data.
If it blocks a worker thread or a worker thread blocks it, things
are not going to go at all well.
I should confess that although I discussed many of the issues
in depth with Charlie, I have reviewed his changes.
young pups for archaic. It's supposed to be the other way around.
Hey, pups, get with the program!
every now and again does the trick. But yes, fill memory with a
couple of gigs of uncommitteed data and the system is going to
thrash. I could probably come up with another dozen stupid ways
to destroy system performance, likely allocating 500 mb of java
objects during a transaction step. Happily, most application
programmers don't need coaching on this subject.
But while we're on the subject, Netfrastructure does use a
garbage collect thread, but for different reasons. Netfrastructure
records are sucked into memory on first reference, then stay there
until the garbage collect thread decides that the aggregate amount of
record memory has exceeded an upper limit, at which point the GC
thread kicks out enough records to bring the usage down to a lower
limit. Doing it without becoming lock bound was a fun problem
to solve.
Jim Starkey
>It probably wouldn't be if there weren't what amounts to a
>I'm not so sure that the design/idea of the GC thread is such a bad
>idea. It seems reasonable that the server idle time should be used to
>perform and valuable task -- clean pages is a 'good thing', in favour of
>improving the speed or readers and writers.
>
single mutex on the engine. Perhap Charlies addressed the
problem. But the gc thread must lock pages and fetch meta-data.
If it blocks a worker thread or a worker thread blocks it, things
are not going to go at all well.
I should confess that although I discussed many of the issues
in depth with Charlie, I have reviewed his changes.
>Yeah, but the Old Wolf is arguing for modern technology and the
>Yep, that battle is still "a waging", there a lull in the battle as the
>camps (the young pups and the Old Wolf) regroup for the next assault.
>
young pups for archaic. It's supposed to be the other way around.
Hey, pups, get with the program!
>Back to the Netfrastructure model -- it is very cool. Although, sinceIt's only an issue during initial data load, where a periodic commit
>Jim explained to me (one night over some drinks), I have wondered if
>that approach (in MGA memory only) would run into problems when the
>amount of changes was larger than available RAM/memory, but I'm sure
>that Jim had already taken that into account.
>
every now and again does the trick. But yes, fill memory with a
couple of gigs of uncommitteed data and the system is going to
thrash. I could probably come up with another dozen stupid ways
to destroy system performance, likely allocating 500 mb of java
objects during a transaction step. Happily, most application
programmers don't need coaching on this subject.
But while we're on the subject, Netfrastructure does use a
garbage collect thread, but for different reasons. Netfrastructure
records are sucked into memory on first reference, then stay there
until the garbage collect thread decides that the aggregate amount of
record memory has exceeded an upper limit, at which point the GC
thread kicks out enough records to bring the usage down to a lower
limit. Doing it without becoming lock bound was a fun problem
to solve.
Jim Starkey