Date: Sun, 15 Apr 2012 13:35:59 -0700 From: Garrett Cooper <yanegomi@gmail.com> To: "O. Hartmann" <ohartman@zedat.fu-berlin.de> Cc: freebsd-security@freebsd.org, Richard Kojedzinszky <krichy@tvnetwork.hu>, Current FreeBSD <freebsd-current@freebsd.org>, freebsd-performance@freebsd.org Subject: Re: ufs multilabel performance (fwd) Message-ID: <28768C15-C694-4C09-8CD1-3F5412554B55@gmail.com> In-Reply-To: <4F8B2CC4.5030601@zedat.fu-berlin.de> References: <alpine.DEB.2.02.1204142134050.8001@krichy.tvnetwork.hu> <4F8AAEF7.3090800@zedat.fu-berlin.de> <alpine.DEB.2.02.1204151555080.12537@krichy.tvnetwork.hu> <4F8B21D2.4080008@zedat.fu-berlin.de> <951B1A8C-A216-420A-BA17-316B8D9C2B0E@gmail.com> <4F8B2CC4.5030601@zedat.fu-berlin.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <ohartman@zedat.fu-berlin.de>
>>>>> To: Richard Kojedzinszky <krichy@tvnetwork.hu>
>>>>> 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 <krichy@tvnetwork.hu>
>>>>>> 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 <<EOF
>>=20
>> #include <fcntl.h>
>> #include <stdio.h>
>> #include <unistd.h>
>>=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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?28768C15-C694-4C09-8CD1-3F5412554B55>