stephenbrooks.orgForumMuon1Bug Reportsv4.34 memory leak
Username: Password:
Search site:
Subscribe to thread via RSS
[TA]z
2004-05-04 09:05:01
Stephen,

The memory occupied by the client tends to increase gradually over time.

In some instances, MUON1 is occupying more than 330 MB of memory.

*EDIT*
I have just found clients where 736+ MB memory is taken by MUON1.
Stephen Brooks
2004-05-06 02:19:46
Hmm.  I went around Muon1 with a memory-leak detector program a while back, but maybe I've messed something up in the interim.  I needed to check out the RAM consumption anyway for v4.4 as there could be many more particles than before.

[edit] What do you use for measuring process memory usage?  I've found the readout in Task Manager does weird things, as if parts of the memory are being swapped from one counter into another.
[TA]z
2004-05-06 06:38:49
I use pslist.exe (which I believe uses the built-in windows performance monitor) to poll every machine on the network for the muon1 process and it returns info for the process.



Name Pid Pri Thd Hnd Priv CPU Time Elapsed Time
muon1 704 4 1 41 50824 10:29:00.609 10:37:27.528
muon1 648 4 4 470 244912 202:45:18.593 206:01:06.497
muon1 536 4 4 466 247432 205:03:50.953 206:27:47.856
muon1 644 4 4 158 87860 19:52:21.609 20:10:48.294
muon1 580 4 4 628 351708 368:45:34.671 373:24:54.216
muon1 2056 4 2 73 18204 23:36:22.531 11:54:51.813
muon1 604 4 4 470 267256 197:34:52.921 205:34:13.825
muon1 636 4 1 45 58756 12:41:11.156 12:45:46.106
muon1 592 4 1 27 52488 0:20:29.656 0:29:16.169
muon1 640 4 4 399 222244 158:38:37.875 159:13:17.950
muon1 540 4 4 163 74176 21:28:48.484 21:37:04.388
muon1 644 4 4 149 83032 14:22:11.296 14:27:48.778
muon1 628 4 4 198 106976 42:59:35.078 43:14:18.434
muon1 616 4 4 965 439520 479:06:21.265 485:26:14.747
muon1 588 4 4 192 109864 39:49:01.703 39:59:13.559
muon1 608 4 4 424 244760 179:39:46.375 181:15:38.309
muon1 640 4 4 188 105216 38:53:07.500 39:21:55.700
muon1 688 4 4 497 280548 203:27:42.281 205:33:29.294
muon1 1632 4 3 1575 576264 497:04:41.875 521:00:23.638
muon1 584 4 4 144 81788 14:24:43.406 14:26:57.294
muon1 656 4 4 242 102708 48:19:40.046 48:29:14.544
muon1 644 4 4 149 81260 14:21:43.046 14:27:50.060
muon1 628 4 1 27 51140 0:28:55.546 0:29:38.419
muon1 636 4 1 27 48032 0:32:24.140 0:34:03.185
muon1 684 4 4 203 65256 35:59:58.828 38:20:29.747
muon1 648 4 4 494 246840 203:53:20.781 205:25:29.294
muon1 636 4 4 140 60612 11:36:57.250 11:40:47.903
muon1 572 4 4 150 88100 14:06:59.812 14:17:57.310
muon1 668 4 1 54 60372 15:04:56.843 15:10:04.497
muon1 684 4 4 444 208096 139:43:47.750 140:16:10.966
muon1 676 4 4 215 112872 42:37:30.796 43:57:37.403
MUON1 1624 4 3 137 101060 13:58:48.125 13:37:49.169
muon1 624 4 4 389 196512 202:40:46.515 206:45:37.935
MUON1 1644 4 1 55 70700 10:49:56.328 11:23:57.919
MUON1 1644 4 3 399 129444 68:49:40.687 70:22:21.685
muon1 1696 4 3 228 115688 47:06:58.468 47:24:24.669
MUON1 2032 4 3 614 262672 176:49:41.921 190:03:48.919
muon1 640 4 4 317 163212 118:32:19.968 120:29:21.528
MUON1 1640 4 3 619 223184 182:54:31.875 191:51:35.419
MUON1 1636 4 3 143 99404 12:50:09.187 13:25:06.435
MUON1 1628 4 1 58 49020 12:56:29.078 13:00:58.263
MUON1 1636 4 3 128 91976 13:17:35.531 13:25:16.982
MUON1 1644 4 3 153 68868 19:32:09.937 19:51:09.982
muon1 560 4 4 1323 237808 645:16:42.359 646:25:52.888
muon1 1704 4 3 169 81060 31:44:59.890 16:01:11.872
muon1 1704 4 4 2179 376336 1073:06:27.468 541:33:27.403
muon1 1700 4 4 626 165048 272:35:19.796 137:41:09.966
muon1 1712 4 4 1085 60604 463:43:29.843 233:35:03.966

Stephen Brooks
2004-05-06 09:38:11
I've just run the leak test again and it appears I've got several small leaks, which I'm going to fix.  Probably if they've been running as long as your machines appear to be running, that'll be enough time for those leaks to really add up.
[TA]z
2004-05-06 10:55:27
Aha!  Admit it, you're secretly taking pleasure in the fact that you've utilized over 7 gigs (I've seen it as high as 10 gigs!Big Grin) of my memory .

Besides, I've known all along that you're secretly breeding mallard populations and tracking them with the muon1 program...

It seems the program first determines the probability of two mallards engaging in the function "SEXT" based on their relative "SKSE" levels.  If "SEXT" happens, you measure the "width" of the result to classify the new mallard as "big" or "small"

M-U-O-N

M allard
U psurge
O bservation
N etwork
[DPC]Stephan202
2004-05-06 15:47:51
Big GrinBig Grin
Things start to taste a little marmite flavoured over here.
Stephen Brooks
2004-05-07 02:01:11
You know, I was expecting boring replies this morning, for some reason.  Instead it appears I have leaky mallards Big Grin
[OCAU] badger
2004-05-09 19:15:50
quote:
Originally posted by Stephen Brooks:
You know, I was expecting boring replies this morning, for some reason.  Instead it appears I have leaky mallards Big Grin


Oh that'll leave a mess.  I have noticed that when I leave this machine running muon over the weekend, when I get back nothing will run (insufficient memory) or it has hung.  This would explain why...

I guess I need to restart the process every so often...
[TA]Confused
2004-05-10 03:03:41
I'm having this problem with some systems as well, running Windows 2000, which are on 24/7.

I don't want to have to remove them from the project, but I feel that I have to, as the systems are slowing to almost a halt, and therefore running DPAD is not as transparent to the end users as I would like.


Garry
Stephen Brooks
2004-05-10 03:06:20
That's OK for now - the other possibility is if you can figure out some way to get (e.g.) Task Scheduler to shut down and restart the Muon1 program every 12/24 hours or something.

I'm trying to trace the memory leak(s) at the moment - I won't release v4.4 with known leaks.

[update] Fixed 2 small leaks so far.  There appear to be about 3 or 4 other small ones, plus one big and rather complicated one.
[TA]z
2004-05-10 07:28:52
good to hear Smile

thanks for the update
Stephen Brooks
2004-05-10 08:19:26
The "3 or 4 other small ones" turned out to all be caused by the same thing, which I've fixed.  Now it's just the peculiar one to do with the decays.  Trying to do memory management when the things you are managing randomly split and are also being dealt with in multiple threads has the potential to be a little tricky...

BTW, the stats were down for a while today, also due to some code rearrangment (I foolishly recompiled genstats with buggy code, meaning I was obliged to fix those particular bugs and get it back online quickly).  It seems to be fine now.

[update] I've just fixed the big leak as well.  All of these were correctable by essentially one-line modifications like inserting a "free" command somewhere.  The trick was figuring out _where_...
[TA]z
2004-05-10 09:44:55
will you replace the v4.34 client with one that addresses the leakiness or wait until v4.4 to update the latest client available to us?
: contact : - - -
E-mail: sbstrudel characterstephenbrooks.orgTwitter: stephenjbrooksMastodon: strudel charactersjbstrudel charactermstdn.io RSS feed

Site has had 25163005 accesses.