I'd also monitor /proc/interrupts and /proc/softirqs for your target cpu On Thu, 13 Apr 2017, 08:36 Gil Tene, <[email protected]> wrote:
> If I read this right. You are running this on localhost (according to SO > code). If that's the case, there is no actual network, and no actual TCP > stack... UDP or TCP won't make a difference then, and neither will any TCP > tweaking. I think this rules out the network, the switch, the NICs, and > most of the OS's network stack. > > Now you're looking at the JVM, the OS scheduling, power management, cache > behavior, etc. > > Some more things to play with to rule out or find some insight: > > - Rule out de-optimization (you may be de-optimizing when the if > (totalMessagesSent == WARMUP) triggers). Do this by examining at > -XX:+PrintCompilation output > > - Rule out scheduling and cpu migration effects: use isolcpus and pin your > processes to specific cores > > - How do you know that your actually disabled all power management. I'd > monitor cstate and pstate to see what they actually are over time. > Cool anecdote: We once had a case where something in the system was > mysteriously elevating cstate away from 0 after we set to to 0. We never > did find out what it was. The case was "resolved" with a cron job that set > cstate to 0 every minute (yuck. I know). > > - Slew with different interval time in your tests to find out how long the > interval needs to be before you see the perf drop. The value at which this > effect starts may be an interesting hint > > > On Wednesday, April 12, 2017 at 12:56:22 PM UTC-7, J Crawford wrote: >> >> The SO question has the source codes of a simple server and client that >> demonstrate and isolate the problem. Basically I'm timing the latency of a >> ping-pong (client-server-client) message. I start by sending one message >> every 1 millisecond. I wait for 200k messages to be sent so that the >> HotSpot has a chance to optimize the code. Then I change my pause time from >> 1 millisecond to 30 seconds. For my surprise my write and read operation >> become considerably slower. >> >> I don't think it is a JIT/HotSpot problem. I was able to pinpoint the >> slower method to the native JNI calls to write (write0) and read. Even if I >> change the pause from 1 millisecond to 1 second, problem persists. >> >> I was able to observe that on MacOS and Linux. >> >> Does anyone here have a clue of what can be happening? >> >> Note that I'm disabling Nagle's Algorithm with setTcpNoDelay(true). >> >> SO question with code and output: >> http://stackoverflow.com/questions/43377600/socketchannel-why-if-i-write-msgs-quickly-the-latency-of-each-message-is-low-b >> >> Thanks! >> >> -JC >> > -- > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
