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 E4E23E157 for ; Wed, 9 Jan 2013 19:45:56 +0000 (UTC) Received: (qmail 83342 invoked by uid 500); 9 Jan 2013 19:45:56 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 83318 invoked by uid 500); 9 Jan 2013 19:45:56 -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 83309 invoked by uid 99); 9 Jan 2013 19:45:56 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 09 Jan 2013 19:45:56 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL,UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [216.82.243.50] (HELO mail1.bemta8.messagelabs.com) (216.82.243.50) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 09 Jan 2013 19:45:46 +0000 Received: from [216.82.241.132:55761] by server-13.bemta-8.messagelabs.com id 40/08-09384-4D8CDE05; Wed, 09 Jan 2013 19:45:24 +0000 X-Env-Sender: pbortnovskiy@jefferies.com X-Msg-Ref: server-12.tower-45.messagelabs.com!1357760724!33570796!1 X-Originating-IP: [169.196.176.53] X-StarScan-Received: X-StarScan-Version: 6.6.1.8; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14340 invoked from network); 9 Jan 2013 19:45:24 -0000 Received: from mail1.jefferies.com (HELO mail1.jefferies.com) (169.196.176.53) by server-12.tower-45.messagelabs.com with AES256-SHA encrypted SMTP; 9 Jan 2013 19:45:24 -0000 Received: from EXJSQUSDAG01.ad.jefco.com (10.162.114.41) by EXJSQEDGE01.dmz.jefco.local (10.162.35.67) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 9 Jan 2013 14:45:24 -0500 Received: from EXJSQUSDAG04.ad.jefco.com ([169.254.4.79]) by EXJSQUSDAG01.ad.jefco.com ([169.254.1.113]) with mapi id 14.01.0355.003; Wed, 9 Jan 2013 14:45:23 -0500 From: Pavel Bortnovskiy To: Derby Discussion Subject: RE: CPU Utilization Thread-Topic: CPU Utilization Thread-Index: Ac3tEBirEF1gJXcdTiqeoJYzAmZXIABuyQqAAApp5mA= Date: Wed, 9 Jan 2013 19:45:23 +0000 Message-ID: <619F13B2042F204E8E8E93D73870255809E29A83@EXJSQUSDAG04.ad.jefco.com> References: <619F13B2042F204E8E8E93D73870255809E2313F@EXJSQUSDAG06.ad.jefco.com> <50EDC7ED.6020508@oracle.com> In-Reply-To: <50EDC7ED.6020508@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.93.34] Content-Type: multipart/alternative; boundary="_000_619F13B2042F204E8E8E93D73870255809E29A83EXJSQUSDAG04adj_" MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org --_000_619F13B2042F204E8E8E93D73870255809E29A83EXJSQUSDAG04adj_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you, Kristian, for your quick response. How can I diagnose this and determine what Derby is doing during the period= s of high CPU utilization? As far as I can determine from watching the log and the "top" simultaneousl= y, it seems that utilization peeks when data are accessed. In other words, the query itself seems to run very fast, but accessing the = data (with the JDBC's ResultSet) seems to peek the CPU usage. P. From: Kristian Waagan [mailto:kristian.waagan@oracle.com] Sent: Wednesday, January 09, 2013 2:42 PM To: derby-user@db.apache.org Subject: Re: CPU Utilization On 07.01.2013 20:51, Pavel Bortnovskiy wrote: Hello: This is more of a general question. Our application uses Derby in the in-me= mory mode only. When the application is configured to use complex queries, such configurati= on causes CPU utilization (on the Linux server) to go as high as 300% or ev= en higher. Using simpler queries don't seem to lead to such high utilizatio= n. 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 specifical= ly for the in-memory back end. Since this is in-memory, the latency associated with page operations is ver= y low. Do you know if Derby is using the CPU for something useful (i.e. pro= cessing 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 add= ressee of this email you may not copy, forward, disclose or otherwise use i= t or any part of it in any form whatsoever. This email may be produced at t= he request of regulators or in connection with civil litigation. Jefferies = accepts no liability for any errors or omissions arising as a result of tra= nsmission. Use by other than intended recipients is prohibited. In the Unit= ed Kingdom, Jefferies operates as Jefferies International Limited; register= ed in England: no. 1978621; registered office: Vintners Place, 68 Upper Tha= mes Street, London EC4V 3BJ. Jefferies International Limited is authorised = and regulated by the Financial Services Authority. 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 add= ressee of this email you may not copy, forward, disclose or otherwise use i= t or any part of it in any form whatsoever. This email may be produced at t= he request of regulators or in connection with civil litigation. Jefferies = accepts no liability for any errors or omissions arising as a result of tra= nsmission. Use by other than intended recipients is prohibited. In the Unit= ed Kingdom, Jefferies operates as Jefferies International Limited; register= ed in England: no. 1978621; registered office: Vintners Place, 68 Upper Tha= mes Street, London EC4V 3BJ. Jefferies International Limited is authorised = and regulated by the Financial Services Authority. --_000_619F13B2042F204E8E8E93D73870255809E29A83EXJSQUSDAG04adj_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you, Kristian, f= or your quick response.

 

How can I diagnose thi= s and determine what Derby is doing during the periods of high CPU utilizat= ion?

As far as I can determ= ine from watching the log and the “top” simultaneously, it seem= s that utilization peeks when data are accessed.

In other words, the qu= ery itself seems to run very fast, but accessing the data (with the JDBC= 217;s ResultSet) seems to peek the CPU usage.

 

P.

 

From: Kristian Waagan [mailto:kristian.waagan@oracl= e.com]
Sent: Wednesday, January 09, 2013 2:42 PM
To: derby-user@db.apache.org
Subject: Re: CPU Utilization

 

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 qu= eries, such configuration causes CPU utilization (on the Linux server) to g= o 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 specifical= ly for the in-memory back end.

Since this is in-memory, the latency associated with page operations is ver= y low. Do you know if Derby is using the CPU for something useful (i.e. pro= cessing 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 add= ressee 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 c= onnection with civil litigation. Jefferies accepts no liability for any err= ors or omissions arising as a result of transmission. Use by other than intended recipients is prohibited. In t= he United Kingdom, Jefferies operates as Jefferies International Limited; r= egistered in England: no. 1978621; registered office: Vintners Place, 68 Up= per Thames Street, London EC4V 3BJ. Jefferies International Limited is authorised and regulated by the Financi= al Services Authority.

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 add= ressee 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 c= onnection with civil litigation. Jefferies accepts no liability for any err= ors or omissions arising as a result of transmission. Use by other than intended recipients is prohibited. In t= he United Kingdom, Jefferies operates as Jefferies International Limited; r= egistered in England: no. 1978621; registered office: Vintners Place, 68 Up= per Thames Street, London EC4V 3BJ. Jefferies International Limited is authorised and regulated by the Financi= al Services Authority.
--_000_619F13B2042F204E8E8E93D73870255809E29A83EXJSQUSDAG04adj_--