I had this problem, I researched this problem, I fixed this problem, its not an excuse its a fact. Deal with it and stop being naive.
If you are freezing at 40% then obviously its not your RAM. Also I do not know why RunUO does not use the virtual memory. Perhaps because it is slower and cause performance issues? Keep in mind this is a recent issue and I'm sure they will work on it.
If you are freezing at 40% then obviously its not your RAM. Also I do not know why RunUO does not use the virtual memory. Perhaps because it is slower and cause performance issues? Keep in mind this is a recent issue and I'm sure they will work on it.
Ingvarr said:Tell me then cward why:
a) It freezes with 400 Mb used on our shard (1 GB total, so this is just 40% not 60%) And this is only if you count only physical memory. Btw its omnious to me why do you exclude virtual memory - .NET can use virtual memory.
b) Ive located the thread and procedure it freezes inside, and this is a core packet handling thread and core procedure (Server.NetState.OnSend). This is not .NET system thread and not garbage collection. And shard will exit this "frozen" state if Ill forcefully place this "stalled" thread into the "suspend" state. If there were the out-of-memory I wouldnt able to resume normal execution no matter what I would do.
If there was a bug with low memory for you, this does not mean that this is a same one. So please dont make an universal excuse for any freezing bugs is upgrading memory.
Also I dont rant about "making RunUO opensource" or whatever. I just hope this bug will be really fixed. Even if it does not happen on developers hardware/software setup.