funky-eyes commented on code in PR #8205:
URL: https://github.com/apache/incubator-seata/pull/8205#discussion_r3818405235
##########
core/src/main/java/org/apache/seata/core/rpc/netty/AbstractNettyRemotingClient.java:
##########
@@ -587,6 +587,20 @@ public void run() {
while (true) {
mergeLock.lock();
try {
+ // Park until there are pending messages, so the merge
thread no longer
+ // burns CPU with a 1ms polling cycle when idle. The
check-and-wait is
+ // atomic under mergeLock and producers offer to the
basket before
+ // signalling (see sendSyncRequest), so no wake-up can be
lost.
+ while (isBasketEmpty()) {
+ isSending = false;
+ mergeCondition.await();
Review Comment:
With this approach, whenever a message arrives, the processing thread waits
for up to another 1 ms. Why is this additional delay necessary?
With the implementation you’re currently using, consider the case where only
a single message arrives: it wakes up the thread, but the thread then waits for
another 1 ms before sending the message. This effectively adds about 1 ms to
the request latency.
I don’t think an `await` of 1 ms alone should cause such high CPU usage.
Could the high CPU utilization be related to Arthas being enabled? Given the
performance of modern CPUs, 1,000 wake-ups per second that do essentially no
work should not normally be enough to consume around 30% CPU.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
