Slow zone connection to world

[Dominatus]

Has anyone else noticed that zone servers connect to the world server very slowly under Linux 050DR3?

The processes aren't doing anything CPU intensive accordning to top, but after starting a zone process, it takes about 5 minutes to connect to the world on my Linux test server.

I'll try and get some truss info and see what they are doing, but they appear to just be sitting there pausing for some reason.

Anyone else seen this behavior under Linux?

[Dominatus]

Ok, I ran strace and got some output. It appears it is getting in a loop getting UNIX time. Here is the important snippit (I think) from the strace:

brk(0) = 0x81e7000
brk(0x81e9000) = 0x81e9000
read(5, "\1\0\0\360", 4) = 4
read(5, "\376", 1) = 1
time([1064484656]) = 1064484656
getpid() = 8317
write(1, "[Status] Loading items\n", 23) = 23
write(6, "8317 [09.25. - 05:10:56] Loading"..., 39) = 39
open("/home/stailey/eqemu/libEMuShareMem.so", O_RDONLY) = 7
read(7, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`( \0\000"..., 1024) = 1024
fstat64(7, {st_mode=S_IFREG|0755, st_size=187886, ...}) = 0
mmap2(NULL, 42740, PROT_READ|PROT_EXEC, MAP_PRIVATE, 7, 0) = 0x40015000
mprotect(0x4001f000, 1780, PROT_NONE) = 0
mmap2(0x4001f000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 7, 0x9) = 0x4001f000
close(7) = 0
time([1064484656]) = 1064484656
getpid() = 8317
write(1, "[Status] libEMuShareMem.so loade"..., 34) = 34
write(6, "8317 [09.25. - 05:10:56] libEMuS"..., 50) = 50
fcntl64(5, F_SETFL, O_RDWR|O_NONBLOCK) = 0
read(5, 0x81dd5b8, 8192) = -1 EAGAIN (Resource temporarily unavailable)
fcntl64(5, F_SETFL, O_RDWR) = 0
write(5, "#\0\0\0\3SELECT MAX(id),count(*) FRO"..., 39) = 39
read(5, "\1\0\0\1", 4) = 4
read(5, "\2", 1) = 1
read(5, "\23\0\0\2", 4) = 4
read(5, "\0\7MAX(id)\3\v\0\0\1\3\3\3@\0", 19) = 19
read(5, "\24\0\0\3", 4) = 4
read(5, "\0\10count(*)\3\25\0\0\1\3\3\1\0\0", 20) = 20
read(5, "\1\0\0\4", 4) = 4
read(5, "\376", 1) = 1
read(5, "\f\0\0\5", 4) = 4
read(5, "\00567382\00523980", 12) = 12
read(5, "\1\0\0\6", 4) = 4
read(5, "\376", 1) = 1
stat64(".", {st_mode=S_IFDIR|0755, st_size=512, ...}) = 0
semget(1224941855, 1, 0666) = -1 ENOENT (No such file or directory)
semget(1224941855, 1, IPC_CREAT|0666) = 2162690
semctl(2162690, 0, IPC_64|SETVAL, 0xbffff60c) = 0
shmget(1224941855, 11227200, IPC_CREAT|IPC_EXCL|IPC_NOWAIT|0x180|0600) = -1 EEXIST (File exists)
shmget(1224941855, 11227200, IPC_NOWAIT|0x100|0400) = 32768
shmctl(32768, IPC_64|IPC_STAT, 0xbffff660) = 0
shmat(32768, 0, SHM_RDONLY) = 0x40c2d000
semctl(2162690, 0, IPC_64|IPC_RMID, 0xbffff60c) = 0
gettimeofday({1064484656, 619351}, NULL) = 0
nanosleep({0, 10000000}, NULL) = 0
gettimeofday({1064484656, 629454}, NULL) = 0
nanosleep({0, 10000000}, NULL) = 0
gettimeofday({1064484656, 644467}, NULL) = 0
nanosleep({0, 10000000}, NULL) = 0
gettimeofday({1064484656, 659452}, NULL) = 0
nanosleep({0, 10000000}, NULL) = 0
gettimeofday({1064484656, 674466}, NULL) = 0
nanosleep({0, 10000000}, NULL) = 0
gettimeofday({1064484656, 689454}, NULL) = 0
nanosleep({0, 10000000}, NULL) = 0
gettimeofday({1064484656, 704466}, NULL) = 0
nanosleep({0, 10000000}, NULL) = 0
gettimeofday({1064484656, 719452}, NULL) = 0
nanosleep({0, 10000000}, NULL) = 0
gettimeofday({1064484656, 734466}, NULL) = 0
nanosleep({0, 10000000}, NULL) = 0
gettimeofday({1064484656, 749451}, NULL) = 0
nanosleep({0, 10000000}, NULL) = 0
gettimeofday({1064484656, 764466}, NULL) = 0


It does the gettimeofday loop forever. I'm not a programmer so I have no idea where to look from here, just curious if this is something in my environment or a global Linux server issue.

thanks!

[Dominatus]

Almost forgot to mention,. this is a new build from the CVS as of 25-sept-2003 at about 10:00 AM EST.

[Dominatus]

Ok, it was the db apparently. After several re-sourcing of MWnpcdb_050_default0_3.sql I switched to MWnpcdb_050_alpha0_1.sql and it works fine. Not sure why, but I'll dig into it and find out :lol:

[Trumpcard]

A better way to debug that would be to compile with -g -pg flags to enable profiling, then exit the zone after the zone has started, then use gprof to look at the gmon.out file to determine where all the time in the executable is being spent.

[Dominatus]

thanks Trumpcard, I'll give that a shot next time I run into problems!