Server Freeze (99% CPU use) - Runuo 1.0RC0

[cward]

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.

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.

 

[Ingvarr]

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.

Read my post above. I too researched this problem, while you researched yours but for some reason you keep insisting that this is same problem you had. Even when evidence clearly points that this is different glitch, just outcome is the same (shard hangs).

 

[cward]

Well, this is a limitation of emulador... because, if dotnet limit to use 60% of RAM memory of the server, if shard grows up, more and more memory is required, and this "memory upgrades" never stops. Plesae... I think this problem can more attetion, for a workaround.
My Shard haves 800k items and 60k mobiles, and this is not a "large" shard yet! This freezes reduce the uptime of server (2 restarts by day, 12/12 hours) and causa a lot of problems with it. Then, i need your attention for a workaround, for sollution for it.

I dont have any mobiles or items to remove :-(
Then, the only way if ADD MORE MEMORY to server... because .net... but.. this is a limitation for ME, and I think, its a limitation for RunUO too... Never can be a large shard with RunUO without a "LARGE" amount of memory (RAM > 2Gb).

This is problem for me... and i think, for others shard admins in this community, then... :-(

Thanks..

You said you had 5000 accounts, If all 5000 accounts are not active why keep them? I don't think 130 players would require 5000 accounts. Unless you are just keeping them as some type of E-Penis. Deleting the inactive ones would free up a lot of your RAM.

 

[cward]

Clearly this is not the same problem you had. Only outcome is the same (shard "hangs"), but you can achieve this in dozen ways.

I think you missed part of my post or didn't bother to read it.

If you are freezing at 40% then obviously its not your RAM.

Also if this is a RunUO issue and not a hardware issue why are you the only person having this issue?
What are your system specs?
What custom scripts do you have installed?
What scripts have you modified?

 

[Ingvarr]

Ive read, and I knew that.
I just trying to say that adding more RAM is not the universal solution.

Possibly there is rare core bug, and if everybody will just brush it aside saying "I dont have it, must be your RAM or custom script or something" it will never be fixed.

I said, Ive localised the thread that stalls the excution. This is the core packet handling thread and call stack is all around internal core procedures - how is this hard to understand? I provided all information in above posts.

Also it started somewhere around B36.

Iam not the only one person having this issue (do a search on my post and youll see dozen similar threads in past time). But Iam think that Iam the only one still havent gave up, because all answers for past months were "faulty hardware buggy custom script, add more ram"

 

[Ryan]

Man you guys are just not listening.

This is NOT a problem with RunUO's core.

UO Gamers Hybrid has no problem like this. We run our software in the largest production environment around. Yes thats right while having the most popular emulatore we also have the largest shard around.

The software is fine. Either you have a hardware issue or a custom script issue.

I am sorry I cannot help you with that.

 

[Defrag]

I agree with Ryan. Check you hardware first. Here is a link to a memory tester. Run this with no other applications running. See if you have a bad RAM chip, if not maybe you CPU has a problem. Check these things first. If all hardware is ok then it must be a custom script causing the crash. I ran into these same issues with NWN. 1 custom script made the entire server crash, about 1 hour after peolpe played on our server. But of course we ditched NWN to use RunUO

Memory Tester link.
http://www.hcidesign.com/memtest/

 

[cward]

Ingvarr, You are also the first to be using under 60% of RAM. Most of those threads people were using 256MB to 512MB of RAM. Had some pretty crap hardware or scripts that had some bad coding. You are using 40% of RAM, I have a pretty busy server with 1GB of RAM I never experience any problems at this level. You basically refuse to give us any information and are here complaining. Even better question are you running 1.0RC0?

 

[Ryan]

seph,
You have 1 gig of memory, by default this means you can only use about 60% of such memory. If your using upwards of 600 MB of memory this means you must add more memory.

Its a limitation of .NET Framework and your just going to have to accept that. If you cannot their are many many unfinished emulators your welcome to try all that have their own bugs/

wrong

 

[cward]

How is that wrong? If it is the sites I've been reading and information I've been giving are wrong also. If theres something we can do to get past that 60% limit what is it?

 

[Ingvarr]

See cward, it must be the some faulty custom script that caused your server to freeze when it used more then 60% of RAM (wink)

 

[cward]

I'm doubting that, I found over 5000 sites and forum topics regarding the RAM limit with .Net.

 

[Phantom]

Ryan

I was going off what I read by other people, who i assumed did their research.

thats the last time it will happen.

 

[cward]

Ryan

I was going off what I read by other people, who i assumed did their research.

thats the last time it will happen.

Ryan is yet to tell us why it is wrong.
http://www.dotnet247.com and the msdn site both mention this limit and say it is intentional. They just do not say why it is intentional.

 

[Ryan]

The basics are this.

In a standard server environment address spacing in memory is 2 gigs for the OS kernel and 2 gigs for the user applications. So in essence, 2 gigs for windows and 2 gigs for RunUO. Of that 2 gigs RunUO cannot use all of it. You can read why here:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/monitor_perf.asp

Now, as for getting past 2 gigs you can use the /3GB boot.ini change and then you can access up to 2.4 gigs of RAM because the OS gets 1 gig of RAM and the user space gets 3 gigs.

That is the only limitation. Keep in mind this only applies to servers with large amounts of physical memory, if you've only got 512MB's, then you can only use what you've got.

 

[Mark]

Ryan hit the nail on the head, the 60% 'limitation' is a precaution dealing with address space. If you had 2GBs of memory, by default RunUO would only be able to use 1.2 of that, Ryan's link will explain why if you read it. If you only have 512MBs of physical memory, you should never run into this issue (unless you have a rediculously massive paging file) and RunUO will use as much as it can.

 

[cward]

Yeah, I ran across that page also and read it. But the servers that do not have enough RAM for the 3GB switch has the 60% limit from what I understood. Also isn't 4GB of RAM required to use the 3GB switch to get the full 2.4GB which is 60% of 4GB?

http://support.microsoft.com/default.aspx?kbid=291988

 

[cward]

Ryan hit the nail on the head, the 60% 'limitation' is a precaution dealing with address space. If you had 2GBs of memory, by default RunUO would only be able to use 1.2 of that, Ryan's link will explain why if you read it. If you only have 512MBs of physical memory, you should never run into this issue (unless you have a rediculously massive paging file) and RunUO will use as much as it can.

Then according to that the 60% limit is correct for the lower RAM systems like I stated.

 

[Mark]

You guys are mixing apples and oranges big time, lets take this step by step.

Virtual memory is physical memory and your paging file.

32bit systems have 4GB of address space. Address space is fairly self explanitory, its the space where all virtual memory is indexed and allocated.

By default, this 4GB of address space is allocated as 2GB for the user, and 2GB for the Windows kernel.

There is a Windows tweak that will change that allocation to 3GB to the user, 1GB to Windows kernel.

.NET will only use up to 60% of user address space, to help prevent out of memory exceptions. By default, this is 1.2GB, and with the /3GB boot tweak, it becomes 2.4GB.

What this means to you: if you want to use more than 1.2GB of virtual memory with a .NET application, you need to apply the /3GB tweak. If you only have 512MB of physical memory and a reasonably sized paging file (512MB or so), you will have 1GB of virtual memory, you will never come close to this 1.2GB address space limit, and therefore RunUO will use any resources available to it.




cward, your above post is completely wrong and I still feel you don't have a grasp on the issue. Regardless if a server has 32MB of virtual memory or 8GB, it can only use 1.2GB in .NET because of address space restrictions. That maximum can be raised to 2.4GB by extending user address space with a Windows tweak.

 

[cward]

So what is your recommendation for pagefile size on 512MB and 1GB systems to prevent this Server freeze at 60% RAM useage? Should we go with a larger page file or a smaller page file? I'm asking because I had a 1GB pagefile and 512MB DDRAM and experienced this freeze at 60% RAM useage. I bought an addition 512MB DDRAM and the freeze was gone and my pagefile is still set to 1GB. Should I increase the pagefile, leave it like it is or lower it?