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 49EFC19602A4 for ; Thu, 6 Jun 2013 21:02:09 +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 21:02:09 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 6084022F76; Thu, 6 Jun 2013 14:48:58 -0400 (EDT) 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 tW3X4IteVgcM; Thu, 6 Jun 2013 14:48:58 -0400 (EDT) Received: from turing.freelists.org (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 3A3B622F6F; Thu, 6 Jun 2013 14:48:17 -0400 (EDT) Received: with ECARTIS (v1.0.0; list oracle-l); Thu, 06 Jun 2013 14:47:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 42E6B22F0D for ; Thu, 6 Jun 2013 14:47:36 -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 qOtAq61jkmWm for ; Thu, 6 Jun 2013 14:47:36 -0400 (EDT) Received: from mail.burton.com (mail.burton.com [204.52.244.205]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id C91A822EF8 for ; Thu, 6 Jun 2013 14:47:35 -0400 (EDT) Received: from mail.burton.com (127.0.0.1) id hm3e640171sj for ; Thu, 6 Jun 2013 15:00:49 -0400 (envelope-from ) Received: from helo.usa.burton.com ([10.7.2.8]) by mail.burton.com (SonicWALL 7.3.5.6369) with ESMTP (AIO); Thu, 06 Jun 2013 15:00:49 -0400 Received: from HELO.usa.burton.com ([::1]) by helo.usa.burton.com ([::1]) with mapi id 14.01.0438.000; Thu, 6 Jun 2013 15:00:44 -0400 From: Brian Pardy To: "hurleyjohnb@yahoo.com" , "oracle-l@freelists.org" , "rjoralist2@society.servebeer.com" Subject: RE: Transparent HugePages causing crashes? Thread-Topic: Transparent HugePages causing crashes? Date: Thu, 6 Jun 2013 19:00:43 +0000 Message-ID: <92C2516C1D75EB4A922A8EE402EC23D555423E01@helo.usa.burton.com> References: <8ab340b6a74fc4f8f3cf3f53011721dc.squirrel@society.servebeer.com> <1370543385.61185.YahooMailClassic@web181202.mail.ne1.yahoo.com> In-Reply-To: <1370543385.61185.YahooMailClassic@web181202.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.15.6.30] Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-Mlf-Version: 7.3.5.6369 X-Mlf-UniqueId: o201306061900490084249 X-archive-position: 49223 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: brianpa@burton.com Precedence: normal Reply-To: brianpa@burton.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 The path specified in the note works as-is on SLES11. The part that disappoints me more is that they refer to the note covering 'standard' hugepages without any details to let us know if we are at risk of this transparent hugepage instability in the following situation: * Transparent hugepages left at default 'enabled' state * Standard hugepages configured via vm.nr_hugepages as per note 361323.1 and used by the database Also, they refer to disabling transparent hugepages at boot time but do not discuss whether or not one can safely set these to 'never' on an active, running server where standard hugepages are in active use, implying a reboot will be needed without stating so. > From: oracle-l-bounce@freelists.org [mailto:oracle-l-bounce@freelists.org] On > Behalf Of John Hurley > > Classic oracle support information here ... they give a fix that refers to a > directory that does not exist. Who would QA a support alert? > > First the directory ( on 6.4 anyhow ) is /sys/kernel/mm/transparent_hugepage > NOT ( ... hugepages ). > > Plus they do not note that directory name is also different between release > levels ( 6.2 versus 6.4 ) etc. > > Caveat emptor. > > > if test -f /sys/kernel/mm/transparent_hugepages/enabled; then > echo never > /sys/kernel/mm/transparent_hugepages/enabled > fi > if test -f /sys/kernel/mm/transparent_hugepages/defrag; then > echo never > /sys/kernel/mm/transparent_hugepages/defrag > fi -- http://www.freelists.org/webpage/oracle-l