So if this a Netty issue, I wonder what the common thread is.... network hardware? If so, swapping in a new NIC could be an easily solution... if that's what it turns out to be.
My issue was resolved by the NOGUI switch and I don't remember ever seeing any netty IO methods eating enough CPU time to show up on the VisualVM radar.
Vanilla 1.72
Java V.7 update 45
Windows 8.1 x64
My network card is either an Intel or an integrated Marvel chip, I'll check when I get home. If this issue affects both Linux and Windows, that makes me think it's Netty + network hardware related.
@Hunter Parkhurst - yeah, add the NOGUI option and see what happens.
I think it's related to how it draws the "activity graph", which stopped working w/ this version also. Even though it's obfuscated, we could run VisualVM and see if it's the same object/method calls eating up CPU. Granted, in my case, it was all the GUI...
are you running the server with our without the server GUI?
I've got a vanilla 1.7.2 server on Windows 8.1 x64. Core i5 machine w/ 16GB of ram and MC sitting on a fast SSD. The java process would consume 25-50% CPU (it was lower when the world was first created) when idle and more when a few clients were connected.
The higher the CPU load, the more "can't keep up" messages. Sometimes it would spike to 80-100% CPU, but it'd typically drop again after a few minutes.
Last night I added the NOGUI option to my startup command... wow... night/day. When I looked at it this morning, the machine was idling at 1-2% CPU. As users played last night, I still saw some of these warnings in the log, but I think it was only when they were exploring new areas.
Given that the GUI for the windows EXE doesn't even work, this isn't too surprising. Could be related to it trying to draw the activity/load graph... which off-hand, I can't remember if that was visible w/ 1.7.2?
It's possible this started with 1.6.x and was complicating the other "zombie pathfinding lag" issue.
curious, are you running the server with or without the GUI?
So do you think this is related to the "nogui" issue you posted after this one? It looks like MC-39078 was deleted? but I saw the cached version where you said setting the nogui reduced the CPU down to 1-2%. I'm having similar issues... CPU usage on an idle server (no clients, hour+ after last person disco'd) hovers from 25 - 45% on a 4-core 3.4ghz i5 processor. CPU load appears evenly distributed across all 4 cores. Running VisualVM shows the largest time consumer is some javax.swing.timer call (or DoPostEvents or something like that, don't have it in front of me)
I'm not sure about client/server lag yet, but so far, 1.7.2 appears to consume more server CPU cycles. One client w/ a large chicken farm was causing 90% CPU (4-core i5 chip @ 3.4ghz) w/ 2clients connected. Haven't tested zombie pathing yet...
Console appears the same for me. Sending a /stop command still appeared to work & clients can connect just fine. Server's log file wasn't being written to, so maybe that changed as well... not sure yet.
I was able to slightly alleviate this issue by lighting & walling-off one of the closer villages, then putting a lava trap at the only entrance. This seems to keep the zombie count in-check, although some get stuck UNDER the village and never follow a clear path to the surface. To handle this, I tried to block off any underground paths. I've been logging server CPU utilization and it goes up more slowly relative to MC server uptime than before.
Talven, by votes, this is ranked #4 out of 2,455 open issues, so there's no doubt the DEVs are aware of it. I've got a feeling most people are more annoyed by the lack of acknowledgement rather than the bug itself. Simply shifting it from "open" to "in progress" and/or assigning it to somebody would be a nice gesture to the server admins that are forced to spend their time dealing with it.
just updated to 14w20b, will try to confirm. Idle CPU usage appears to be up vs. 14w11b. The GUI in windows still causes even more cpu utilization, but running with NOGUI helps... I seem to idle between 6 and 15% CPU, but it appears to be related to how the CPU is self-throttling. ie: it lowers it's clock speed, load goes up, runs at full speed again for a second, then it drops again. Rinse & repeat.