11 Mar, 2007, syn wrote in the 1st comment:
Votes: 0
Hey everyone.

After switching over to Arthmoor coming from Fedora 1 and a single core proc, to Samson's Fedora 6 and Dual core setup I have a bit of a quandry.

I was able to fix the errors from switching over, but now I have another problem. My RoT codebase (pretty much stock at this time except for some moderate core world changes - i.e. OLC and specific world additions etc - ) is running like molasses and using about 3-4 times the ram it was on the old OS. I have made no makefile changes or any core code changes that would explain this intrinsicly.

So my question is, is anyone aware of specific changes that I need to implement to be completely compatable and cohesive on a 64 bit OS? Particularly changes to my makefile or mud loading. I do apologize if this is to broad or lacking in any evident way, and can provide any information needed.

Thanks for taking the time to read.

-Syn
11 Mar, 2007, Guest wrote in the 2nd comment:
Votes: 0
I also responded via email with this:

Well, first off, I'm glad you're happy with the server.

Sorry to see you're having trouble though. If it's any comfort, you're not alone in that. The upgrade to a 64bit environment has not gone as well as I'd hoped. But it's getting there and hopefully my experiences will help others to avoid getting hit too hard by migrating to this kind of environment.

But a couple of questions first:

When you say it lags a lot, when does it lag? Is it trying to do DNS lookups of some sort?

When you say it leaks, how are you making this determination? Your code shouldn't leak anything it wasn't leaking before. But the information you see on the "ps" display may not match what you're used to seeing. From what I can tell your process looks more or less normal in terms of memory usage. On the "ps ux" screen, the one you're most concerned with is the "RSS" column, which shows you're barely using much of anything.

Is the compiler giving you any residual warnings you haven't cleaned up yet?
11 Mar, 2007, syn wrote in the 3rd comment:
Votes: 0
Ok On my old server we went by the VSZ size, which was alot different, so aparently im actually using about 1/5th the ram I was before, I apologize for that misinformation.

Anyway to continue, It lags on certain calls, the greet help file, and the score are the predominent ones, sometimes commands themselves take a bit to resolve which is odd. The score is stock right now and pretty low on intensity which is why I can't seem to figure out whats wrong. I suppose in light of my idiocy about the ram use I am not leaking really at all, well in any way that matters at this time.

I have a couple implicit declarations to stuff like do_look because I havent added them into merc.h yet but error free and the warnings are negligable. The first compile I did had a clock time warning, but has since gone away so I payed it no attention. The normal DNS lookup message I would get I havent so I wouldnt think that it is, and the logs do not indicate as such either.

So in summary at this point I suppose the lag is the only problem, and could very well be something from my code itself. I only mention it as lag as half the time the command has almost no pause, and the other time it will get halfway through the score stop for a couple seconds and then complete the function which is new for this code.

Again, absolutely am happy with the server, and apologies about my own self misinformation as to the ram use.

-Syn

<– feels a bit of a fool right now :)
11 Mar, 2007, Guest wrote in the 4th comment:
Votes: 0
It's entirely possible there's some quirk in the code that behaves differently on 64 bit systems. That's part of the problem. Figuring out what the relevant differences are. It could be something really subtle, or it could be something very obvious which manifests itself as a boatload of error messages. Most codebases have not been tested in a fully 64 bit environment yet since just about all of the current mud hosts still use 32 bit.

The fact that you got a clock skew shouldn't be a huge problem, but I'd do a make clean just to be sure everything is in sync. Part of the code may not have been linked up properly.

As far as ram, I've always understood that the RSS figure is what you go by for how much actual usage you're currently at. VSZ has something to do with library allocations and other system hooks. Never been to clear on what it actually is. The VSZ figures did get considerably larger than they used to be for 32 bits. But if they were correct then Apache alone would have long ago consumed all of the ram :)
11 Mar, 2007, syn wrote in the 5th comment:
Votes: 0
Samson said:
It's entirely possible there's some quirk in the code that behaves differently on 64 bit systems. That's part of the problem. Figuring out what the relevant differences are. It could be something really subtle, or it could be something very obvious which manifests itself as a boatload of error messages. Most codebases have not been tested in a fully 64 bit environment yet since just about all of the current mud hosts still use 32 bit.

The fact that you got a clock skew shouldn't be a huge problem, but I'd do a make clean just to be sure everything is in sync. Part of the code may not have been linked up properly.

As far as ram, I've always understood that the RSS figure is what you go by for how much actual usage you're currently at. VSZ has something to do with library allocations and other system hooks. Never been to clear on what it actually is. The VSZ figures did get considerably larger than they used to be for 32 bits. But if they were correct then Apache alone would have long ago consumed all of the ram :)


Good to know, and Some hosting services require that they go by the VSZ and not RSS.. ;) Ill try to add dynamic buffers to the score and see what shakes with that, thanks.

-Syn
0.0/5