From owner-freebsd-fs@freebsd.org Tue May 17 21:46:47 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5BD93B3FEA0 for ; Tue, 17 May 2016 21:46:47 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DF2561777 for ; Tue, 17 May 2016 21:46:46 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: by mail-wm0-x22e.google.com with SMTP id n129so158118761wmn.1 for ; Tue, 17 May 2016 14:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=HbfemyyWjoDRZ6770FQPy4PY02rYdxvUX21JKyZnTvE=; b=GBmlXcYH54XMqkc88djwby+crSG/B+62kv1kFDresvyb3AzZN1b/qMKSr2uMZvJwJL YxlHEU5fq/egqQaK4yZwyWW57eJ2hC38kNUnbwIacDwv9STRj5rB+Iphof+Ql2PmhuHK UCLEsyYuHSJ7T/PlRq0ZPhltu+6nTXKtIzMVgfCgticqe3bcLPPPXQKqgCTM7YN/UPbA tQyOxD27jAaJj3meff9faAi7qXiG5uz/GHhKJPNRE6u5GkmqO6OdaI8S9LLiZidaV7rH 4ZZAJKg0fn0+mNTLl67hjlJhQgRyesYoBRaSX0UccYrhVAXhqP29TnJchb0gyVN5iccV gKBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=HbfemyyWjoDRZ6770FQPy4PY02rYdxvUX21JKyZnTvE=; b=bfRb0nqGwUUwi9aXA3Sofo5GDIdn0g41b9mziHbUtvUxe7BexUDfMKHVBHKLfqUCFB qXjptfESSGHB3/0ULr810pUVMWVeBREmafHv4GR3nIsSdNjXrRlRHMNgVFuuGhcJgs49 bihNITJyLa2VKa1vC/DZmRjtorDBrhep0a5gTk+3fh0SXqj+74JrnY86N/7Es8vEOFjz +6R8f/oZBqYfcZ0ZT++lGcnxu0yOCP9u7aZx0EIB/xDJmtZ1b6Dx5kpdipK6ccQcgeAD tMsDbYe60NLlp048EtRsigzYYfd+puL6c3CaR9gntwUslX6ZdRU3nsa5IxPvsmT2S21a Yw8g== X-Gm-Message-State: AOPr4FVmJMTjRjVUon74W+pMIx7aq310aFzp1+2lgvgS7RJSJEb0/Nns/ljgHHFOwJvsrwTcv47K3mzSx1s0KCHv MIME-Version: 1.0 X-Received: by 10.28.6.138 with SMTP id 132mr25022114wmg.60.1463521605006; Tue, 17 May 2016 14:46:45 -0700 (PDT) Received: by 10.28.93.203 with HTTP; Tue, 17 May 2016 14:46:44 -0700 (PDT) In-Reply-To: <20160517213549.GK24656@over-yonder.net> References: <8441f4c0-f8d1-f540-b928-7ae60998ba8e@lexa.ru> <16e474da-6b20-2e51-9981-3c262eaff350@lexa.ru> <1e012e43-a49b-6923-3f0a-ee77a5c8fa70@lexa.ru> <86shxgsdzh.fsf@WorkBox.Home> <20160517213549.GK24656@over-yonder.net> Date: Tue, 17 May 2016 22:46:44 +0100 Message-ID: Subject: Re: ZFS performance bottlenecks: CPU or RAM or anything else? From: Steven Hartland To: "Matthew D. Fuller" Cc: Freddie Cash , "freebsd-fs@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 21:46:47 -0000 Not to mention it's so easy to cripple performance with a bad bios setup this could easily be a simple setup issue. I had an issue the other day where a 4ghz Intel CPU couldn't process video transcode in real time which turned out to be a power saving option in the bios that was utterly destroying performance by running the CPU at 800Mhz instead of 4Ghz. Everything else seemed fine with nothing was using more then a few present of CPU. Disabling power saving fixed the issue. This issue was not present on a much lower power / older box simply because it didn't have the advanced power saving options. I'm not saying this was the case in these tests but simply providing a comcrete example that it's sometimes hard to get like for like comparisons even for what should be simple tests. On Tuesday, 17 May 2016, Matthew D. Fuller wrote: > On Tue, May 17, 2016 at 02:16:16PM -0700 I heard the voice of > Freddie Cash, and lo! it spake thus: > > > > They're not asking for ways to improve the performance of a > > raidz-based pool; they're asking why they get different performance > > metrics from the exact same pool when they change the CPU and RAM. > > More specifically, as I read it, different performance in a very > specific metric; single-thread linear bulk writes. That doesn't seem > like it would benefit heavily from a lot of cores available, or from > RAM bandwidth or size above a pretty low threshold. > > Of course, it's not just changing the CPU and RAM; it's also the > motherboard, and possibly the HBA (at least the bus the HBA is on, if > it's a card being transplanted with the pool). And the Core 2 would > be back in the plain-old FSB era, so RAM access would be competing > with the disk IO on the bus. > > > -- > Matthew Fuller (MF4839) | fullermd@over-yonder.net > Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ > On the Internet, nobody can hear you scream. >