What raid size should be "stable"?

gnode · #1 02-10-2009, 12:05 AM

I am getting complaints of instability when I have 25+ people in a zone raiding, like for NToV.

At what point do people usually start seeing degradation on raids? According to perfmon, my CPU just hovers around 7-10% most of the day, and spikes to like 13-18% during raids. I have tweak my mysql db to not hit the hd constantly, so my hd read/writes are much lower. The db mostly operates in memory now.

Are there any configuration tips to increase stability for peak conditions like raids? It just does not seem like a hardware problem.

Specs on the server:
P4 2.4ghz
2gb ddr400
7200 rpm hd with eqemu and db on one small partition (quick and easy to defrag), swap and OS on another.
Clean install of Windows XP and on a fresh boot, only 20 processes run. The server does nothing but EQEMU.

Typically the population is 35-50 players. Not everyone attends the raids. When people are spread out the problem does not seem to show itself nearly so much. But when a lot gather for a raid, sometimes the zone will crash.

21 static zones and 15 dynamic.

gnode · #2 02-10-2009, 12:15 AM

Oh and I also have a script close and restart eqemu every morning at 7:30 to start the day fresh for everyone.

ChaosSlayer · #3 02-10-2009, 12:32 AM

I would say that for any serios server - 4 GB of RAM is a must, and of course uploading bandwith

gnode · #4 02-10-2009, 01:19 AM

I have 1.4gb free right now though.......

The db is operating 100% in memory.

No zone.exe is over 21mb atm, and most are 6-20mb.

I think there is plenty of memory, just based on performance stats.

MNWatchdog · #5 02-10-2009, 03:29 AM

It's Windows that's the problem.

When a Windows machine gets to 25ish players, Windows based Emus lag.

Yeormom · #6 02-10-2009, 12:36 PM

Running windows has nothing to do with your server capacity...The size of your raid is completely dependent on what hardware and bandwidth you have to work with, bandwidth being the problem for most people.

gnode · #7 02-10-2009, 03:21 PM

I have 1mbit upstream. When people are dispersed across multiple zones, I can easily support ~45 players before people complain about lag.

What I am talking about here is having ~25 people in one zone doing a raid and every single person in the zone being booted to the login screen from the zone.exe crashing.

It does not seem like a bandwidth problem or a memory problem because my logs don't indicate that.

Does anyone here have anecdotal information such as supporting 50+ person raids on certain hardware/software specs? I am running the latest peq distro with numerous db and quest related customizations, but everything else is out of the box.

Are there any kind of configuration changes I should consider? Maybe I should reduce the number of zones I am using? Right now I have ~21 static and 15 dynamic zones.

**Derision** · #8 02-10-2009, 03:43 PM

If your zone.exe is really 'crashing' as in you get the message 'zone.exe has caused a problem and needs to close', accompanied by a 'zone has gone down' in the eqlaunch output, then this is due to a code bug.

What revision of code are you running ? A number of fixes for zone crashes have been comitted to the SVN over the months.

If the zone.exe is not really crashing, but everyone is getting booted to desktop, then this could be a bandwidth issue. When a lot of people are fighting in close proximity, every spell cast, weapon swing etc, that they make has to be transmitted to all the other nearby clients, which increases the bandwidth requirements a lot compared to when the same number of people are spread out across several zones.

EDIT: If your server is Gnomish Proving Grounds, the #version command shows me you are running a version of code from June 2008. I would seriously considering upgrading as there have been lots of stability fixes and new features since then. You'll probably have a lot of fun applying all the SQL updates since then though :(

gnode · #9 02-10-2009, 04:08 PM

Quote:

Originally Posted by Derision

If your zone.exe is really 'crashing' as in you get the message 'zone.exe has caused a problem and needs to close', accompanied by a 'zone has gone down' in the eqlaunch output, then this is due to a code bug.

What revision of code are you running ? A number of fixes for zone crashes have been comitted to the SVN over the months.

If the zone.exe is not really crashing, but everyone is getting booted to desktop, then this could be a bandwidth issue. When a lot of people are fighting in close proximity, every spell cast, weapon swing etc, that they make has to be transmitted to all the other nearby clients, which increases the bandwidth requirements a lot compared to when the same number of people are spread out across several zones.

EDIT: If your server is Gnomish Proving Grounds, the #version command shows me you are running a version of code from June 2008. I would seriously considering upgrading as there have been lots of stability fixes and new features since then. You'll probably have a lot of fun applying all the SQL updates since then though :(

Thanks this is the kind of info I need.

I am gnomish proving grounds and I did install in June. I used the installer off projecteq.net that (as far as I can tell) is the same one hosted there now ending in 110a.

My database has way too many changes made to it that were on the fly. I am totally comfortable with merging different tables from different databases. Is there any reason why I would not be able to update to the latest build and keep my existing db? Is there documentation about new required columns or tables? I can add them in as necessary and keep my existing data.

I guess I am saying, I don't care about changes made to quests or items. I do not plan to go beyond PoP on my server and am satisfied with content as it is and can make my own changes or additions as needed. How can I upgrade the actual server software components without impacting my data?

I also had a sneaking suspicion about bandwidth requirements going up in raids given the exponential amount of data from many people in close proximity fighting. Is there any server side setting where you can turn off "other hits" for everyone? It seems like that would help a ton and not hurt gameplay.

Andrew80k · #10 02-10-2009, 04:30 PM

I can answer some of your questions. There are a LOT of db changes including table additions, movement of columns, new columns, etc. Most, if not all, the changes can be made to your database without impacting your database. There was a new addition to the svn code base that included sql files that made the modifications. You'll need to add in all those changes that have been made from your current rev. The sql files are numbered for the rev that they pertain to. Also, you'll likely need to go through the changelog.txt file between the rev you update to and the rev you are currently on and ensure that you have all the changes. I'm not certain all the database changes were included in the sql files.

gnode · #11 02-10-2009, 04:33 PM

Thanks. I was just reviewing the changelogs actually.

I used to run this on my personal computer before I migrated over to a dedicated box. I still have the original files on my pc. Tonight I am going to load up a recent backup of my live db and do a test update and see how it goes.

Yeormom · #12 02-10-2009, 06:50 PM

Like Derision said, it's a problem in the code. Applying updates is probably a good idea but you could attach a debugger to your zone file and catch the exception that way as it is most likely one little thing that keeps getting triggered. There's always the one odd case that rarely occurs like a person trying to invite a charmed npc to the group and it tries to process the request because of some past modification.

gnode · #13 02-18-2009, 03:55 PM

In case anyone searches and finds this thread, the resolution to my raid stability problem was to upgrade to the 11/25/2008 release. Raids are now rock solid, even with 40+ people.