Return-Path: X-Original-To: oracle-l@orafaq.com Delivered-To: oracle-l@orafaq.com Received: from puck1183.startdedicated.com (localhost [127.0.0.1]) by puck1183.startdedicated.com (Postfix) with ESMTP id 2CA2A19605C4 for ; Thu, 6 Jun 2013 18:22:45 +0200 (CEST) Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180]) by puck1183.startdedicated.com (Postfix) with ESMTP for ; Thu, 6 Jun 2013 18:22:45 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 6453D22BF2; Thu, 6 Jun 2013 12:09:34 -0400 (EDT) Authentication-Results: turing.freelists.org; dkim=fail (verification failed; insecure key) header.i=@gmail.com; dkim-adsp=none (insecure policy) X-Virus-Scanned: Debian amavisd-new at turing.freelists.org Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfhExoizO6xo; Thu, 6 Jun 2013 12:09:34 -0400 (EDT) Received: from turing.freelists.org (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 29A0321729; Thu, 6 Jun 2013 12:08:53 -0400 (EDT) Received: with ECARTIS (v1.0.0; list oracle-l); Thu, 06 Jun 2013 12:08:12 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 23DB222DAD for ; Thu, 6 Jun 2013 12:08:12 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFhlAC8Zo1tb for ; Thu, 6 Jun 2013 12:08:12 -0400 (EDT) Received: from mail-ve0-f169.google.com (mail-ve0-f169.google.com [209.85.128.169]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id EA69A22DA6 for ; Thu, 6 Jun 2013 12:08:11 -0400 (EDT) Received: by mail-ve0-f169.google.com with SMTP id m1so2385024ves.28 for ; Thu, 06 Jun 2013 09:21:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=i94PQpWY144sk6BYGIRG+f7bT6iegGSke5MhJ7yH0PI=; b=A8gxlphrGjHYQY+T0Ytoz7v4aLQUK5iEqV7wMJgMRBYnTM6miKeUtvMMImbFTTBmSz Jq/IqXF6P5u2blnb98Q+FScnOToX2VlhwcifxipzglFevuGQEFa5wSCx4b2Sv6ugfrFc oxzM36KWg4+Sgk1Zuci/duT8bXoZ+acnCbDsJr1U9bvHEFTA9tCnD6ru28CCLiOlThTX /d5CTh9Q5ykLDkIFxZ8ggSuUpJxq0LBND8TxWXXDQu6gDCGVkuS7+FlK3X//QMg+L5DM FKhAMhDwX5/Je/201kKQCTKKw6EFYkbfACjQZUVO3OGvgsDNqpNB6go9lY0yWFWqARTk 3zsg== MIME-Version: 1.0 X-Received: by 10.58.255.199 with SMTP id as7mr6028138ved.23.1370535679732; Thu, 06 Jun 2013 09:21:19 -0700 (PDT) Received: by 10.58.145.169 with HTTP; Thu, 6 Jun 2013 09:21:19 -0700 (PDT) In-Reply-To: References: <8ab340b6a74fc4f8f3cf3f53011721dc.squirrel@society.servebeer.com> Date: Thu, 6 Jun 2013 17:21:19 +0100 Message-ID: Subject: Re: Transparent HugePages causing crashes? From: Niall Litchfield To: "rjoralist2@society.servebeer.com" Cc: ORACLE-L Content-type: text/plain Content-Transfer-Encoding: 8bit X-archive-position: 49209 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: niall.litchfield@gmail.com Precedence: normal Reply-To: niall.litchfield@gmail.com List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: oracle-l X-List-ID: oracle-l List-subscribe: List-owner: List-post: List-archive: X-list: oracle-l I think the fact that Kevin Closson also sees a significant performance hit for Greenplum workload suggests that it might be well worth taking care with this feature on heavy data processing (of whatever variety) workloads On Thu, Jun 6, 2013 at 5:04 PM, Rich Jesse wrote: > Karl writes: > > > have you seen this blog? > > > http://structureddata.org/2012/06/18/linux-6-transparent-huge-pages-and-hadoop-workloads/ > > Now we're getting somewhere! But does Hadoop allocate memory like Oracle > does for it's SGA (assuming PGA will not use THP)? In other words, would a > statically-sized SGA be subject to the THP defrag? > > Greg's article is great, but I still question if disabling THP defrag would > solve the issue, as he has no performance stats specific to it. > > At this point, I see enough of a risk that there's no way in hell I'll be > using THP on a Production box, but now I just want to know. > > Thanks! > Rich > > -- > http://www.freelists.org/webpage/oracle-l > > > -- Niall Litchfield Oracle DBA http://www.orawin.info -- http://www.freelists.org/webpage/oracle-l