Zugg Software :: View topic

Beginner Joined: 30 Jan 2005 Posts: 26

When CMUD has been on for about 12h it starts having periodic lags, and the lag keeps becoming longer and longer. First the lag is under one second but after a day it's like 3 seconds. The lag (or freeze) happens exactly every 60 seconds and it freezes the whole computer, not just CMUD. When looking at task manager the CPU usage of CMUD caps during the freeze.

I have tried disabling all triggers and tick timer but they don't make any difference. Although I haven't tried if the lag builds up with all triggers disabled. The only way to get rid of the lag is to restart CMUD. Anyone experienced this behaviour?

I think it might have something to do with #alarms. After executing about 10000 alarms it starts to show. I know the amount of alarms used from the alarm trigger: _Alarm13745 etc.

Posted: Tue Sep 09, 2008 7:06 pm

Are you removing the alarms when they are finished? In other words, if you go into the Package Editor, do you have 10,000 alarms still?

Every 60 seconds, CMUD is saving changes to your settings to the *.PKG database file for your session. So it sounds like a problem where it still thinks you have 10,000 alarms and that all of them have changed since the last save.

If you don't have lots of alarms, then post your exact script for creating the alarms so that I can try to reproduce the problem here.

Edited: I also changed your topic title to be more specific

Beginner Joined: 30 Jan 2005 Posts: 26

Well the alarms get removed automatically since I use temporary alarms, like: #alarm +4 {blah blah}. So Package Editor only shows current "pending" alarms, 0-3 at a time.

Posted: Tue Sep 09, 2008 8:41 pm

OK, yes, I see the problem. When you create the alarm with #ALARM, it gets added to the package database (even if it's a temporary alarm). When the database is saved, the alarm record is saved too. When the alarm expires, the alarm in memory is deleted, and when the database is saved, the record is deleted from the database.

I will play with this to see if there is a bug where creating and then deleting a setting still causes a database update every 60 seconds or not. But I will also try to add a "temporary" flag in the future so that temporary alarms like this are never even saved into the database in the first place. The #TEMP triggers need this anyway, so it's already been on my to-do list.

Until this is fixed, I suggest either that you restart CMUD more often, or redesign your scripts to use the #WAIT command, or multistate triggers with a Wait state, or have a single alarm that you enable and disable. For example, you might be able to do this instead of your alarm:

#THREAD {#WAIT 4000;blah blah}

That will create a background thread that will wait 4 seconds and then execute. The only potential problem with this is that after 4 seconds, the "blah blah" will execute simultaneously with any other scripts that are running, so if this is a complex alias script, then you might run into threading problems. But if it's just a command to send to the MUD, then it will work fine.

I'm sure some other other Gurus can also suggest more ways to solve your problem. Regardless of the bug, creating thousands of temporary alarms is definitely not the most efficient way to do something.

Beginner Joined: 30 Jan 2005 Posts: 26

Yea this is not a big problem for me, since I'm normally restarting CMUD anyway. I just wanted to inform you of such behaviour. :) I mean if there is a bug it can always cause other problems too.

Apprentice Joined: 05 Apr 2008 Posts: 121

OMG
I've been having this problem for a bit, I went as far as disabling all my settings and restarting cmud, then re-enabling them 1 at a time.
and when they all went back activei t worked :P now i know why. :)