Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cWV80-0004IE-IA for pgsql-hackers@arkaria.postgresql.org; Wed, 25 Jan 2017 21:29:16 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cWV80-0000eq-0Z for pgsql-hackers@arkaria.postgresql.org; Wed, 25 Jan 2017 21:29:16 +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 1cWV6Z-0007VF-Ip for pgsql-hackers@postgresql.org; Wed, 25 Jan 2017 21:27:47 +0000 Received: from mail-wm0-x229.google.com ([2a00:1450:400c:c09::229]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1cWV6W-0002x7-21 for pgsql-hackers@postgresql.org; Wed, 25 Jan 2017 21:27:47 +0000 Received: by mail-wm0-x229.google.com with SMTP id c206so53440307wme.0 for ; Wed, 25 Jan 2017 13:27:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=UnmBgmlKykc5apSJclDyxvx4KL36Cd4kbVlsBuZpWfY=; b=LVzIygcWynhhOqFbuE3Q5SASZlvxOiyiw0SrXC/9k7pgmb/lCGPK4CcNanNfvXSE2i U5jnwf+rDQ/QiGEUDIJJoicgxfgNSRfmsrbz/t7TZXaN9YR91AFjfcaqn9Q/uUqmqf6m D7WpnIPSDHcI624kb8eXTX6UtmF5tx16eM4nFUL+tQ9VU6YVKuXL/Ml7MuYQOMvoGRH5 AeCwoBBo1SNyI0JF/9oPahsqTTZkuardte3Qn+CGYu4WWQZpqKj2SywG4eUxWJHalHKj IpDqF9pmqOMjCt92yJFOj0AFp844ETjvPyCrfBztWQ34P31EJkAzbhDwGbXUxhf8ICn0 5BNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=UnmBgmlKykc5apSJclDyxvx4KL36Cd4kbVlsBuZpWfY=; b=BGgcco2GWmcKCk8Cwk6aX/ERSNlgd/NebHQJbtJW8Lc4sGG2MD2tTfw5sKcKWoycPU Vc9VTA9EHAYulIlv39L7eoP4pOh0UHSEtzsoq5pR13dqEmRVg1H5t5YHYnpY/0zIkMzA wo3Iqk8N8Lvx2cNfSmG7iPVpJfWeRHeBxsLYsAClnQnd0AXoCq1AXmHmhTC644I5ny1h VdCGwwtZP58OkDl+F0cY9wuOdQtkFu8KqFgTWvr/MXTp8XE3W0hOozbPNdDO31uAb6u1 r8gtyORhC/5QoChHpjNTNVA/lP/lQKG0X/e4eG0b/aAaJ9PN/P4CBcyOjycJvjQY9/nG ZoWw== X-Gm-Message-State: AIkVDXIxSOigh2un/9mbTVcq4MKlV1celSqBWiXXJIoyoIaxiMqnwJQZpv976tphkYZO1w== X-Received: by 10.223.133.4 with SMTP id 4mr35650327wrh.176.1485379661441; Wed, 25 Jan 2017 13:27:41 -0800 (PST) Received: from [192.168.55.138] (ppp-93-104-163-1.dynamic.mnet-online.de. [93.104.163.1]) by smtp.googlemail.com with ESMTPSA id 191sm401566wmo.21.2017.01.25.13.27.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jan 2017 13:27:40 -0800 (PST) Subject: Re: lseek/read/write overhead becomes visible at scale .. To: Andres Freund References: <20170124171841.2n2nzqkuetbivzta@alap3.anarazel.de> <20170124174158.nk6htg7jjmqia7hr@alap3.anarazel.de> <422b4e6c-b7f0-90e0-6f70-389b2d50a848@gmail.com> <20170124181121.pgk7kqfkq4dd3hpo@alap3.anarazel.de> <20170124190705.2ioaocx6wuhvvegn@alap3.anarazel.de> <20170125195238.2sjh477x2zvmjm5a@alap3.anarazel.de> Cc: pgsql-hackers@postgresql.org From: Tobias Oberstein Message-ID: Date: Wed, 25 Jan 2017 22:27:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170125195238.2sjh477x2zvmjm5a@alap3.anarazel.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Hi, >> Synthetic PG workload or real world production workload? > > Both might work, production-like has bigger pull, but I'd guess > synthetic is good enough. Thanks! The box should get PostgreSQL in the not too distant future. It'll get a backup from prod, but will act as new prod, so it might take some time until a job can be run and a profile collected. >> So how would I do a perf profile that would be acceptable as prove? > > You'd have to look at cpu time, not number of syscalls. IIRC I > suggested doing a cycles profile with -g and then using "perf report > --children" to see how many cycles are spent somewhere below lseek. Understood. Either profile manually or expand the function. > I'd also suggest sharing a profile cycles profile, it's quite likely > that the overhead is completely elsewhere. Yeah, could be. It'll be interesting to see for sure. I should get a chance to collect such profile and then I'll post it back here - /Tobias -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers