EQEmulator Forums

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)
-   Support::Windows Servers (https://www.eqemulator.org/forums/forumdisplay.php?f=587)
-   -   disable log files (https://www.eqemulator.org/forums/showthread.php?t=25240)

opyrus 05-15-2008 12:30 AM

disable log files
 
how do i disable the logs there realy eating up space on me. is there like a setting for this some where? after like one day my server log folder is like a gig id realy would rather have it not log anything.

trevius 05-15-2008 07:16 AM

Ya, all the devs run on linux I am sure, cause this problem doesn't happen on linux. On windows, the log files are insanely ridiculous. There is no easy way to disable the logs, but I you can stop them simply by deleting or renaming the log folder to another name. You won't get logs, and you will get a couple of errors when you start the server, but it doesn't cause any real problems. Then if you ever decide you want to actually get some logs to investigate a problem, you just put the folder back again. Pretty simple.

opyrus 05-15-2008 08:00 AM

much better i renamed the log folder to log.off dident even realy get an error just a debug msg in the server console.

opyrus 05-15-2008 01:25 PM

after running with no logs for about a day there is a major reduction in system useage. server is useing less ram less cpu and the number of system handles droped by 200.000 went from 500,000 down to 300,000 and disk IO has droped by alot to.

thepoetwarrior 05-15-2008 03:27 PM

My handles are at 51k. Anyways, I renamed my log dir and now Im a happier GM! Thanks for the tip!

opyrus 05-15-2008 05:14 PM

i may have forgot to note that i run all 306 zones static + 10 extra dynamics.

Angelox 05-15-2008 09:32 PM

Quote:

Originally Posted by opyrus (Post 148780)
after running with no logs for about a day there is a major reduction in system useage. server is useing less ram less cpu and the number of system handles droped by 200.000 went from 500,000 down to 300,000 and disk IO has droped by alot to.

I hope Cavedude sees this one - might help him out over at the PEQ server

jenco420 05-15-2008 10:13 PM

does'nt PEQ use a linux box? i personally hav'nt had any trouble with log files from eqemu on my linux box. MYSQL on the other hand ~.~

trevius 05-15-2008 11:30 PM

Ya, PEQ runs on Linux. And my linux box maybe gets 100-250mbs of log files per day or so, but I restart it every day or 2 anyway and the startup scripts erase all of the log files and start new ones. Linux handles the logs MUCH better than windows does for sure.

One thing I would love to see would be trying to disable almost all debugs accept for the most important ones in the source and seeing how much performance is gained. I bet it would be a surprising amount even on Linux. I know this isn't exactly related, but when I worked at AT&T, we weren't allowed to turn debugging on for the routers ever. This is because the huge amount of traffic that the backbone took would cause enough of a performance hit if you enabled certain debugs that it would crash the router for sure due to the processors not being able to handle that much more work load. But as long as you left debugs off, their processor utilization was at about 1%. I know debugging every packet is MUCH more work than all of the debugs that eqemu does, but I am also sure that debugs can and do use a considerable amount of resources.

I would LOVE to see some easy way to turn debugs on and off with a command, rule, or setting somewhere. Then you could use them when you want, and disable them when you have no need for them. The only way I know to keep the debugs from being processed at all is to remove each one from the source line by line (or comment out) and then recompile. That isn't exactly an "easy" way to turn them on or off tho lol.

Even by changing the log directory name, I think the debugs are all still processed, they just don't get written to the file, which that alone is enough to probably help performance some. But if they were disabled completely, I think it would make a considerable difference.

Maybe I will experiment with them sometime if I ever get the time to go through and comment them all out and recompile lol.

Aramid 05-16-2008 04:54 AM

I thought that the debug level could be set somewhere within one of the files,before compiling of course, as I know the code does a lot of checks for the debug LEVEL.

Also, if its so TITANIUM Supported, why are there still checks for the other Opcodes from Live, Anniversary and 6.x opcode files?

rojadruid 05-16-2008 06:49 AM

Quote:

Originally Posted by Aramid (Post 148820)
Also, if its so TITANIUM Supported, why are there still checks for the other Opcodes from Live, Anniversary and 6.x opcode files?

That is because some os us are using the old client still from way back and are happy with all that it offers. I am using 6.x myself.

trevius 05-16-2008 07:18 AM

Quote:

Originally Posted by rojadruid (Post 148823)
That is because some os us are using the old client still from way back and are happy with all that it offers. I am using 6.x myself.

And you are able to connect and play on servers running 7.x with that? As far as I know, only Titanium clients can play on 7.x servers. If that is the case, then there is no reason for all of those client version checks. It might increase performance a little to remove those checks (for both client and server). But, I think it is the other debugs that are the biggest resource hogs.

Aramid 05-16-2008 02:20 PM

Quote:

Originally Posted by rojadruid (Post 148823)
That is because some os us are using the old client still from way back and are happy with all that it offers. I am using 6.x myself.


Ok, that explains the 6.x checks, but then why the Live and Anniversary?

Aramid 05-16-2008 03:47 PM

Trevius,

Look thru debug.h in /common folder. There is where the EQDEBUG level is set. They have choices 0 thru 10 and it is set to 1 by default. Maybe experiement with those different levels.


All times are GMT -4. The time now is 02:22 AM.

Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.