From owner-freebsd-performance@FreeBSD.ORG Sun Apr 15 20:39:10 2012 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 956AA1065674; Sun, 15 Apr 2012 20:39:10 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 35E718FC16; Sun, 15 Apr 2012 20:39:10 +0000 (UTC) Received: by obqv19 with SMTP id v19so5422520obq.13 for ; Sun, 15 Apr 2012 13:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=WzeAvt6pvhUgFhO0k93lFSOn8nLG3M1hx3eGZN/CotI=; b=gJ5P5kyAvobcQ2SVQdRTwHEe4wzblb8TuVzOuGZ8yRUsJkcaiuVcjyfFb9m78InZtK Skx3MPuJiJdAD3ePplOuGqdorZNGKyS1scN5pSDrl5W2WJk/X8aVImXbQLg7nqpGC4Gg G2zhFP5Wp3EFhy432ZchI1yYjdR9tBqfsT9JdBA6ej8h5ivj+R88UJUagU82auonyBKb qfPufbaL5kDl9TJQG8amwz+6Ja7pZymeB0aQ2KaVEwezQPk/CoCoVR2hTetJBZpnB5YI SGrRp0ARw/UvnGm21w8OMxkuSETjlZ3mDqybg59heW//xPjKLKi2x98EvkPzxFy7ETy8 i6dQ== Received: by 10.60.36.100 with SMTP id p4mr12717115oej.42.1334522349610; Sun, 15 Apr 2012 13:39:09 -0700 (PDT) Received: from [192.168.2.5] (dpc691939029.direcpc.com. [69.19.39.29]) by mx.google.com with ESMTPS id a8sm13819782oea.8.2012.04.15.13.38.59 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 15 Apr 2012 13:39:08 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Garrett Cooper In-Reply-To: <4F8B2CC4.5030601@zedat.fu-berlin.de> Date: Sun, 15 Apr 2012 13:35:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <28768C15-C694-4C09-8CD1-3F5412554B55@gmail.com> References: <4F8AAEF7.3090800@zedat.fu-berlin.de> <4F8B21D2.4080008@zedat.fu-berlin.de> <951B1A8C-A216-420A-BA17-316B8D9C2B0E@gmail.com> <4F8B2CC4.5030601@zedat.fu-berlin.de> To: "O. Hartmann" X-Mailer: Apple Mail (2.1257) Cc: freebsd-security@freebsd.org, Richard Kojedzinszky , Current FreeBSD , freebsd-performance@freebsd.org Subject: Re: ufs multilabel performance (fwd) X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 20:39:10 -0000 On Apr 15, 2012, at 1:17 PM, O. Hartmann wrote: > Am 04/15/12 22:00, schrieb Garrett Cooper: >> On Apr 15, 2012, at 12:30 PM, O. Hartmann wrote: >>=20 >>> Am 04/15/12 15:59, schrieb Richard Kojedzinszky: >>>> Thank you for the reply. >>>>=20 >>>> Unfortunately, dont know why, but on my xen virtualised = environment, >>>> fbsd amd64 domU performs much slower, not only 30 times. Without >>>> multilabel, file creation speed is around 2500/s, but with = multilabels >>>> enabled, it is only 15/s (!). so it is more than 100 times slower. >>>>=20 >>>> And anyway freebsd is known to be fast as well, as functional. The = power >>>> to serve. :) >>>>=20 >>>> But in my environment, 15/s file creation is very-very slow. The >>>> hardware is a q6700 cpu with 4G ram, 2x1T sata disks in raid1, the = host >>>> runs linux. I think with this hw the mentioned speed is really = slow. >>>>=20 >>>> Regards, >>>>=20 >>>>=20 >>>> Kojedzinszky Richard >>>> Euronet Magyarorszag Informatikai Zrt. >>>>=20 >>>> On Sun, 15 Apr 2012, O. Hartmann wrote: >>>>=20 >>>>> Date: Sun, 15 Apr 2012 13:20:23 +0200 >>>>> From: O. Hartmann >>>>> To: Richard Kojedzinszky >>>>> Cc: freebsd-security@freebsd.org >>>>> Subject: Re: ufs multilabel performance (fwd) >>>>>=20 >>>>> Am 04/14/12 21:37, schrieb Richard Kojedzinszky: >>>>>> Dear list, >>>>>>=20 >>>>>> Although it is not only security-related question, I did not get = any >>>>>> answer from freebsd-performance. The original question is below. >>>>>>=20 >>>>>> Can someone give some advice? >>>>>>=20 >>>>>> Thanks in advance, >>>>>>=20 >>>>>>=20 >>>>>> Kojedzinszky Richard >>>>>> Euronet Magyarorszag Informatikai Zrt. >>>>>>=20 >>>>>> ---------- Forwarded message ---------- >>>>>> Date: Thu, 10 Nov 2011 06:16:57 +0100 (CET) >>>>>> From: Richard Kojedzinszky >>>>>> To: freebsd-performance@freebsd.org >>>>>> Subject: ufs multilabel performance >>>>>>=20 >>>>>> Dear List, >>>>>>=20 >>>>>> I've noticed that when I enable multilabel on an fs, a file = creation >>>>>> gets around 20-30 times slower than without multilabel set. >>>>>>=20 >>>>>> This one-liner can be used to test the differences: >>>>>> $ truss -D perl -e 'open(F, ">$_.file") for 1 .. 1000' >>>>>=20 >>>>> Same here, creating files seems to be 10 - 30 times slower with >>>>> multilabels as it is without. >>>>>=20 >>>>> But as several posts and discussions reflects, FreeBSD isn't = supposed to >>>>> be fast although it is claimed that writing is the major than = reading; >>>>> FBSD should serve functionality. >>>>>>=20 >>>>>> And one can see that the open call takes much more when = multilabel is >>>>>> set on an fs. It seems that only file creation needs that many = time, >>>>>> when a file exists it is opened much faster. >>>>>>=20 >>>>>> Could someone acknowledge this, and have some suggestions how to = make it >>>>>> faster? >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>>=20 >>>>>> Kojedzinszky Richard >>>>>> TvNetWork Nyrt. >>>>>> E-mail: krichy (at) tvnetwork [dot] hu >>>>>> PGP: 0x54B2BF0C8F59B1B7 >>>>>> Fingerprint =3D F6D4 3FFE AF03 CACF 0DCB 46A1 54B2 BF0C 8F59 = B1B7 >>>=20 >>> At the moment, I'm troubled with a nasty kernel bug on all FreeBSD = 10 >>> boxes I have spare to test. >>>=20 >>> I just tried to reproduce your observation and as far as I can go = with >>> my experience, I can confirm that by using your perl script. >>>=20 >>> I'd like to test this again with a small C program. >>>=20 >>> I can only test the issue (test is too far optimistic, it's simply a >>> reproduction of your observation) on FreeBSD 10, the only remaining >>> FreeBSD server at our department is running FBSD 9-STABLE/amd64 and = "in >>> production", so changing multilabel support is a bit harsh at the = moment. >>>=20 >>>=20 >>> Sorry about crossposting, but I think this belongs more to CURRENT = and >>> PERFORMANCE than SECURITY. >>=20 >> My suggestion is completely take perl out of the equation because the = way you're invoking it above uses stdio and a few other things that add = unnecessary overhead. >>=20 >> Try the attached C program/bourne shell snippet instead. >>=20 >> Cheers, >> -Garrett >>=20 >> #!/bin/sh >>=20 >> set -e >>=20 >> tmp=3D$(mktemp -d tmp.XXXXXX) >> trap "cd /; rm -Rf $tmp" EXIT >> cd $tmp >>=20 >> cat > test_open.c <>=20 >> #include >> #include >> #include >>=20 >> int >> main(void) >> { >> char buf[20]; >> int i; >>=20 >> for (i =3D 0; i < 1000; i++) { >> sprintf(buf, "%d", i); >> close(open(buf, O_WRONLY|O_CREAT, 0600)); >> } >> return (0); >> } >> EOF >>=20 >> gcc -o test_open test_open.c >> time ./test_open_______________________________________________ >=20 > This was pretty fast ;-) If it turns out that it wasn't that particular item that's = causing a slowdown, I can easily modify my above snippet to use stdio, = etc. But unless the version of perl and a few other items are the same, = I wouldn't necessarily blame the guest OS. Please also make sure that = Xen, etc is completely up-to-date because there were some performance = degradation issues that were fixed post-6.0. -Garrett=