Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id EF4F817BCE for ; Fri, 24 Oct 2014 17:37:04 +0000 (UTC) Received: (qmail 44926 invoked by uid 500); 24 Oct 2014 17:37:02 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 44894 invoked by uid 500); 24 Oct 2014 17:37:02 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 44884 invoked by uid 99); 24 Oct 2014 17:37:02 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 24 Oct 2014 17:37:02 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of dvankley@salesforce.com designates 209.85.218.47 as permitted sender) Received: from [209.85.218.47] (HELO mail-oi0-f47.google.com) (209.85.218.47) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 24 Oct 2014 17:36:56 +0000 Received: by mail-oi0-f47.google.com with SMTP id a141so670536oig.6 for ; Fri, 24 Oct 2014 10:35:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=PaY9uwtNW/Fw8dGQJtGKMlnmLDvtAzgHL1itDgy/JKA=; b=Iw7r1XcG1UTcLaYbAhRJ72fWVh3uXQHuOqYhcrA24aizdOPK3nq74nKq2tv19ojn9o IQhSlrQwjoSk5PCVTpufbFeA6cYRN5M+K0G6TBQeNwsfL2LhABdzCZP+Vlhx2BW3O7PH WsYY0rKyAorUevgCS00nfJTQu7J95BrCcr0OmJfU2aHeRNQPjJ4/BwwBWHmPlbuz/Kxp Gx4VygEP4/9MqoqTViFSfM2evxRT0IfeH5Ww8F+5tfNuMn7PmFQX1G6TdxEm/YB3NHLK F41uv5r4PS6y18UvLNAWPk2Eb7vg+KFGRML3D+ja4bC3lRbU7svJhVRLYT6yLyCP3Xlf r3pg== X-Gm-Message-State: ALoCoQnyLjxZ4EEPTlM1eJiyagQwgRbmJJt7i7jSCHyv2bMillRPODSHdNQJwI2mGhXEW+kvat+P MIME-Version: 1.0 X-Received: by 10.60.78.106 with SMTP id a10mr4809037oex.21.1414172105301; Fri, 24 Oct 2014 10:35:05 -0700 (PDT) Received: by 10.76.98.166 with HTTP; Fri, 24 Oct 2014 10:35:05 -0700 (PDT) Date: Fri, 24 Oct 2014 13:35:05 -0400 Message-ID: Subject: Re: Intermittent long application pauses on nodes From: Dan van Kley To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=089e0111de2afd135005062e9963 X-Virus-Checked: Checked by ClamAV on apache.org --089e0111de2afd135005062e9963 Content-Type: text/plain; charset=UTF-8 I'm also curious to know if this was ever resolved or if there's any other recommended steps to take to continue to track it down. I'm seeing the same issue in our production cluster, which is running Cassandra 2.0.10 and JVM 1.7u71, using the CMS collector. Just as described above, the issue is long "Total time for which application threads were stopped" pauses that are not a direct result of GC pauses (ParNew, initial mark or remark). When I enabled the safepoint logging I saw the same result, long "sync" pause times with short spin and block times, usually with the "RevokeBias" description. We're seeing pause times sometimes in excess of 10 seconds, so it's a pretty debilitating issue. Our machines are not swapping (or even close to it) or having other load issues when these pauses occur. Any ideas would be very appreciated. Thanks! --089e0111de2afd135005062e9963 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm also curious to know if this was ever resolved or = if there's any other recommended steps to take to continue to track it = down. I'm seeing the same issue in our production cluster, which is run= ning Cassandra 2.0.10 and JVM 1.7u71, using the CMS collector. Just as desc= ribed above, the issue is long "Total time for which application threa= ds were stopped" pauses that are not a direct result of GC pauses (Par= New, initial mark or remark). When I enabled the safepoint logging I saw th= e same result, long "sync" pause times with short spin and block = times, usually with the "RevokeBias" description. We're seein= g pause times sometimes in excess of 10 seconds, so it's a pretty debil= itating issue. Our machines are not swapping (or even close to it) or havin= g other load issues when these pauses occur. Any ideas would be very apprec= iated. Thanks!
--089e0111de2afd135005062e9963--