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 E841D200CA4 for ; Wed, 7 Jun 2017 15:46:47 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id E6E6C160BD0; Wed, 7 Jun 2017 13:46:47 +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 138A2160BB6 for ; Wed, 7 Jun 2017 15:46:46 +0200 (CEST) Received: (qmail 16435 invoked by uid 500); 7 Jun 2017 13:46:44 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 16421 invoked by uid 99); 7 Jun 2017 13:46:44 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Jun 2017 13:46:44 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id EAF36D023F for ; Wed, 7 Jun 2017 13:46:43 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.879 X-Spam-Level: * X-Spam-Status: No, score=1.879 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id q0sQzXbupKbZ for ; Wed, 7 Jun 2017 13:46:43 +0000 (UTC) Received: from mail-it0-f41.google.com (mail-it0-f41.google.com [209.85.214.41]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 589005F39D for ; Wed, 7 Jun 2017 13:46:42 +0000 (UTC) Received: by mail-it0-f41.google.com with SMTP id r63so6869036itc.1 for ; Wed, 07 Jun 2017 06:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=k5XnZx2NZpjzU6NyvOzLGKFnUkTwLeTqSS2tEkGXLVg=; b=O40bnvDnSiBtt39JzNLLb1r1guy1Kq0u9dNSf1U2tKR0RIXq5xuwJbAE+aR1Yl9xR3 m6iDL0VcYYCKoqtNXmZx7Wb46kJ7PMC6ZvnoEnMjXdBZ3zX0Fu2/lCxlFzQXKC0gPYZU /OXB1kyHWmjN3MJu5yPK6cVNpEDhOl0ecTT5AD0oL3SUYjdHM+0IEeMewODiyFiJRZZH kXH8u3sXWsEB7EahnT+durpmSJvEyItZd4elbXPkFv6kNQrn452XGWK8LBSLm4hVqA2O zm2iyNlInSInj4oQhZuixJ+U1UjlFCNsm45WO6xxWcYTwratWXiFb6EINGdV2WN7/NQO VvDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=k5XnZx2NZpjzU6NyvOzLGKFnUkTwLeTqSS2tEkGXLVg=; b=pTHv4tnRWEqXrrvA56HZsaUev8EQbjcL8cKfndRMMbgZWk4pSNDVp5YAzxCrHqxue2 uumxZVN0rS6wyiZBgVnWqnsADS6mMCAZQVaRzPrFQKs6ySMeNqs0NYJWiffuGc1v0Px6 CM2PhAR8ntLFz4wRHb99K4aRekxrsEOvn9SgeGl3zbTVchBCy5Q7olriTDqdm5RuyOIh uBe8CfFj7B9R8AwGb/sQWhl5HYqYJAGhV478zXpUAFBHLZlruGG661yluJZm5OcvuZpq SCi98e8TBtFje4r1CHWMFfNnxzVjSizuFQpopZpczwOX0GjG8IYlXsXIGqEHW75Lmf1y znAA== X-Gm-Message-State: AODbwcBVKOMZUooAa/G6Fv5H0vaA3Uc90j3bIMrbv4zQv/6A8o9kSE7W G0cVpFPON9gw8dXxYU/l2DAwWTjHJw== X-Received: by 10.36.46.210 with SMTP id i201mr1855516ita.77.1496843201152; Wed, 07 Jun 2017 06:46:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.72.134 with HTTP; Wed, 7 Jun 2017 06:46:40 -0700 (PDT) In-Reply-To: <5E89C64C-E616-4061-9C67-290424944028@canoga.com> References: <97EB699F861AD841B5908C7CA9C9565604A103BDD587@VSERVER1.canoga.com> <5E89C64C-E616-4061-9C67-290424944028@canoga.com> From: Bryan Pendleton Date: Wed, 7 Jun 2017 06:46:40 -0700 Message-ID: Subject: Re: Could use some thoughts on a problem with a query in production To: derby-dev@db.apache.org Content-Type: multipart/alternative; boundary="001a114a9b084a138105515ef70f" archived-at: Wed, 07 Jun 2017 13:46:48 -0000 --001a114a9b084a138105515ef70f Content-Type: text/plain; charset="UTF-8" Hi Brett, Cache cleaning in general is a very I/O intensive activity, so I agree that it is odd that your system appeared to be CPU busy during that time. It's interesting that whatever it was, persisted for such a long time. In the past, I have developed small operator scripts which collect system information, which can be run by a simple monitoring tool and can keep a history about the observations they make. If you were to build and install such a monitoring system, you might be able to develop more clues about the "larger picture" of activity on your machine during that time period. Sorry to be so vague and non-specific, but I find that retrospective analysis of problems like this is VERY challenging. Often, the best you can do is: 1) Try to figure out some way to make the problem happen on demand, so you can cause it and observe it. 2) Instrument everything, and ensure you are preserving a history of your instrumentation recordings, so that you can have a mountain of detail when those rare events occur. It strikes me as being like high-energy physics, where your experiment generates volumes of data, and it takes weeks or months of analysis afterward to figure out what actually occurred. Not that I'm much good at high-energy physics, either, I'm afraid. :) bryan --001a114a9b084a138105515ef70f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Brett,

Cache cleaning in general i= s a very I/O intensive activity, so I agree that it is odd that your system= appeared to be CPU busy during that time.
=
It's interesting that whatever it = was, persisted for such a long time.

In the past, I have developed small operator= scripts which collect system information, which can be run by a simple mon= itoring tool and can keep a history about the observations they make.
=

If you were= to build and install such a monitoring system, you might be able to develo= p more clues about the "larger picture" of activity on your machi= ne during that time period.

Sorry to be so vague and non-specific, but I find tha= t retrospective analysis of problems like this is VERY challenging.

Often, the be= st you can do is:
1) Try to figure out some= way to make the problem happen on demand, so you can cause it and observe = it.
2) Instrument everything, and ensure yo= u are preserving a history of your instrumentation recordings, so that you = can have a mountain of detail when those rare events occur.

It strikes me as bein= g like high-energy physics, where your experiment generates volumes of data= , and it takes weeks or months of analysis afterward to figure out what act= ually occurred.

Not that I'm much good at high-energy physics, either, I'= m afraid. :)

bryan

--001a114a9b084a138105515ef70f--