From derby-user-return-14840-apmail-db-derby-user-archive=db.apache.org@db.apache.org Wed Jan 9 19:42:08 2013 Return-Path: X-Original-To: apmail-db-derby-user-archive@www.apache.org Delivered-To: apmail-db-derby-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 E79A7E12D for ; Wed, 9 Jan 2013 19:42:08 +0000 (UTC) Received: (qmail 66467 invoked by uid 500); 9 Jan 2013 19:42:08 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 66431 invoked by uid 500); 9 Jan 2013 19:42:08 -0000 Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Discussion" Delivered-To: mailing list derby-user@db.apache.org Received: (qmail 66413 invoked by uid 99); 9 Jan 2013 19:42:08 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 09 Jan 2013 19:42:08 +0000 X-ASF-Spam-Status: No, hits=1.9 required=5.0 tests=FSL_NEW_HELO_USER,HTML_MESSAGE,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of kristian.waagan@oracle.com designates 156.151.31.81 as permitted sender) Received: from [156.151.31.81] (HELO userp1040.oracle.com) (156.151.31.81) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 09 Jan 2013 19:41:59 +0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r09Jfb6Z003890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 9 Jan 2013 19:41:38 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r09Jfbv7006960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 9 Jan 2013 19:41:37 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r09Jfbuj007529 for ; Wed, 9 Jan 2013 13:41:37 -0600 Received: from [192.168.1.238] (/84.215.144.124) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 09 Jan 2013 11:41:36 -0800 Message-ID: <50EDC7ED.6020508@oracle.com> Date: Wed, 09 Jan 2013 20:41:33 +0100 From: Kristian Waagan Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: derby-user@db.apache.org Subject: Re: CPU Utilization References: <619F13B2042F204E8E8E93D73870255809E2313F@EXJSQUSDAG06.ad.jefco.com> In-Reply-To: <619F13B2042F204E8E8E93D73870255809E2313F@EXJSQUSDAG06.ad.jefco.com> Content-Type: multipart/alternative; boundary="------------030808040203000202080407" X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Virus-Checked: Checked by ClamAV on apache.org This is a multi-part message in MIME format. --------------030808040203000202080407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 07.01.2013 20:51, Pavel Bortnovskiy wrote: > > Hello: > > This is more of a general question. Our application uses Derby in the > in-memory mode only. > > When the application is configured to use complex queries, such > configuration causes CPU utilization (on the Linux server) to go as > high as 300% or even higher. Using simpler queries don't seem to lead > to such high utilization. Is there any way to control or lower CPU > utilization by Derby? > Hi Pavel, I don't believe there is such a mechanism in place, at least not specifically for the in-memory back end. Since this is in-memory, the latency associated with page operations is very low. Do you know if Derby is using the CPU for something useful (i.e. processing queries effectively), or is the CPU spent on wasteful activities? One potential wasteful activity is moving data back and forth from the page cache (page cache too small?). Is this a highly concurrent scenario? Regards, -- Kristian > Thank you, > Pavel. > > > > Jefferies archives and monitors outgoing and incoming > e-mail. The contents of this email, including any > attachments, are confidential to the ordinary user of the > email address to which it was addressed. If you are not > the addressee of this email you may not copy, forward, > disclose or otherwise use it or any part of it in any form > whatsoever. This email may be produced at the request of > regulators or in connection with civil litigation. > Jefferies accepts no liability for any errors or omissions > arising as a result of transmission. Use by other than > intended recipients is prohibited. In the United Kingdom, > Jefferies operates as Jefferies International Limited; > registered in England: no. 1978621; registered office: > Vintners Place, 68 Upper Thames Street, London EC4V 3BJ. > Jefferies International Limited is authorised and > regulated by the Financial Services Authority. > --------------030808040203000202080407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 07.01.2013 20:51, Pavel Bortnovskiy wrote:

Hello:

 

This is more of a general question. Our application uses Derby in the in-memory mode only.

When the application is configured to use complex queries, such configuration causes CPU utilization (on the Linux server) to go as high as 300% or even higher. Using simpler queries don’t seem to lead to such high utilization. Is there any way to control or lower CPU utilization by Derby?


Hi Pavel,

I don't believe there is such a mechanism in place, at least not specifically for the in-memory back end.

Since this is in-memory, the latency associated with page operations is very low. Do you know if Derby is using the CPU for something useful (i.e. processing queries effectively), or is the CPU spent on wasteful activities?
One potential wasteful activity is moving data back and forth from the page cache (page cache too small?).
Is this a highly concurrent scenario?


Regards,
--
Kristian
 

 

Thank you,
Pavel.


Jefferies archives and monitors outgoing and incoming e-mail. The contents of this email, including any attachments, are confidential to the ordinary user of the email address to which it was addressed. If you are not the addressee of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. This email may be produced at the request of regulators or in connection with civil litigation. Jefferies accepts no liability for any errors or omissions arising as a result of transmission. Use by other than intended recipients is prohibited. In the United Kingdom, Jefferies operates as Jefferies International Limited; registered in England: no. 1978621; registered office: Vintners Place, 68 Upper Thames Street, London EC4V 3BJ. Jefferies International Limited is authorised and regulated by the Financial Services Authority.
--------------030808040203000202080407--