I dig into Tomcat source code and from what I've seen this is what happens:
Tomcat "worker thread", tries the polls the work and if it doesn't succeed it invokes sun.misc.Unsafe.park (that's waiting which can be interrupted by another thread), internally in Linux goes through kernel function FUTEX_WAIT (futex definition is " The futex() system call provides a method for waiting until a certain condition becomes true." However, these futex_wait functions sums to top CPU load, although I don't find it's actually load here, as per infamous Linux change of 29 Oct 1993 by Matthias Urlichs: http://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html On Tue, Nov 26, 2019 at 4:50 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Mladen, > > On 11/25/19 14:36, Mladen Adamović wrote: > > On Mon, Nov 25, 2019 at 5:57 PM Christopher Schultz < > > ch...@christopherschultz.net> wrote: > > > >>> We certainly want to be able to serve 10000 hits per second > >>> (!), while some connections might be stalled. > >> > >> What might stall a connection? The network, or the application > >> (or database, etc.)? > >> > > > > Underlying (synchronized) monitors could stall every thread, the > > network, whatever. > > > > The network itself demands a large number of connection, i.e. > > current situation at the server (displaying only remove > > connections): > > > > root@condor1796 ~ # netstat -tnp | grep -v "127.0.0" | wc -l 1220 > > Note this is every connection, bound port, and cleanup connection the > kernel knows about ; not just established/active connections to your > application specifically. > > > If we now have 1220, we definitely need at least 10000 active > > connections for Tomcat and I don't see that setting this to 50000 > > is a bad idea. > > Okay. I think you need a reverse proxy and more servers if you think > 50000 is going to be your peak load. > > >> For real DDOS protection, you need a provider who can handle lots > >> of traffic and respond quickly by black-holing that kind of > >> traffic as > > > > Depending on how large server farm they use (hypothetically). We > > want to be able to survive some DDoS attacks. If we limit the > > number of concurrent connections by IP address and the number of > > connections per second, that's some DoS protection. > > But honestly, this is better done at another layer of the network; not > at the host-level. > > > Regarding network delays, out of currently 1220 active remove > > connections, most of them are in TIME_WAIT state. Lowering > > TIME_WAIT settings in Linux are not recommended. > > Hmm. Lots of TIME_WAIT connections isn't good. I actually don't know > if they count "against" your 50000 limit in the Java process. > > - -chris > -----BEGIN PGP SIGNATURE----- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3dSaUACgkQHPApP6U8 > pFhStRAArIHBU4UT6cw5jS7ys6aRlYpaxw4lJ1lhRA9WB5U7/bG+qnZlai6052X7 > MPrfjP8ZlNMugVwhHjMnY3iijfWT2K6bkd8WILT3gcu/ZSqwz2tr9QYru40zG/Bu > FHHlmoUwfWkUrwphJUgwvp1VsIU3exdG28LDlnGjjp1JmgALd7/KeBmS98kpSyKR > Dot/7tlW98Y9DaPOnOnwkWO/MIZLEuekjBRRgZcYr6OpY+9s0hRP/RJ8uEpSfOgA > +ZCvqrjR3MR26gbap9o6zBsZzI+tjFjH9YteAHkxAOmzU+ztiCoIRj6SA4LJErgT > z53yqxpVRszbWmJod3P7sphHJ+r2dmvf0iOEV4qbkBAYF2vP8wsV3jY/7B68OfNh > 6sSC9CWTg7l0wYzxFLrSVQqIt7WV4BBX/4yH9fQ72jHs8Qd5uIJoDbD5GJ1HW32E > viGpzg9/dlXxsRisow7wdKOFC+wTtWeoyDasMZqgdf+SofSTK1qGF/sR0n866dM3 > I1Rz8E0cVZKADtDrjkUK4BMTExfX0rS2WdpwqWOykvTOA9wvW5IzMfokblMQ1XxG > ctnIJA4sRfFwFmnQVu7ew0Ryu3P3tLzaXE7CqfveOgqu/YLi/9gwbvmSB0x0UGsk > YHepLdZ+CwB1vo0fTn0kVKf+anVoAq3xOguPB69gnBZwmsK4v6g= > =Pk1p > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
