TM1 crashes when saving rule

[andre lie]

I experience TM1 crashing when saving rule on several og my cubes. When i view from tm1top, seems TM1 has recahed commit stage but then crashes.

Visual debugger appears then shows error: 'memory could not be written at reference....', server out of memory.

But before saving rule, i notice from windows task manager my server still have available memory. I am working on 9.1 SP3, 4 GB RAM, 8 cores processor. I try using old and new rule editor with same result

However, if i edit the rule from notepad, then restart the server, the rule can be loaded properly (without running out of memory). For time being, if anything to change on those rules, i have to do it from notepad and restart the server, which is really silly

Anyone has idea how to overcome this or this is software bug?

Regards
Andre

[mattgoff]

What version of TM1 are you running: x86 or x64? If x86, have you enabled the /3gb swtich in boot.ini? If not, TM1 can only use up to 2GB of system RAM. I assume that TM1 uses some additional memory during the commit process that's not necessary when computing from scratch.

Matt

[andre lie]

I am running x86 9.1 SP3

I don't think I have enabled the /3gb switch in boot.ini. Can you provide the line statement to enable it? Where is the file normally located?

Thanks
Andre

[mattgoff]

How to Set the /3GB Startup Switch in Windows

[andre lie]

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Enterprise" /noexecute=optout /fastdetect /3GB

Right Click my computer, choose properties, advance tab, settings under startup and recovery and then edit. Add the /3GB and save. Restart the server

I have tried saving one of the rules that normally causes the server down. This time, it completes sucessfully

Rgds
Andre

[ScottW]

Hi Andre,

The 3Gb switch buys you some breathing space but you should also have a look at why your rules are consuming so much memory.
Try using TM1'sbuilt in PerfMon cubes, the relevant one will be }StatsByCube to see which cubes are using the most memory, and whether memory usage is due to data or feeders.

If it turns out there isn't anything you can do to rewrite the application to be more efficient then ultimately you will need to consider x64. However you will usually find that a lot of memory can be saved by making sure rule and feeder statements have tight and matching area statements.