Hi,
that's ok, just to make sure the spec. Are you running
- a 2-socket Xeon E5-2640 system, and
- not running VM (and assigning only partial CPUs to it)?
It will need someone else having similar machines to help reproduce
it. My guess is some counting bits got overflown, or the CPU topology
repo
Il 29/04/13 14:20, Jia-Shiun Li ha scritto:
On Fri, Mar 22, 2013 at 5:03 PM, Davide D'Amico
wrote:
Hi, I'm doing performance tests on a DELL R720, follows dmesg:
Copyright (c) 1992-2012 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The R
On Fri, Mar 22, 2013 at 5:03 PM, Davide D'Amico
wrote:
> Hi, I'm doing performance tests on a DELL R720, follows dmesg:
>
> Copyright (c) 1992-2012 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> The Regents of the University of California.
Il 25/03/13 18:11, Adrian Chadd ha scritto:
Can you please run a Linux install in a FreeBSD jail so we can see
whether it's the kernel or userland?
Sure, do you have a link on how to install gnu/linux on a fbsd jail?
Is ok if I use the VM I created in vmware (so it will be VMWARE ->
FreeBSD -
Can you please run a Linux install in a FreeBSD jail so we can see
whether it's the kernel or userland?
Thanks,
Adrian
On 25 March 2013 07:45, Davide D'Amico wrote:
> Il 25/03/13 15:00, Davide D'Amico ha scritto:
>
>> Thank you Daniel for your tests, here my tests using sysbench v0.5 MySQL
Il 25/03/13 15:00, Davide D'Amico ha scritto:
Thank you Daniel for your tests, here my tests using sysbench v0.5 MySQL
Benchmarks r/w (80%/20%) test on 10.000.000 rows 2.000.000 query using
Standard OLTP: values represent the number of transactions per second
and the first number is obtained usin
Thank you Daniel for your tests, here my tests using sysbench v0.5 MySQL
Benchmarks r/w (80%/20%) test on 10.000.000 rows 2.000.000 query using
Standard OLTP: values represent the number of transactions per second
and the first number is obtained using 1 thread, the second one using 2
threads,
On Sun, 24 Mar 2013 11:01:05 -0500
Adam Vande More wrote:
> These are interesting results. Did you try tuning any of the jemalloc
> options in /etc/malloc.conf?
No tuning, jemalloc was tested "out of the box" just for curiosity.
> I think increasing the number of arenas may help the contention
On 24 March 2013 11:45, Adam Vande More wrote:
> jemalloc also has concurrency issues when threads > areas:
>
> http://people.freebsd.org/~jasone/jemalloc/bsdcan2006/jemalloc.pdf
Right.
I still think it's worth trying the mysql test in a debian/kfreebsd
install in a jail on the same machine you
jemalloc also has concurrency issues when threads > areas:
http://people.freebsd.org/~jasone/jemalloc/bsdcan2006/jemalloc.pdf
On Sun, Mar 24, 2013 at 12:51 PM, Adrian Chadd wrote:
> The contention is due to memory allocations being page aligned and
> those pools all hitting the same cache line
The contention is due to memory allocations being page aligned and
those pools all hitting the same cache line mappings.
Adrian
On 24 March 2013 09:09, Adam Vande More wrote:
> I think increasing the number of arenas may help the contention, eg "ln -s
> 3N /etc/malloc.conf"
>
> On Sun, Mar 24
I think increasing the number of arenas may help the contention, eg "ln -s
3N /etc/malloc.conf"
On Sun, Mar 24, 2013 at 11:01 AM, Adam Vande More wrote:
> These are interesting results. Did you try tuning any of the jemalloc
> options in /etc/malloc.conf?
>
>
> On Sat, Mar 23, 2013 at 3:34 PM, D
These are interesting results. Did you try tuning any of the jemalloc
options in /etc/malloc.conf?
On Sat, Mar 23, 2013 at 3:34 PM, Daniel Bilik wrote:
> On Fri, 22 Mar 2013 10:03:27 +0100
> Davide D'Amico wrote:
>
> > Hi, I'm doing performance tests on a DELL R720, follows dmesg:
> > ...
> > I
#x27;ve worked with many Linux variants. However, when I look
at who is really using BSD Cisco, Juniper, NetApp, and many major
manufacturers base their *NIX products on it and kind of give away Linux for
free but they are really happy to get consulting hours at $200-$400/hr to work
it.... So,
... and how about setting up MySQL inside a Linux jail? Say,
installing debian/kfreebsd in a jail and then testing mysql in there?
Adrian
___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
T
On 3/23/13 3:44 AM, Davide D'Amico wrote:
Il 23.03.2013 01:34 Paul Pathiakis ha scritto:
Hi,
There are several things about this that are highly suspect.
First, wipe out the hardware RAID. The processor doing RAID
computation is, probably, MUCH slower than a core on the CPU. Even if
it's RAID-
On Sun, 24 Mar 2013 09:11:53 +0100
Davide D'Amico wrote:
> Ok, I'll try tomorrow and I'll post results here. Some particular
> parameter to use?
Well, sysbench's "simple" is really simple ;-), it performs a single
SELECTs (unlike "nontrx", which can be made to perform also writes). Table
size yo
On Sun, 24 Mar 2013 06:59:29 +0100
Davide D'Amico wrote:
> I'll try the 'simple' dataset, but do you think I have some chance to
> "solve" the issue?
Not sure. But in case you'll get much more similar (CentOS vs. FreeBSD)
results from "simple" OLTP test, as opposed to very differrent numbers
fo
Ok, I'll try tomorrow and I'll post results here. Some particular parameter to
use?
Daniel Bilik ha scritto:
>On Sun, 24 Mar 2013 06:59:29 +0100
>Davide D'Amico wrote:
>
>> I'll try the 'simple' dataset, but do you think I have some chance to
>
>> "solve" the issue?
>
>Not sure. But in case yo
Il 24.03.2013 07:10 Mehmet Erol Sanliturk ha scritto:
On Sat, Mar 23, 2013 at 10:59 PM, Davide D'Amico
wrote:
Il 22.03.2013 16:56 Евгений Хоркин ha scritto:
Hi Davide!
Sorry if I do a reply 'here' but some posts where filtered by
antispam.
To Daniel Bilik: yes, I used the 'complex' OLTP
On Sat, Mar 23, 2013 at 10:59 PM, Davide D'Amico <
davide.dam...@contactlab.com> wrote:
> Il 22.03.2013 16:56 Евгений Хоркин ha scritto:
>
>> Hi Davide!
>>
>
> Sorry if I do a reply 'here' but some posts where filtered by antispam.
>
> To Daniel Bilik: yes, I used the 'complex' OLTP tests, because
Il 22.03.2013 16:56 Евгений Хоркин ha scritto:
Hi Davide!
Sorry if I do a reply 'here' but some posts where filtered by antispam.
To Daniel Bilik: yes, I used the 'complex' OLTP tests, because more
similar to my production dataset/workload.
I'll try the 'simple' dataset, but do you think I
Yup, that one.
I wonder if that has anything to do here..
Adrian
On 23 March 2013 17:20, Adam Vande More wrote:
> On Sat, Mar 23, 2013 at 7:08 PM, Adrian Chadd wrote:
>>
>> Hi,
>>
>> I recall that there were significant issues with jemalloc on
>> computational loads, primarily because of th
On Sat, Mar 23, 2013 at 7:08 PM, Adrian Chadd wrote:
> Hi,
>
> I recall that there were significant issues with jemalloc on
> computational loads, primarily because of the alignment jemalloc ends
> up giving to various allocation sizes and the cache-busting behaviour
> of that.
>
> Does anyone re
Hi,
I recall that there were significant issues with jemalloc on
computational loads, primarily because of the alignment jemalloc ends
up giving to various allocation sizes and the cache-busting behaviour
of that.
Does anyone remember the thread in which that happened? Maybe someone
posted a patc
On Fri, 22 Mar 2013 10:03:27 +0100
Davide D'Amico wrote:
> Hi, I'm doing performance tests on a DELL R720, follows dmesg:
> ...
> I will use this server as a mysql-5.6 dbserver so I have a root
> partition using a hw raid1 and a /DATAZFS partition, follows
> configuration:
> ...
Well, it seems
Il 23.03.2013 01:34 Paul Pathiakis ha scritto:
Hi,
There are several things about this that are highly suspect.
First, wipe out the hardware RAID. The processor doing RAID
computation is, probably, MUCH slower than a core on the CPU. Even if
it's RAID-1 (Simple Mirror) this RAID card is perform
To: Евгений Хоркин
Cc: freebsd-performance@freebsd.org
Sent: Friday, March 22, 2013 12:15 PM
Subject: Re: FreeBSD 9.1 vs CentOS 6.3
Well, the I/O isn't the bottleneck (if you follow the link to freebsd-fs,
you'll see iostats values) but it seems something related to cpu/scheduler or
On Fri, Mar 22, 2013 at 9:15 AM, Davide D'Amico
wrote:
> Well, the I/O isn't the bottleneck (if you follow the link to freebsd-fs,
> you'll see iostats values) but it seems something related to cpu/scheduler or
> something else.
> Now I am trying vmware 5 on the same server and a vm with centos6
Well, the I/O isn't the bottleneck (if you follow the link to freebsd-fs,
you'll see iostats values) but it seems something related to cpu/scheduler or
something else.
Now I am trying vmware 5 on the same server and a vm with centos6: the vm
outperforms freebsd with every concurrency from 1 to 4
Hi Davide!
Are you sure that disk is the bottleneck in your test?
Does systat -vm 1 show 100% busy for disk ?
Evgeny.
2013/3/22 Davide D'Amico
> Hi, I'm doing performance tests on a DELL R720, follows dmesg:
>
> Copyright (c) 1992-2012 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 19
On Mar 22, 2013, at 6:06 AM, Davide D'Amico
wrote:
> Il 22/03/13 11:00, Traffanstead, Mike ha scritto:
>> May I ask why you're running ZFS on top of a RAID array? That's not
>> recommended. One of the advantages of ZFS is that it balance disk
>> activity across devices but when put it on top
Il 22/03/13 11:00, Traffanstead, Mike ha scritto:
May I ask why you're running ZFS on top of a RAID array? That's not
recommended. One of the advantages of ZFS is that it balance disk
activity across devices but when put it on top drives that at are
already raided it loses that insight and may
May I ask why you're running ZFS on top of a RAID array? That's not
recommended. One of the advantages of ZFS is that it balance disk
activity across devices but when put it on top drives that at are
already raided it loses that insight and may end up scheduling
reads/writes that all land on the
Hi, I'm doing performance tests on a DELL R720, follows dmesg:
Copyright (c) 1992-2012 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The F
35 matches
Mail list logo