Thread: ioNinja Issue
View Single Post
Old 03-22-2010, 02:01 AM  
Too much time...
Join Date: May 2005
Posts: 1,194

That looks like the annoying lockup bug... You running win2k3? It seems to happen far more often on that OS especially with multi-core/processor setups. Win2k8/XP/win7 would be better choices if possible. The memory usage number you quoted doesn't really mean anything. You'd have to look at VM/Commit/Working Set details for the process to get a better idea of memory usage but I doubt that's the problem given how it's acting.

You've mentioned ioNinja, are you also using nxTools or other scripts? Do you do imdb, etc lookups? Have lots of mp3/movie uploads? Are most transfers using SSL? How many users online/transferring at a time? How much uptime do you get before you see the problem and anything in particular that seems likely to trigger it? Just trying to get more info to compare with others who have the problem.

If this problem is happening every day or so for you there are a few possible things to look forward to. The next feature release of ioFTPD will be trying openSSL to see if ditching the MS crypto libraries makes a difference since it seems to use the lock that gets stuck. It's an internal MS lock I can't touch which makes it annoying to debug.

There are 2 other things I just thought up that we could try though. I could perhaps make the server connect to itself every minute or so as part of the service loop or something. Thus when the server gets stuck it would figure it out quickly and either try and commit suicide (remember, it CAN'T exit gracefully, spawn processes, etc since it's an internal windows lock that is stuck and it's screws everything up), or report a problem/fail to report and see if we can't get the service manager to try and kill the process if you are running it as a service. I don't remember off the top of my head if it will do that, or just try to start a new copy which won't solve anything since the socket to listen on will already be held. But if it does the service manager could be used to restart it automatically if I can make it terminate which while not a very graceful solution would at least keep downtime to a minimum.

The other option to try is to use processor affinity to make ioFTPD only ever use one processor as this should reduce the chance of race conditions on the loader lock at the cost of lost performance. Since the server is so lightweight this might be worth the hit since it's usually I/O bound anyway and I'd trade stability for performance if it's a small hit.
Yil is offline   Reply With Quote