Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dWRKy-0001BW-Tm for pgsql-performance@arkaria.postgresql.org; Sat, 15 Jul 2017 17:58:41 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dWRKy-0006tU-Ge for pgsql-performance@arkaria.postgresql.org; Sat, 15 Jul 2017 17:58:40 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dWRKx-0006s9-ER for pgsql-performance@postgresql.org; Sat, 15 Jul 2017 17:58:39 +0000 Received: from mail-qk0-x232.google.com ([2607:f8b0:400d:c09::232]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1dWRKt-0003vf-3J for pgsql-performance@postgresql.org; Sat, 15 Jul 2017 17:58:37 +0000 Received: by mail-qk0-x232.google.com with SMTP id p73so33091054qka.2 for ; Sat, 15 Jul 2017 10:58:34 -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 :cc; bh=yBxOMD7MuF7DAouIe6NeEVbnq8EGdp8MbN0cgMrjzW8=; b=SHjfdGc3gG6n5BeN44q6J5qCUpX5STCaL6tk5BaVttbnNq3Fu94KF4eJa7+x6ERvWH XPNuMw0z6GH6WlzGkQ3pX+LMDryKAVUop3rtj5FyxnSxtGQrvEHjzQ1ioT7VBh2Yi2KV xO53k2UCsxGuiJuRgt5E1/Vs1G1yH4hwa4cfEzGH1rY2PWwr9HeA9ByekwAcR81iZMeZ LbHODon2DzWSm+8ZEgM/YPuic+MADb64vvx75VdD3dzGuFd6MgaRfm97jJUYrgC+yzad +yxBj49zw0JQpdW9p7MKz5VtWTtvPEslhN4CRMUq52Iw1rEmeicmI8Re9LI0ou9R3pq7 YmcQ== 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:cc; bh=yBxOMD7MuF7DAouIe6NeEVbnq8EGdp8MbN0cgMrjzW8=; b=FhJ6tfPtCjhUDsaI5pwGbeFGVoNE6uPa5V86vZxxSar6oh3OjGoKdWADXsz8qdMzRS hsCQU7X3dkONFMZSRppRxqltoFpUaccPO7Nui+0EgLRKmWEMcF8HD2lqLZOVsOfiAG9U 9MZMm8+qRFuNxwfYpFWhj54pnhVtWqacMiZUXCtyZGGq6NXzcr00oXEPgN75hG/ndqKX +afHchl0bA1c324CVw1B8LfQk4n/JNrmVdRQaqw4u6nRjG+sL7IPs0XOBhGQErmtlTyl dyQqxe/ttqYcjE92pjxdUtPDobVusaI/piw3ms2RxS6j5KsI1H8JcM9fISS9Fks6oRoV UfQA== X-Gm-Message-State: AIVw112Xr326Gfi3EBQja5py9vnkMv3x6WckuXVE3X6/aRmi5JZvPcQ/ F2MtM0pF2ZZzV1ctXhaDuUeLDfqaMw== X-Received: by 10.55.8.140 with SMTP id 134mr18961735qki.198.1500141513512; Sat, 15 Jul 2017 10:58:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.82.7 with HTTP; Sat, 15 Jul 2017 10:58:32 -0700 (PDT) In-Reply-To: References: From: Scott Marlowe Date: Sat, 15 Jul 2017 11:58:32 -0600 Message-ID: Subject: Re: Very poor read performance, query independent To: Charles Nadeau Cc: Mark Kirkwood , "pgsql-performa." Content-Type: text/plain; charset="UTF-8" List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org On Sat, Jul 15, 2017 at 11:53 AM, Charles Nadeau wrote: > Mark, > > I increased the read ahead to 16384 and it doesn't improve performance. My > RAID 0 use a stripe size of 256k, the maximum size supported by the > controller. Are your queries still spilling to disk for sorts? If this is the case, and they're just too big to fit in memory, then you need to move your temp space, where sorts happen, onto another disk array that isn't your poor overworked raid-10 array. Contention between sorts and reads can kill performance quick, esp on spinning rust. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance