Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id D5ADE200C16 for ; Thu, 9 Feb 2017 19:39:49 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id D44ED160B50; Thu, 9 Feb 2017 18:39:49 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 2B089160B4B for ; Thu, 9 Feb 2017 19:39:49 +0100 (CET) Received: (qmail 99620 invoked by uid 500); 9 Feb 2017 18:39:48 -0000 Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list common-issues@hadoop.apache.org Received: (qmail 99609 invoked by uid 99); 9 Feb 2017 18:39:48 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Feb 2017 18:39:48 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id E2049C05D7 for ; Thu, 9 Feb 2017 18:39:47 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, KAM_LAZY_DOMAIN_SECURITY=1, RP_MATCHES_RCVD=-2.999] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id qtJdjxoG15VS for ; Thu, 9 Feb 2017 18:39:47 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id 987965FC61 for ; Thu, 9 Feb 2017 18:39:46 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 67779E0526 for ; Thu, 9 Feb 2017 18:39:42 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id C766A21D69 for ; Thu, 9 Feb 2017 18:39:41 +0000 (UTC) Date: Thu, 9 Feb 2017 18:39:41 +0000 (UTC) From: "Kihwal Lee (JIRA)" To: common-issues@hadoop.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Comment Edited] (HADOOP-14033) Reduce fair call queue lock contention MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Thu, 09 Feb 2017 18:39:50 -0000 [ https://issues.apache.org/jira/browse/HADOOP-14033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15859967#comment-15859967 ] Kihwal Lee edited comment on HADOOP-14033 at 2/9/17 6:39 PM: ------------------------------------------------------------- Is it possible to add a meaningful metrics to show how reader threads (producer) are doing? was (Author: kihwal): Is it possible to add a meaningful metrics to show how readers are doing? > Reduce fair call queue lock contention > -------------------------------------- > > Key: HADOOP-14033 > URL: https://issues.apache.org/jira/browse/HADOOP-14033 > Project: Hadoop Common > Issue Type: Sub-task > Components: ipc > Affects Versions: 2.7.0 > Reporter: Daryn Sharp > Assignee: Daryn Sharp > Attachments: HADOOP-14033.patch > > > Under heavy load the call queue may run dry yet clients experience high latency. > The fcq requires producers and consumers to sync via a shared lock. Polling consumers hold the lock while scanning all sub-queues. Consumers are serialized despite the sub-queues being thread-safe blocking queues. The effect is to cause other producers/consumers to frequently park. > The lock is unfair, so producers/consumers attempt to barge in on the lock. The outnumbered producers tend to remain blocked for an extended time. As load increases and the queues fill, the barging consumers drain the queues faster than the producers can fill it. > Server metrics provide an illusion of healthy throughput, response time, and call queue length due to starvation on the ingress. Often as the load gets worse, the server looks better. -- This message was sent by Atlassian JIRA (v6.3.15#6346) --------------------------------------------------------------------- To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org For additional commands, e-mail: common-issues-help@hadoop.apache.org