High usage of mbufs

[Michael VInce]

Hi guys
On one of my web servers I have a really high usage of mbuf clusters in 
use on a web server that does about 3million hits a day.

4294914731/262144 mbuf clusters in use (current/max)
Does any one know why this is? I was thought it may of been hit by a 
small syn flood that went un noticed and that the current mbuf stat is 
failing to update its real usage, but the number does move every time I 
run netstat -m
This is a dual P4 machine with 4gigs of ram that was setup before 5.4 
was release, so it could be considered 5.3 stable.

5.4-PRERELEASE #0: Mon Feb 28 20:01:43 EST 2005

netstat -m
352955 mbufs in use
4294914731/262144 mbuf clusters in use (current/max)
0/27/6656 sfbufs in use (current/peak/max)
4177412 KBytes allocated to network
0 requests for sfbufs denied
0 requests for sfbufs delayed
415 requests for I/O initiated by sendfile
2300 calls to protocol drain routines

___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD MySQL still WAY slower than Linux

[Michael Vince]

Your posting a lot of configuration here except the most easily 
important one for performance in MySQL, thats your my.cnf configuration file

You will more then double your performance if you just start off by copying
/usr/local/share/mysql/my-large.cnf
to
/var/db/mysql
MySQL out of the box setup to use a tiny amount of ram and it wouldn't 
surprise me if a lot of Linux distributions have a much more high 
performance my.cnf file since most distributions are aimed at people who 
don't know what they are doing.



Steve Roome wrote:


Oops, here's what I was supposed to attach to the email with test results in it.

Sorry about that,

   Steve Roome


/etc/make.conf


WITHOUT_X11=yes
WITHOUT_NLS=yes

CFLAGS?=-O3 -pipe
CPUTYPE?=p4
KERNCONF?=PE2650_i386_steve
NO_PROFILE=true

MASTER_SITE_BACKUP?= 
ftp://ftp.uk.freebsd.org/pub/FreeBSD/ports/distfiles/${DIST_SUBDIR}/
MASTER_SITE_OVERRIDE?= ${MASTER_SITE_BACKUP}

SUP_UPDATE=yes
SUP=/usr/local/bin/cvsup
SUPFLAGS=-g -L 2
SUPHOST=cvsup.uk.FreeBSD.org
SUPFILE=/usr/src/supfile
PORTSSUPFILE=/usr/ports/ports-supfile
# added by use.perl 2005-06-23 10:21:11
PERL_VER=5.8.6
PERL_VERSION=5.8.6



# Kernel configuration

# $FreeBSD: src/sys/i386/conf/GENERIC,v 1.413.2.8 2004/10/24 17:42:08 scottl 
Exp $

machine i386
cpu I686_CPU
ident   PE2650_i386_1

options MAXDSIZ=(2048UL*1024*1024)

options SCHED_4BSD  # 4BSD scheduler
options INET# InterNETworking
options FFS # Berkeley Fast Filesystem
options SOFTUPDATES # Enable FFS soft updates support
options UFS_ACL # Support for access control lists
options UFS_DIRHASH # Improve performance on big directories
# can be dynamically loaded: optionsNFSCLIENT   # Network 
Filesystem Client
# can be dynamically loaded: optionsNFSSERVER   # Network 
Filesystem Server
# can be dynamically loaded: optionsMSDOSFS # MSDOS 
Filesystem
# can be dynamically loaded: optionsCD9660  # ISO 9660 
Filesystem
# can be dynamically loaded: optionsPROCFS  # Process 
filesystem (requires PSEUDOFS)
options PSEUDOFS# Pseudo-filesystem framework
options GEOM_GPT# GUID Partition Tables.
options COMPAT_43   # Compatible with BSD 4.3 [KEEP THIS!]
options COMPAT_FREEBSD4 # Compatible with FreeBSD4
options SCSI_DELAY=1000 # Delay (in ms) before probing SCSI
options KTRACE  # ktrace(1) support
options SYSVSHM # SYSV-style shared memory
options SYSVMSG # SYSV-style message queues
options SYSVSEM # SYSV-style semaphores
options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time 
extensions
options KBD_INSTALL_CDEV# install a CDEV entry in /dev
options ADAPTIVE_GIANT  # Giant mutex is adaptive.

options SMP
device  apic# I/O APIC

device  isa
device  pci

device  fdc

device  ata
device  atapicd # ATAPI CDROM drives
options ATA_STATIC_ID   # Static device numbering

device  scbus   # SCSI bus (required for SCSI)
# can be dynamically loaded: device ch  # SCSI media 
changers
device  da  # Direct Access (disks)
# can be dynamically loaded: device sa  # Sequential 
Access (tape etc)
device  pass# Passthrough device (direct SCSI access)
# can be dynamically loaded: device ses # SCSI 
Environmental Services (and SAF-TE)

device  aac # Adaptec FSA RAID
device  aacp# SCSI passthrough for aac (requires CAM)

device  atkbdc  # AT keyboard controller
device  atkbd   # AT keyboard

device  vga # VGA video card driver
device  sc
# can be dynamically loaded: device agp # support 
several AGP chipsets
device  npx
device  sio # 8250, 16[45]50 based serial ports

device  miibus  # MII bus support
device  bge # Broadcom BCM570xx Gigabit Ethernet

device  loop# Network loopback
device  mem # Memory and kernel memory devices
device  io  # I/O device
device  random  # Entropy device
device  ether   # Ethernet support
#

Re: FreeBSD MySQL still WAY slower than Linux

[Michael Vince]

I tried some benchmark testing on a Dell 1850 5.4-Release-P2 with 
generic kernel.
From what I have seen from your postings I was able to get a higher 
supersmack result, 23626.76 .

I compiled 4.0 MySQL with some optimizations
portupgrade -RN -m 'BUILD_STATIC=yes BUILD_OPTIMIZED=yes' 
/usr/ports/databases/mysql40-server/


Downloaded and installed the supersmack source from here 
http://vegan.net/tony/supersmack/super-smack-1.3.tar.gz

with just ./configure --with-mysql

Copied the default large my.cnf profile
cp /usr/local/share/mysql/my-large.cnf /var/db/mysql/my.cnf

# super-smack /usr/share/smacks/select-key.smack 50 1000
Query Barrel Report for client smacker1
connect: max=44ms  min=11ms avg= 20ms from 50 clients
Query_type  num_queries max_timemin_timeq_per_s
select_index10  3   0   23626.76

If I delete the /var/db/mysql/my.cnf and restart mysql so I get default 
configuration, I get 13398.76

# super-smack /usr/share/smacks/select-key.smack 50 1000
Query Barrel Report for client smacker1
connect: max=29ms  min=7ms avg= 17ms from 50 clients
Query_type  num_queries max_timemin_timeq_per_s
select_index10  7   0   13398.76

For me this is as fast as I need my database to be but I can understand 
there is a difference here between FreeBSD and Linux that would make you 
prefer it as the db OS choice.


Regards,
Mike

Steve Roome wrote:


On Sun, Jun 26, 2005 at 12:06:41AM +1000, Michael Vince wrote:
 

Your posting a lot of configuration here except the most easily 
important one for performance in MySQL, thats your my.cnf configuration file

You will more then double your performance if you just start off by copying
/usr/local/share/mysql/my-large.cnf
to
/var/db/mysql
MySQL out of the box setup to use a tiny amount of ram and it wouldn't 
surprise me if a lot of Linux distributions have a much more high 
performance my.cnf file since most distributions are aimed at people who 
don't know what they are doing.
   




Sorry, good point, here's the my.cnf we're using. Please note however
that although the configuration may not be optimal, we have been using
the same config for benchmarking on Linux also. No matter how broken
this my.cnf is we still shouldn't find MySQL running half the speed on
an "identical" setups only switching from Linux to FreeBSD.

Ta,

   Steve Roome

[mysqld]
log-bin
log_slow_queries
log_long_format
server-id   = 182
warnings
skip-slave-start
skip-locking
#read-only

datadir = /data/mysql_data

innodb_file_per_table
innodb_data_home_dir = /data/mysql_data/
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = /data/mysql_data/
innodb_log_arch_dir = /data/mysql_data/
innodb_additional_mem_pool_size = 20M
innodb_flush_log_at_trx_commit = 1
innodb_buffer_pool_size = 1G
innodb_thread_concurrency = 5
innodb_log_files_in_group = 3
innodb_log_buffer_size = 8M
innodb_log_file_size = 64M
innodb_max_dirty_pages_pct = 90


port= 3306
socket  = /tmp/mysql.sock
max_binlog_size=256M
key_buffer = 128M
max_allowed_packet = 4M
table_cache = 2048
sort_buffer_size = 8M
read_buffer_size = 8M
join_buffer_size = 8M
myisam_sort_buffer_size = 128M
thread_cache = 8
thread_cache_size = 40
query_cache_size= 64M
thread_concurrency = 8
wait_timeout= 60
max_connections= 120
#skip-networking

[client]
#password   = 
port= 3306

socket  = /tmp/mysql.sock

[mysqldump]
quick
max_allowed_packet = 32M

[mysql]
#no-auto-rehash
#safe-updates

[isamchk]
key_buffer = 128M
sort_buffer_size = 128M
read_buffer = 2M
write_buffer = 2M

[myisamchk]
key_buffer = 256M
sort_buffer_size = 256M
read_buffer = 2M
write_buffer = 2M

[mysqlhotcopy]
interactive-timeout

[mysqld_safe]
open-files-limit = 8192


 


Steve Roome wrote:

   

Oops, here's what I was supposed to attach to the email with test results 
in it.


Sorry about that,

 Steve Roome


/etc/make.conf


WITHOUT_X11=yes
WITHOUT_NLS=yes

CFLAGS?=-O3 -pipe
CPUTYPE?=p4
KERNCONF?=PE2650_i386_steve
NO_PROFILE=true

MASTER_SITE_BACKUP?= 
ftp://ftp.uk.freebsd.org/pub/FreeBSD/ports/distfiles/${DIST_SUBDIR}/

MASTER_SITE_OVERRIDE?= ${MASTER_SITE_BACKUP}

SUP_UPDATE=yes
SUP=/usr/local/bin/cvsup
SUPFLAGS=-g -L 2
SUPHOST=cvsup.uk.FreeBSD.org
SUPFILE=/usr/src/supfile
PORTSSUPFILE=/usr/ports/ports-supfile
# added by use.perl 2005-06-23 10:21:11
PERL_VER=5.8.6
PERL_VERSION=5.8.6



# Kernel configuration

# $FreeBSD: src/sys/i386/conf/GENERIC,v 1.413.2.8 2004/10/24 17:42:08 
scottl Exp $


machine i386
cpu I686_CPU
ident   PE2650_i386_1

options MAXD

Re: FreeBSD MySQL still WAY slower than Linux

[Michael VInce]

I would just like to finish my own thoughts on the thread I created here 
for the sakes of other people who may be googling up this mailing list 
thread in the future and judging performance on this particular 
benchmark method.


I just wanted to point out that this benchmark test is using 50 
simultaneous connections doing thousands of querys at the same time,
I was thinking about performance always being a big issue but also the 
other factors that make a over all OS choice for the database.


For me I am using MySQL in my database app its usage of MySQL is quite 
different as it only uses 1 connection thread most of the time or 
sometimes a few connections doing querys at the same time.


The database app does an average of 600 querys a minute or 36,000 querys 
an hour, so its biggest difference is that it only uses 1 or 2 
persistent connections instead of 50, I think anyone should consider how 
many people are going to be doing a large amount simultaneous querys 
because this is where the MySQL people would of concentrated a lot of 
effort in making Linux succeed in this area since Linux is probably 
MySQLs biggest market is at this time.


If I was going to be doing mass cheap virtual php hosting and want to 
have everyone on the smallest amount of MySQL database installs as 
possible then I might choose a different OS, but if the difference 
between 25,000 querys/sec or 30,000 querys/sec could be over come by 
spending an extra couple of 100$ on getting a CPU that could go a extra 
400mhz higher that could over come the difference.
I look my total OS choice based on license and things like software 
upgrade ability point of view, I am quite happy with portupgrade and I 
can easily update any port on the system.


GPL is a riddle of a license and the only people who disagree always 
seem to be a riddle with in them selfs, maybe because they always just 
willing to accept straight out lies.
To me the possibility of handing over millions of dollars for a large 
Linux setup to SCO is a scary possible thought, and any company who is 
on the stock exchange or has private investment should be afraid.

http://news.zdnet.com/2100-3513_22-5167825.html
http://www.iseriesnetwork.com/nodeuk/ukarchive/index.cfm?fuseaction=viewarticle&CO_ContentID=18174
I believe that "lawyer death stars" powered by companies like MS can be 
a very powerful thing,  as far as I am concerned if things get in the 
way of the movement of technology which I ultimately GPL does, with its 
greed fueled riddle rules then these companies will aim to 'blow' it out 
of the way. Ultimately its always been private companies who have been 
the biggest movers of technology and they wont stand for things getting 
in the way.
If GPL was about technology then it would NOT be so eager to sue the 
hell out of companies who adopt GPL technologies into their products as 
they do, so as far as I am concerned the last thing GPL and FSF are 
about is technology. For every company FSF goes after there are 1,000s 
of others who have quietly take the same thing/code/whatever, GPLs 
greatest evil is the fact it creates a illusion of protection to 
software naive developers, there are no illusions,tricks or riddles 
under BSD.


I kind of screwed off the topic about MySQL performance, oh well, I 
guess there was something else building up in my mind that felt like 
coming out.

My rant is complete.
Thank you.


Michael Vince wrote:

I tried some benchmark testing on a Dell 1850 5.4-Release-P2 with 
generic kernel.
From what I have seen from your postings I was able to get a higher 
supersmack result, 23626.76 .

I compiled 4.0 MySQL with some optimizations
portupgrade -RN -m 'BUILD_STATIC=yes BUILD_OPTIMIZED=yes' 
/usr/ports/databases/mysql40-server/


Downloaded and installed the supersmack source from here 
http://vegan.net/tony/supersmack/super-smack-1.3.tar.gz

with just ./configure --with-mysql

Copied the default large my.cnf profile
cp /usr/local/share/mysql/my-large.cnf /var/db/mysql/my.cnf

# super-smack /usr/share/smacks/select-key.smack 50 1000
Query Barrel Report for client smacker1
connect: max=44ms  min=11ms avg= 20ms from 50 clients
Query_type  num_queries max_timemin_timeq_per_s
select_index10  3   0   23626.76

If I delete the /var/db/mysql/my.cnf and restart mysql so I get 
default configuration, I get 13398.76

# super-smack /usr/share/smacks/select-key.smack 50 1000
Query Barrel Report for client smacker1
connect: max=29ms  min=7ms avg= 17ms from 50 clients
Query_type  num_queries max_timemin_timeq_per_s
select_index10  7   0   13398.76

For me this is as fast as I need my database to be but I can 
understand there is a difference here between FreeBSD and Linux that 
would make you prefer it as the db OS choice.


Regards,
Mike

Steve Roome wrote:


On Sun, Jun 26, 2005 at 12:06:41AM +1000, Michael Vince wrote:
 

Your p

Re: changing max_connections in postgresql on FreeBSD 5.4

[Michael VInce]

Hi,

I have done all my Postgres optimization configuration via sysctl or the 
postgresql.conf no kernel recompilation was performed.
I did benchmarks at complete default FreeBSD / Postgres configuration 
and benchmarks after.


I found raising the values to probably not much more then 1/4 of what 
they are now list below gave around 30% increase in performance. But 
increase the numbers after that did nothing. I still left them way past 
the mark anyway because this server has 4gigs of ram that would other 
wise go to waste.
The Postgres DB setup here is only meant to handle a few connections at 
a time unlike yours.


sysctl.conf
kern.ipc.shmmax=1073741824
# x32 the default ( 8192 )
kern.ipc.shmall=262144

postgresql.conf
# shared_buffers = 108000 32 x default = 884,736,000 bytes
shared_buffers = 108000# min 16, at least 
max_connections*2, 8KB each


work_mem = 65536   # min 64, size in KB
max_stack_depth = 4096 # min 100, size in KB

max_fsm_pages = 4  # min max_fsm_relations*16, 6 bytes each
max_fsm_relations = 2000   # min 100, ~50 bytes each


Also note that I have a MySQL server with a similar table setup and it 
performs a lot better.


Claus Guttesen wrote:


Hi.

I recently lowered max_connections from 1024 to 384 in
/usr/local/pgsql/data/postgresql.conf. The server is a quad opteron @
2 GHz and 4 GB of RAM.

This decreased the SIZE and RES values in top and it seems that the
current max_connections is more than adequate. To see how many
concurrent connections the db-server had I did a 'netstat -na|grep -i
establi|wc -l' which showed some 230 established connections during
peak.

In order to use max_connections set to 1024 I had to raise the
following values in the kernel:

options SHMMAXPGS=327680
options SEMMNI=200
options SEMMNS=1200
options SEMUME=200
options SEMMNU=600

The values were taken from the postgresql-ports-installation-notes and
were simply increased to fit the max_connections-parameter in
postgresql.conf.

Will more RAM become available to postgresql if I change the
kernel-values mentioned above to half the size?

The server does occasionally become loaded with load-averages around 6
or 7 but usually stays below 4. Disk-io is not a problem, usually
remains below 1 MB/s, cpu-idle is approx. 5-10 % during peak and
around 80 % idle otherwise.

regards
Claus
___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
 



___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: SATA: RAID 5 controller recommendations

[Michael VInce]

For SATA I have always been getting the Dell 750s (now 850s) which use 
the 'aac'

Adaptec AdvancedRAID Controller driver, do 'man aac' for more details.
Dell supply them with a 64meg cache and are hardware raid, I have always 
just installed FreeBSD on them and only 1 hard drive comes up as RAID 
should be.


I have only been ordering the machines in dual drive mirror 1 Raid, but 
you could get a PowerEdge Tower servers like the 830 which do raid 5, I 
never used one though.
Alternatively all the Dell SCSI RAID systems have 256megs cache which 
use the LSI Logic MegaRAID ( man amr )
Stay away from the ultra low end SC1425 systems they have some kind of 
software based raid.


The thing I have noticed is that if you compare other (often claiming to 
be much cheaper) servers from other companies they often really skimp on 
their hard drive subsystems with software based stuff claiming its RAID.


I used to be anti Dell and build my own U1 servers from case and up and 
had a keen interest in cheap RAID technologies but I gave up a little 
while ago.
I believe Dell are great value when you consider their RAID 
implementations and as long as you are happy with Intel chips.


Mike

Steven Hartland wrote:


Anyone got any SATA RAID 5 controllers they can recommend
64Bit PCIX.

   Steve



This e.mail is private and confidential between Multiplay (UK) Ltd. 
and the person or entity to whom it is addressed. In the event of 
misdirection, the recipient is prohibited from using, copying, 
printing or otherwise disseminating it or any information contained in 
it.
In the event of misdirection, illegible or incomplete transmission 
please telephone (023) 8024 3137

or return the E.mail to [EMAIL PROTECTED]

___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to 
"[EMAIL PROTECTED]"



___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: SATA: RAID 5 controller recommendations

[Michael VInce]

[EMAIL PROTECTED] wrote:


At 07:29 AM 11/2/2005 -0500, Mike Tancsa wrote:
| At 05:47 AM 02/11/2005, Achim Patzner wrote:
| >>For SATA I have always been getting the Dell 750s (now 850s) which
| >>use the 'aac'
| >>Adaptec AdvancedRAID Controller driver, do 'man aac' for more details.
| >
| >Did you ever have to replace a failed drive? You might try it, just
| >to see if you're still happy afterwards.
| 
| Thats one thing I must say about 3ware that I really like.  I have 
| been using the cards for years now and have not had issues when it 
| came to swapping out  dead drives.  I havent had the opportunity to 
| do it with the ARECA yet in production to see how it works, only as a test.
| 
|  ---Mike 


Mike,

 Here is a link to the mysql benchmarks I was talking about.  If you can run
them using the 3ware raid and the other raid, I would be interested to see what
sort of results you get.  Feel free to contact me if you have any questions.

http://www.redshift.com/~ray/mysql_bench

 These are my personal benchmarks I use here, but I added a file to try to walk
you through stuff and in case you want to share them with anyone else, etc.  If
you have any questions, please feel free to e-mail me.  


Take care!

Ray

 


I would like to give it a shot but don't really have time at the moment.
I might do it sometime in the future though.

Thanks anyway.

Mike

___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: SATA: RAID 5 controller recommendations

[Michael VInce]

I have seen some network based SMP related performance problems vanish 
in 6.0 tests, admittedly I haven't done hard drive based tests but I 
wouldn't surprise me of performance drops on HDs in SMP on 6.0 are gone 
as well.


Mike


Markus Kovero wrote:

Dell's CERC sata raid thingy works fast for me but when I turn SMP on 
read  performance drops 50%+ (raid1,raid5,raid10 and single volumes).

I don't know if its aac problem or what.
In leenox it works very well though.

Yours
Markus Kovero

[EMAIL PROTECTED] wrote:


At 09:17 PM 11/2/2005 +1100, Michael VInce wrote:
| For SATA I have always been getting the Dell 750s (now 850s) which 
use | the 'aac'

| Adaptec AdvancedRAID Controller driver, do 'man aac' for more details.
| Dell supply them with a 64meg cache and are hardware raid, I have 
always | just installed FreeBSD on them and only 1 hard drive comes 
up as RAID | should be.
| | I have only been ordering the machines in dual drive mirror 1 
Raid, but | you could get a PowerEdge Tower servers like the 830 
which do raid 5, I | never used one though.
| Alternatively all the Dell SCSI RAID systems have 256megs cache 
which | use the LSI Logic MegaRAID ( man amr )
| Stay away from the ultra low end SC1425 systems they have some kind 
of | software based raid.
| | The thing I have noticed is that if you compare other (often 
claiming to | be much cheaper) servers from other companies they 
often really skimp on | their hard drive subsystems with software 
based stuff claiming its RAID.
| | I used to be anti Dell and build my own U1 servers from case and 
up and | had a keen interest in cheap RAID technologies but I gave up 
a little | while ago.
| I believe Dell are great value when you consider their RAID | 
implementations and as long as you are happy with Intel chips.

| | Mike
| | Steven Hartland wrote:
| | > Anyone got any SATA RAID 5 controllers they can recommend
| > 64Bit PCIX.
| >
| >Steve

Steve - 3ware is very good.

Mike - I have some benchmarks from a guy using a Dell with a raid and 
was
surprised to see how slow they were compared to our other hardware.  
I didn't
run them myself, but the guy is on the list here some place.  I can 
send you a

copy of the spreadsheet if you want to look it over.

Ray

___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to 
"[EMAIL PROTECTED]"
 




___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Poor Samba throughput on 6.0

[Michael Vince]

Joao Barros wrote:


Hi,

Last month I started a thread[1] on current@ about this, but I guess I
should have done it here, my apologies for that.

After my initial post I did some more testing and I'm going to start
clean here with all my findings :)

I started with Samba 3 installed on a PIII 733MHz with fxp (82559) and
a RAID5 consisting of 4 drives connected to an amr.
Performance reading or writing was poor, around 5.5MB/s measured on
two Windows clients and iostat never topped that by much.
cpu was mbufs were available and there were no IRQs shared.
To dismiss the amr out of the question I tried with a local IDE
attached yielding the same results.
I then tested the same on a machine I have at work, an HP Proliant
server, Pentium 4 3.06GHz, used SMP instead of GENERIC to use HTT.
I could get 8MB/s with 2 read or write simultaneous operations. With 1
operation I still can only get 6MB/s
This machine has 1GB ram and after copying a 700MB file to it it was all cached.
A copy to dev/null took 1 second.
A copy via samba took the same time as if there was no cache for it.
iostat always showed 0.0 during the operation so that pretty much
takes disks, controllers, IO out of the picture.

Both machines have cpu, IO and mbufs to spare and they still can't use
them. Why?


[1] http://lists.freebsd.org/pipermail/freebsd-current/2005-October/057116.html

--
Joao Barros
___
 

Sometime in the near future I will be building a Samba3 server and I 
plan to get everything I can get out of it, I expect to uncover a lot of 
needed tweaks to get it going fast.
My guess would be to you try at least turning on polling, also if its 
only 100mbit Ethernet/switches you got then I guess you cant expect much 
either.


Mike

___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: new benchmarks. WAS: FreeBSD MySQL still WAY slower than Linux

[Michael Vince]

It would be good to actually see the Linux performance on the exact same 
hardware, all we ever see is how it is on FreeBSD.


MySQL has very frequent use of queries of the system time and is well 
known in FreeBSD to be slower because its more expensive to call 
compared to Linux, which has less precision time.
If you are on modern hardware you might want to try changing from 
kern.timecounter.hardware: ACPI-fast to TSC(-100) and doing a benchmark 
this has already proven to increase performance of MySQL by a 
significant amount.


Also some new experimental low-precision time code has been added to 
current source tree to see how much performance increases can be gained 
some people are against it and I don't know if its usable for tests yet.


Mike


Gustavo A. Baratto wrote:

following  Steve Roome's benchmarks from a few months ago, here it 
goes a few more, on freebsd 6.0 RELEASE, using libpthreads (system, 
and process scopes), libthr, and linuxthreads. Unless otherwise 
specified, the my.cnf values are the ones posted below. Dmesg, and 
diff of the kernel compared with GENERIC are posted in the end as 
well. File systems are mounted as default (no fancy mount opts):


# more /etc/fstab
# DeviceMountpoint  FStype  Options Dump 
Pass#

/dev/da0s1b noneswapsw  0   0
/dev/da0s1a /   ufs rw  1   1
/dev/da0s1d /tmpufs rw  2   2
/dev/da0s1e /varufs rw  2   2
/dev/da0s1f /home   ufs rw  2   2
/dev/acd0   /cdrom  cd9660  ro,noauto   0   0
---

Cheers all


 lipthread: standard
# date; for i in 1 2 3 4 5; do super-smack select-key-mysql.smack 10 
1000 | grep select_index; done; date

Wed Nov 30 16:20:52 EST 2005
select_index2   0   0   14570.99
select_index2   2   0   14787.32
select_index2   3   0   14621.65
select_index2   1   0   13554.19
select_index2   0   0   13514.42
Wed Nov 30 16:20:59 EST 2005

date; for i in 1 2 3 4 5; do super-smack select-key-mysql.smack 10 
1000 | grep select_index; done; date

Wed Nov 30 22:45:37 EST 2005
select_index2   1   0   14567.60
select_index2   0   0   13745.24
select_index2   1   0   13625.50
select_index2   0   0   13558.84
select_index2   1   0   13460.09
Wed Nov 30 22:45:45 EST 2005




 lipthread:  LIBPTHREAD_PROCESS_SCOPE=yes
# date; for i in 1 2 3 4 5; do super-smack select-key-mysql.smack 10 
1000 | grep select_index; done; date

Wed Nov 30 16:37:16 EST 2005
select_index2   2   0   12014.51
select_index2   2   0   11991.61
select_index2   0   0   10890.61
select_index2   1   0   11992.41
select_index2   3   0   11775.37
Wed Nov 30 16:37:24 EST 2005

date; for i in 1 2 3 4 5; do super-smack select-key-mysql.smack 10 
1000 | grep select_index; done; date

Wed Nov 30 22:49:40 EST 2005
select_index2   1   0   11035.18
select_index2   4   0   11877.35
select_index2   0   0   10097.29
select_index2   0   0   10765.29
select_index2   1   0   11401.68
Wed Nov 30 22:49:50 EST 2005




 libthr:
# more /etc/libmap.conf
[mysqld]
libpthread.so.2 libthr.so.2
libpthread.so   libthr.so

# ldd /usr/local/libexec/mysqld
/usr/local/libexec/mysqld:
   libz.so.3 => /lib/libz.so.3 (0x881f8000)
   libcrypt.so.3 => /lib/libcrypt.so.3 (0x88208000)
   libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x8822)
   libm.so.4 => /lib/libm.so.4 (0x882ea000)
   libpthread.so.2 => /usr/lib/libthr.so.2 (0x8830)
   libc.so.6 => /lib/libc.so.6 (0x88312000)

# date; for i in 1 2 3 4 5; do super-smack select-key-mysql.smack 10 
1000 | grep select_index; done; date

Wed Nov 30 16:38:45 EST 2005
select_index2   0   0   15789.56
select_index2   1   0   14804.51
select_index2   0   0   14810.69
select_index2   0   0   14600.25
select_index2   0   0   14478.79
Wed Nov 30 16:38:52 EST 2005

# date; for i in 1 2 3 4 5; do super-smack select-key-mysql.smack 10 
1000 | grep select_index; done; date

Wed Nov 30 22:47:26 EST 2005
select_index2   1   0   14375.95
select_index2   0   0   14392.69
select_index2   0   0   14478.93
select_index2   0   0   14371.66
select_index2   0   0   14416.07
Wed Nov 30 22:47:33 EST 2005




 linuxthreads
# ldd /usr/local/libexec/mysqld
/usr/local/libexec/mysqld:
   liblthread.so.3 => /usr/local/lib/liblthread.so.3 (0x88201000)
   liblstdc++.so.5 => /usr/local/lib/libl

More threads

[Michael Vince]

Hi All,

I been benchmarking a Java servlet I have created and I want to be able 
to handle a massive amount of simultaneous connections.
So far using benchmarking tools I have been able to get around 2,565 
threads on the Tomcat 5.5 Java process (with native 1.4.2 Java) 
according to ps -auxwH | grep -c 'java'


But I just can't seem to get past that mark, I have a lot of memory 
currently the Tomcat is allocated 2gigs of memory.


When I max it out with my benchmarks I get this in catalina Tomcat 5.5 
but there is still plenty of free memory to the Tomcat process.
SEVERE: Caught exception (java.lang.OutOfMemoryError: unable to create 
new native thread) executing [EMAIL PROTECTED], 
terminatingthread


I have been testing with my libmap.conf with these different types of 
implementations.


[/usr/local/jdk1.4.2/]
#libpthread.so   libc_r.so
#libpthread.so.2   libc_r.so.6
libpthread.so.2 libthr.so.2
libpthread.so   libthr.so
libc_r.so.6 libthr.so.2
libc_r.so   libthr.so

I have been getting the best performance with libthr and have been using 
the above libthr and with these settings below.


I have set my max_threads in /etc/sysctl.conf to a massive amount.

kern.threads.max_threads_per_proc=4
kern.threads.max_groups_per_proc=4

ps -auxwH | grep -c 'java'
2565

I am using Apache2.2 with the new built in AJP module which has been a 
great addition to Apache 2.2.
I have been able to get the setup performing most stable (no 503 status 
errors) but with less performance / threads with the libmap.conf below.

[/usr/local/jdk1.4.2/]
libpthread.so   libc_r.so
libpthread.so.2   libc_r.so.6

I am on 6.0 Release i386, dual Intel P4, generic SMP kernel.

With Tomcat on Windows XP I have been able to get it running better.
Does any one know of some other sysctls that increase the amount of 
threads in libthr which I am assuming utilizes the above sysctls. Does 
any one know how many threads can be created in Java on FreeBSD?


Cheers,
Mike





___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Benchmark MySQL Performance On FreeBSD And Linux

[Michael Vince]

Chris wrote:


Make sure your compile your MySQL dynamically which is done by default,
if you include 'BUILD_STATIC=yes' you ruin your ability to change
threading libs.

portupgrade -N  -m 'BUILD_OPTIMIZED=yes'
/usr/ports/databases/mysql41-server
Or upgrade
portupgrade -R  -m 'BUILD_OPTIMIZED=yes'/var/db/pkg/mysql-server-4.1.14


Use 'ldd' to find which threading library you are using.

ldd /usr/local/libexec/mysqld
/usr/local/libexec/mysqld:
  libz.so.3 => /lib/libz.so.3 (0x800978000)
  libwrap.so.4 => /usr/lib/libwrap.so.4 (0x800a8b000)
  libcrypt.so.3 => /lib/libcrypt.so.3 (0x800b94000)
  libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x800cad000)
  libm.so.4 => /lib/libm.so.4 (0x800ea4000)
  libpthread.so.2 => */usr/lib/libpthread.so.2* (0x800fc)
  libc.so.6 => /lib/libc.so.6 (0x8010eb000)

Put something like this into your /etc/libmap.conf to change your
threading library, and restart the service in question for the library
change to take effect.
[/usr/local/libexec/mysqld]
libpthread.so.2 libthr.so.2
libpthread.so   libthr.so

# ldd /usr/local/libexec/mysqld
/usr/local/libexec/mysqld:
  libz.so.3 => /lib/libz.so.3 (0x800978000)
  libwrap.so.4 => /usr/lib/libwrap.so.4 (0x800a8b000)
  libcrypt.so.3 => /lib/libcrypt.so.3 (0x800b94000)
  libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x800cad000)
  libm.so.4 => /lib/libm.so.4 (0x800ea4000)
  libpthread.so.2 => */usr/lib/libthr.so.2* (0x800fc)
  libc.so.6 => /lib/libc.so.6 (0x8010d7000)



Ok thanks just 2 more questions.
   



(a) if I build dynamic there is no performance penalty? since the Makefile
states build static for performance.
(b) I have no /etc/libmap.conf it doesnt exist, so if I just create one and
enter what you say it will work?

Chris
 


Yes check the URL below
http://dev.mysql.com/doc/refman/4.1/en/compile-and-link-options.html
The first line of the Optimizing the MySQL Server 
 in 
the Compiling section says

"You obtain the fastest executables when you link with |-static|."
And then again further down

" If you link dynamically (without |-static|), the result is 13% slower 
on Linux. Note that you still can use a dynamically linked MySQL library 
for your client applications. It is the server that is most critical for 
performance."


It would be great if some one could do the benchmarks on FreeBSD to 
verify that.


(b) I have no /etc/libmap.conf it doesnt exist, so if I just create 
one and enter what you say it will work?



Yes, its never there by default so just create it.
FYI there is a man page on libmap.conf

Mike
___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Benchmark MySQL Performance On FreeBSD And Linux

[Michael Vince]

huang leo wrote:


Hi, all:

We had evaluated MySQL performance on FreeBSD and Linux. The result is
attached.

We are longing for your feedbacks!


Best regards,

Leo Huang


Really good work.

I gave your results some thought and was thinking that maybe you should 
check to see if you reached the default 1500 threading limit  of libthr 
and maybe it needs to be increased, I set mine to 4 like below.

kern.threads.max_threads_per_proc=4
kern.threads.max_groups_per_proc=4

I was thinking it would be good to show threading usage activity with 
some kind of 1 second loop doing ps -auxwH | grep -c 'mysql' or 
something like that so we could see what limits its getting to, and so I 
can have an idea of what I can compare it to on my own servers.


Just a suggestion.

Regards,
Mike


___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Benchmark MySQL Performance On FreeBSD And Linux

[Michael Vince]

Chris wrote:


On 01/01/06, Michael Vince <[EMAIL PROTECTED]> wrote:
 


huang leo wrote:

   


Hi, all:

We had evaluated MySQL performance on FreeBSD and Linux. The result is
attached.

We are longing for your feedbacks!


Best regards,

Leo Huang

 


Really good work.

I gave your results some thought and was thinking that maybe you should
check to see if you reached the default 1500 threading limit  of libthr
and maybe it needs to be increased, I set mine to 4 like below.
kern.threads.max_threads_per_proc=4
kern.threads.max_groups_per_proc=4

I was thinking it would be good to show threading usage activity with
some kind of 1 second loop doing ps -auxwH | grep -c 'mysql' or
something like that so we could see what limits its getting to, and so I
can have an idea of what I can compare it to on my own servers.

Just a suggestion.

Regards,
Mike
   




Well sorry if I am completely wrong here, but that test seems to indicate
there is a general stability problem with libpthread.  My own experience
backs up their results since on a production web server with heavy forums I
have had mysql lockups until I tinkered with the threading settings. 

Personally I was surprised by this statement that libpthread wasn't 
working for his test, for me it does benchmark a tad slower but I have 
always seen libpthread as the most stable threading library.


libthr doesn't work very well at all under amd64 in Java benchmarks 
(Java will core in a few minutes of usage) while pthread is much more 
reliable.



I am confused now as their is very little documentation on this, google
throws up barely anything and my main concern is stability.

Chris
 

I believe the best thing to do is always just benchmark and use whats 
best for you, there is no guarantee with this stuff.


BTW I did a few super smack tests and saw that the thread numbers 
doesn't appear to reach thread numbers above 1500 but I only tested with 
smaller client numbers.


Mike




___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: mysql performance tuning @ FreeBSD6

[Michael Vince]

Joao Barros wrote:


On 1/26/06, Mike Jakubik <[EMAIL PROTECTED]> wrote:
 


Rich Murphey wrote:
   


I'm curious whether Robert's patch might have an
effect on samba3 performance as well.
 


No real difference here, tried ACPI-fast, i8254, and TSC. :( My
transfers still average at 10MB/s (although it did peak at 20MB/s once)
Which is really horrible for a em gigabit link with jumbo frames
enabled. The performance of Samba on FreeBSD just stinks, for unknown
reasons.
   



No real difference here too...

I started a thread on that subject not long ago and following Robert's
tip setting net.inet.tcp.inflight.enable=0 yielded better results.

--
Joao Barros
___
 


With the new TCP/IP stack replacement and major updates to the em driver in 
FreeBSD -current this should all turn around. I believe I saw a cvs commit for 
em a little while ago saying the new em driver can achieve higher transfer 
rates then using em with polling enabled.
Hopefully this stuff will make it into 6.1-Release

Mike






___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: packet drop with intel gigabit / marwell gigabit

[Michael Vince]

I use netperf which is a pure network traffic tester I also just use 
basic 'ab/apache' tests which would also test HD/IO if getting large files.
For the 'em' driver I have seen some posts/cvs commit updates to the 
driver saying it now works better without polling then with polling. I 
think this is in -stable but it might just be in current. I haven't done 
any testing for a while.




OxY wrote:


i changed sk to em.
how could i measure speed or benchmark the network performance?

- Original Message - From: "Bjoern A. Zeeb" 
<[EMAIL PROTECTED]>

To: "OxY" <[EMAIL PROTECTED]>
Cc: ; 
Sent: Sunday, March 19, 2006 7:26 PM
Subject: Re: packet drop with intel gigabit / marwell gigabit



On Sun, 19 Mar 2006, OxY wrote:

Hi,

Just on a hunch, can you try putting the card in a different PCI  
slot? There may be interrupt routing issues.



okay, i will try it in a couple days



the card also has a sysctl for intr moderation. See man 4 sk. The
default changed with Pyun's updated driver, I think, but you could
play with that too.

Further I still have the feeling that your measurings are not
comparable.

--
Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 



___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"



___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: mysql performance on 4 * dualcore opteron

[Michael Vince]

I just ran a test on 6_stable (April 5th) on a Dell 2850 dual CPU 
(single core 3.60GHz) using the AMD64 build of FreeBSD and got similar 
speeds as you.
Its interesting how Sven could have 8 cores with what appears to be less 
MySQL speed then just having a few cores.
After enabling libthr it does jump by about 3,600 on a generic SMP 
kernel compile, I didn't try any more serious tweaks.


For those who are interested in exactly how I tested wheres what I did.

portupgrade -RN  -m 'BUILD_OPTIMIZED=yes WITH_PROC_SCOPE_PTH=yes' 
/usr/ports/databases/mysql41-server

portupgrade -RN /usr/ports/benchmarks/super-smack

super-smack -d mysql /usr/local/share/super-smack/select-key.smack 10 1
Query Barrel Report for client smacker1
connect: max=4ms  min=1ms avg= 2ms from 10 clients
Query_type  num_queries max_timemin_timeq_per_s
select_index20  0   0   22061.88

With this below in my /etc/libmap.conf for libthr and a MySQL restart 
/usr/local/etc/rc.d/mysql-server restart the numbers do jump.

[/usr/local/libexec/mysqld]
libpthread.so.2 libthr.so.2
libpthread.so   libthr.so


super-smack -d mysql /usr/local/share/super-smack/select-key.smack 10 1
Query Barrel Report for client smacker1
connect: max=238ms  min=0ms avg= 117ms from 10 clients
Query_type  num_queries max_timemin_timeq_per_s
select_index20  0   0   25601.49

I have also done benchmarking with libthr against Apache using 'ab' and 
found it can deliver an extra amount of megabytes/sec of data (I think 
it was about an extra 2000/requests sec) at the cost of giving the 
server from what I remember almost double the 'average load' according 
to 'top'
Given that if your machine has nothing else to do but deliver data 
purely from Apache then even libthr is more worth while for Apache as well.


Mike

Steven Hartland wrote:
Looking at this on a dual box here ( waiting for the new MB for dual 
dual core )

All the time is spent processing super-smack and only 25% on mysqld.
Even dropping to 10 clients a large portion is take by the clients.
That said there is a lot that can be gained by using the tweaks out there
i.e. ULE + libthr + TSC + context_time.patch + cpu_acct_1.patch + 
cpu_acct_2.patch

Adding these jumps from a baseline:
select_index200 8   0   18624.60
to:
select_index200 5   0   29942.10

The biggest increases coming from libthr ( thanks DavidXu ) and the ULE
scheduler.

[log]
== 4BSD + libpthread + ACPI-Fast ==
super-smack -d mysql select-key.smack 100 1
Query Barrel Report for client smacker1
connect: max=46ms  min=6ms avg= 25ms from 100 clients Query_type  
num_queries max_timemin_timeq_per_s

select_index200 8   0   18624.60

super-smack -d mysql select-key.smack 10 10
Query Barrel Report for client smacker1
connect: max=5ms  min=0ms avg= 1ms from 10 clients Query_type  
num_queries max_timemin_timeq_per_s

select_index200 0   0   23983.87

== 4BSD + libthr + ACPI-Fast  ==
super-smack -d mysql select-key.smack 100 1
Query Barrel Report for client smacker1
connect: max=107ms  min=2ms avg= 45ms from 100 clients Query_type  
num_queries max_timemin_timeq_per_s

select_index200 13  0   22413.39

super-smack -d mysql select-key.smack 10 10
Query Barrel Report for client smacker1
connect: max=2ms  min=1ms avg= 1ms from 10 clients Query_type  
num_queries max_timemin_timeq_per_s

select_index200 0   0   26841.07

== 4BSD + libthr + TSC ==
super-smack -d mysql select-key.smack 100 1
Query Barrel Report for client smacker1
connect: max=46ms  min=1ms avg= 21ms from 100 clients Query_type  
num_queries max_timemin_timeq_per_s

select_index200 11  0   23428.03

super-smack -d mysql select-key.smack 10 10
Query Barrel Report for client smacker1
connect: max=2ms  min=0ms avg= 1ms from 10 clients Query_type  
num_queries max_timemin_timeq_per_s

select_index200 0   0   26403.95

== ULE + libthr + TSC ==
super-smack -d mysql select-key.smack 100 1
Query Barrel Report for client smacker1
connect: max=41ms  min=0ms avg= 23ms from 100 clients Query_type  
num_queries max_timemin_timeq_per_s

select_index200 5   0   28581.18

super-smack -d mysql select-key.smack 10 10
Query Barrel Report for client smacker1
connect: max=4ms  min=0ms avg= 1ms from 10 clients Query_type  
num_queries max_timemin_timeq_per_s

select_index200 0   0   30128.44

== ULE + libthr + TSC + context_time.patch + cpu_acct_1.patch + 
cpu_acct_2.patch ==

super-smack -d mysql select-key.smack 100 1
Query Barrel Report for client smacker1
connect: max=27ms  min=0ms avg= 14ms from 100 clients Query_type  
nu

Re: mysql performance on 4 * dualcore opteron

[Michael Vince]

David Xu wrote:


ÔÚ Thursday 06 April 2006 17:12£¬Michael Vince дµÀ£º

 

I have also done benchmarking with libthr against Apache using 'ab' and 
found it can deliver an extra amount of megabytes/sec of data (I think 
it was about an extra 2000/requests sec) at the cost of giving the 
server from what I remember almost double the 'average load' according 
to 'top'
Given that if your machine has nothing else to do but deliver data 
purely from Apache then even libthr is more worth while for Apache as well.


Mike
   



libpthread default uses M:N threads which means a thread  may be on
userland scheduler's run queue, and FreeBSD kernel does not know, 
so it will be not shown on average load, default system tools are not

very useful here.

David Xu
 

Yeah I figured that, which isn't fair because it makes pthread look 
better then libthr when its not.


I did notice that during the tests that when benchmarking Apache under 
libthr that when it was giving out the extra megabytes/sec speed that 
the server did feel equally responsive even though 'top' was reporting 
higher load.


I have also tried putting my Perl under libthr for a single thread log 
analyzer and to my surprise it even could process logs faster.


libthr is also really useful for actually paying attention to tops 'thr' 
column since it does show actual true thread number activity, under 
pthread it shows a couple and under libc_r I could have 1000 threads 
going but top just shows 1.


Mike








___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: mysql performance on 4 * dualcore opteron

[Michael Vince]

Michael Vince wrote:

I just ran a test on 6_stable (April 5th) on a Dell 2850 dual CPU 
(single core 3.60GHz) using the AMD64 build of FreeBSD and got similar 
speeds as you.
Its interesting how Sven could have 8 cores with what appears to be 
less MySQL speed then just having a few cores.
After enabling libthr it does jump by about 3,600 on a generic SMP 
kernel compile, I didn't try any more serious tweaks.


For those who are interested in exactly how I tested wheres what I did.

portupgrade -RN  -m 'BUILD_OPTIMIZED=yes WITH_PROC_SCOPE_PTH=yes' 
/usr/ports/databases/mysql41-server

portupgrade -RN /usr/ports/benchmarks/super-smack

super-smack -d mysql /usr/local/share/super-smack/select-key.smack 10 
1

Query Barrel Report for client smacker1
connect: max=4ms  min=1ms avg= 2ms from 10 clients
Query_type  num_queries max_timemin_timeq_per_s
select_index20  0   0   22061.88

With this below in my /etc/libmap.conf for libthr and a MySQL restart 
/usr/local/etc/rc.d/mysql-server restart the numbers do jump.

[/usr/local/libexec/mysqld]
libpthread.so.2 libthr.so.2
libpthread.so   libthr.so


super-smack -d mysql /usr/local/share/super-smack/select-key.smack 10 
1

Query Barrel Report for client smacker1
connect: max=238ms  min=0ms avg= 117ms from 10 clients
Query_type  num_queries max_timemin_timeq_per_s
select_index20  0   0   25601.49

Interestingly I just did a install of i386 FreeBSD 6.1RC1 and installed 
a PAE kernel (for 6gigs of ram) on this very same server (which had 
AMD64 FreeBSD on before hand) and run the exact same tests and its now a 
good deal slower!


# super-smack -d mysql /usr/local/share/super-smack/select-key.smack 10 
1

Query Barrel Report for client smacker1
connect: max=3ms  min=2ms avg= 2ms from 10 clients
Query_type  num_queries max_timemin_timeq_per_s
select_index20  0   0   19234.02


And without libthr its even slower
# super-smack -d mysql /usr/local/share/super-smack/select-key.smack 10 
1

Query Barrel Report for client smacker1
connect: max=100ms  min=22ms avg= 60ms from 10 clients
Query_type  num_queries max_timemin_timeq_per_s
select_index20  0   0   16583.43

Does any one have any explanation of this?

Mike


I have also done benchmarking with libthr against Apache using 'ab' 
and found it can deliver an extra amount of megabytes/sec of data (I 
think it was about an extra 2000/requests sec) at the cost of giving 
the server from what I remember almost double the 'average load' 
according to 'top'
Given that if your machine has nothing else to do but deliver data 
purely from Apache then even libthr is more worth while for Apache as 
well.


Mike

Steven Hartland wrote:

Looking at this on a dual box here ( waiting for the new MB for dual 
dual core )

All the time is spent processing super-smack and only 25% on mysqld.
Even dropping to 10 clients a large portion is take by the clients.
That said there is a lot that can be gained by using the tweaks out 
there
i.e. ULE + libthr + TSC + context_time.patch + cpu_acct_1.patch + 
cpu_acct_2.patch

Adding these jumps from a baseline:
select_index200 8   0   18624.60
to:
select_index200 5   0   29942.10

The biggest increases coming from libthr ( thanks DavidXu ) and the ULE
scheduler.

[log]
== 4BSD + libpthread + ACPI-Fast ==
super-smack -d mysql select-key.smack 100 1
Query Barrel Report for client smacker1
connect: max=46ms  min=6ms avg= 25ms from 100 clients Query_type  
num_queries max_timemin_timeq_per_s

select_index200 8   0   18624.60

super-smack -d mysql select-key.smack 10 10
Query Barrel Report for client smacker1
connect: max=5ms  min=0ms avg= 1ms from 10 clients Query_type  
num_queries max_timemin_timeq_per_s

select_index200 0   0   23983.87

== 4BSD + libthr + ACPI-Fast  ==
super-smack -d mysql select-key.smack 100 1
Query Barrel Report for client smacker1
connect: max=107ms  min=2ms avg= 45ms from 100 clients 
Query_type  num_queries max_timemin_timeq_per_s

select_index200 13  0   22413.39

super-smack -d mysql select-key.smack 10 10
Query Barrel Report for client smacker1
connect: max=2ms  min=1ms avg= 1ms from 10 clients Query_type  
num_queries max_timemin_timeq_per_s

select_index200 0   0   26841.07

== 4BSD + libthr + TSC ==
super-smack -d mysql select-key.smack 100 1
Query Barrel Report for client smacker1
connect: max=46ms  min=1ms avg= 21ms from 100 clients Query_type  
num_queries max_timemin_timeq_per_s

select_index200 11  0   23428.03

super-smack -d mysql select-key.smack 10 10
Query Barrel Report for 

Re: Dual-core CPU vs. very large cache

[Michael Vince]

Yes I was going to point out a article from Anandtech as well.

Its an older one but someone on Anandtech is a SQL performance article 
benchmarking different server CPUs on Database performance.

It concluded that large CPU cache is very important for Databases.
Basically said having a large CPU cache it helped performance more for 
databases then most things they ever benchmark such as benchmark 
differences shown in Office apps and multimedia tests.


The AMD Opterons are real performance leaders ATM right now no doubt.
I also understand why you must get Dell, some of the other hardware 
suppliers are just to hard to deal with, I tried to get a Opteron server 
out of HP and after about 1 month of getting excuses about CPU shortages 
etc I went back to Dell.
Off topic here is a kind of cool article I think a lot of people can 
identify with, http://joyeur.com/2006/03/20/the-sun-doesnt-shine-on-me


Mike


Steven Hartland wrote:


Forget Intel and go for AMD who beat them hands down for DB work:
http://www.anandtech.com/IT/showdoc.aspx?i=2745

- Original Message - From: "Bill Moran" 
<[EMAIL PROTECTED]>



Our current Dells have 2M cache, and I'm trying to determine whether
the 8M cache will make a significant difference or not.  Can someone
recommend a testing procedure for determining whether adding cache is
worthwhile or not?  I can simulate a test load at any time, but I
don't know how to tell whether the cache is the bottleneck of the
CPU or not.




___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: (Another) simple benchmark

[Michael Vince]

Interesting that the linux you are claiming to use would use prefork
Apache as default, while this is the default on FreeBSD I would think
the threaded worker would be used on a lot of linux dists, since they 
don't have the option to easily rebuild it.


Even if it is using prefork, the Linux Apache conf prefork settings
already are set higher, the start up server is 8 and has a higher max
spare server setting of 20 (double the setting of default FreeBSD
setting), I have found that ab is a kind of weird program and initial
settings of the Apache server (its ability to initially respond) do
adversely affect its ability to do the ab benchmark for some reason.

Considering you are trying to initiate 100 connections at the same time
with a prefork server that even one the better configured Linux side
(with 8 initial servers which would quickly jump to 13) its not a very
valid benchmark setup, especially with the unforgiving ab benchmark tool

Something else you should look at when using Apache on FreeBSD is the
Apache accept kernel module to save context switches which is aimed  at
increasing performance.
man accf_http

Sometimes I look at the ab program as something that better shows off
the abilities of the Zeus server considering that the ab benchmark tool
doesn't have some sane benchmark options such as constant connection
rate modes unlike programs like 'httperf' do (which is in the ports tree)

Such simple settings such as prefork might work fine for people running
a simple CGI site or a PHP site (if there not going to load zend
performance modules or use the encoder), if you have done benchmarks on
PHP its surprisingly slow technology, on top of the fact that PHP folk
recommend nothing other then prefork mode with PHP.

If I was working on a project such as Apache I know I wouldn't be
concentrating of performance with prefork in this day when threaded
modes are where Apache has been aiming for modern high performance web
serving for a fair while now.

Mike


Ivan Voras wrote:

Sorry, I forgot about performance@ mailing list, moving the discussion 
there - please use performance at freebsd.org or equivalent address 
when replying (and drop current@).


Steve Hodgson wrote:


Ivan Voras wrote:


Today I had the opportunity to experiment for a short time with a
4-CPU Xeon machine with hyperthreading (-> 8 logical CPU-s) and 3GB
RAM. In absence of anything smarter to do, I installed WBEL 3 Linux
(non-RedHat version of RedHat Enterprise Linux) which was accidentally
on the table and after toying around I've run a simple benchmark - ab
(apachebench, included by default with apache server) over localhost
to a local apache2 server, on a static home-page file. The command
line was "ab -n 10 -c 100 http://localhost/";. Since I still had
time with the machine, I then downloaded and installed FreeBSD 6.1 to
try to beat the score. Unfortunately, not only I couldn't beat the
score, but the results were *extremely* bad. Since I'm still not sure
it isn't my fault, I won't post the actual results, but I wonder...

Apache is a well known server-grade product, which doesn't use
threading (it was preforked in both systems), doesn't call
gettimeofday() constantly, uses sendfile(), and in short, is very
different from MySQL. It shouldn't behave this badly on FreeBSD.

Some observations from the benchmark runs:
- Linux was maxed out with ~50% total idle time, each logical
processor (hyperthreading was enabled) had ~25% user + ~25% sys time.
It still delivered order-of-magnitude better results. WBEL3 uses Linux
2.4.x kernel (i.e. old kernel)
- FreeBSD CPU time was 100% spent, with 90%-95% spent in sys time
- On FreeBSD, enabling hyperthreading got me a slowdown of *4x* over
the initial (bad) results (some slowdown is not surprising, 4x
slowdown is).
- Linux "load average" never went above 8, FreBSD's went > 60; this
could be just a difference in accounting, or it could not - I don't 
know.


What is needed to reproduce this simple benchmark:
- SMP machine, the more CPUs the better
- installed software: only apache20. The "ab" benchmark is included in
it. Leave apache's default configuration as-is (i.e. preforked, max
150 parallel clients allowed)
- A simple static HTML page (Apache's default "welcome, but this site
is not configured" should be ok).
- my invocation of "ab" was with "-n 10 -c 100" ; the (n)umber of
requests could be modified to fit local CPU speed, but (c)oncurrency
shouldn't (100 parallel requests is not uncommon).



Apache may not use gettimeofday, but ab certainly does. here is a truss
output of ab:...



I don't think this would result in 90% time being spent in sys with 
large load averages.



A fairer test would be to use ab on a second box and keep ab on the same
OS - you're changing two things at once here. You're also at the mercy
of how the scheduler places the processes across the different CPU's
(since there is one ab process and multiple httpd processes). Why was
Linux stuck at 50% utili

Re: (Another) simple benchmark

[Michael Vince]

Ivan Voras wrote:


Michael Vince wrote:


Interesting that the linux you are claiming to use would use prefork
Apache as default, while this is the default on FreeBSD I would think
the threaded worker would be used on a lot of linux dists, since they 
don't have the option to easily rebuild it.



"Professional" Linux distributions such as RedHat Enterprise Linux &
Debian have avoided threaded apache for a long time. One of the reasons
for this is that PHP doesn't work well with threaded server. Now, most
have two separate packages - apache-preforked and apache-threaded and
users can pick one (though preforked is still the default).

What I am trying to say here is you are expecting good performance out 
of things like CGI/PHP and prefork,
I don't think anyone should see these types of systems under that light, 
they are for convenience and cheap and reliable hosting.
PHP is 'deliberately' made slow (magnitudes slow) to encourage Zend 
optimizer module installs which to give magnitudes more performance, and 
then there is the sales on their 300% performance increase giving Zend 
Encoder suite.  PHP have created a good open source business model, but 
I don't think its really worthy of the word professional.


The average prefork httpd daemon with PHP takes 14megs of memory, I 
don't think any one can argue that serving 2,000 clients at the same 
time is feasible considering it would need a close 28gigs of ram, to 
hold that many httpd daemons on a "Professional" linux server.
I don't see it as a any kind of "professional" server, its more just a 
dive for pleasing the masses just like PHP and CGI to fit the market.


To get the amount of connections you are after with 'ab' in real world 
situations would insane amounts of ram because the connections would 
take a long longer to complete over the Internet considering all the 
dialup and low end adsl connections out there, and web clients would be 
loading pages bigger then the default Apache installation page, and 
considering it might be a professional solution using PHP it would 
probably be long page loads.


Configuring a Apache server that has 'ready' 5 http daemons when its 
really expecting to do 100,000 requests and handle huge amounts of 
simultaneous connections just doesn't seem the right way to approach 
such setups and benchmark methods.


Mike




___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Gigabit ethernet very slow.

[Michael Vince]

Nikolas Britton wrote:


On 6/25/06, Nikolas Britton <[EMAIL PROTECTED]> wrote:


On 6/25/06, Sean Bryant <[EMAIL PROTECTED]> wrote:
> /dev/zero not exactly the best way to test sending data across the
> network. Especially since you'll be reading a 8k chunks.
>
> I could be wrong, strong possibility that I am. I only got 408mb when
> doing a /dev/zero test. I've managed to saturate though. Using other
> software that I wrote.
> On 6/25/06, Nikolas Britton <[EMAIL PROTECTED]> wrote:
> > What's up with my computer, it's only getting 30MB/s?
> >
> > hostB: nc -4kl port > /dev/null
> > hostA: nc host port < /dev/zero
> >

408MByte/s or 408Mbit/s and what measuring stick are you using? I'm
trying to rule in/out problems with the disks, I'm only getting
~25MB/s on a 6 disk RAID0 over the network... would it be better to
setup an memory backed disk, md(4) , to read from?




Now I'm getting 523.2Mbit/s (65.4MB/s) with netcat, I wiped out the
FreeBSD 6.1/amd64 install with FreeBSD 6.1/i386... and...

After a kernel rebuild (recompiled nc too):
CPUTYPE?=athlon-mp
CFLAGS+= -mtune=athlon64
COPTFLAGS+= -mtune=athlon64

I'm up to 607.2Mbit/s (75.9MB/s). What else can I do to get that
number higher, and how can I get interrupts lower?

Before recompile:
load averages:  0.94,  0.91,  0.66
CPU states:  2.6% user,  0.0% nice, 21.5% system, 64.6% interrupt, 
11.3% idle

---
After recompile:
load averages:  0.99,  0.96,  0.76
CPU states:  3.0% user,  0.0% nice, 33.7% system, 58.2% interrupt,  
5.1% idle


Out of interested I tried the same test with nc but with dd in the pipe 
or by watching it by pftop.


According to pftop (with modulate state rules) I am able to get about 
85megs/sec when I don't have dd running. dd does indeed eats a fair 
amount of cpu (40%) on the AMD64 6-stable machine.


With a dd pipe I am able to get roughly 70megs/sec  between 2 Dell 
machines, one of them being AMD64 (I ran dd on this one as its has 2 
CPUs). pftop confirms this figure as well.


cat /dev/zero | dd | nc host 3000
2955297+0 records in
2955297+0 records out
1513112064 bytes transferred in 20.733547 secs (72978930 bytes/sec)

These machines are also doing regular work and not idle.

I tested on another remote network setup as well, with a 3 FreeBSD 
setup, 1 client  one FreeBSD gateway and 3rd server. (host-A 
host-Bhost-C) HostA is the only one using 6-stable all others 
are 6.1.

None of these machines have polling and are all em devices (Dell servers).


Going from C to A (via B) gives 50megs/sec
host-C#cat /dev/zero | dd | nc host-A 3000
15000154+0 records in
15000153+0 records out
7680078336 bytes transferred in 152.320171 secs (50420626 bytes/sec)


Between them directly they all appear to give around 55-85megs/sec.

The shocker I found was sending data from hostA to hostC which appears 
to only give 1 meg/sec

host-A#cat /dev/zero | dd | nc host-C 3000
40135+0 records in
40134+0 records out
20548608 bytes transferred in 19.250176 secs (1067450 bytes/sec)

Host-A to Host-B. Actually all tests sending data from outside into 
anything past Host-B's internal network interface caused a massive drop 
in performance 800kbytes/sec

host-A#cat /dev/zero | dd | nc host-B(internal interface ip) 3000
58041+0 records in
58040+0 records out
29716480 bytes transferred in 36.137952 secs (822307 bytes/sec)

Going from Host-A to Host-B's external interface gives still gives fast 
results around 60megs/sec

host-A#cat /dev/zero | dd | nc host-B(external interface ip) 3000
4984545+0 records in
4984544+0 records out
2552086528 bytes transferred in 40.569696 secs (62906227 bytes/sec)

Speed from host-B (gateway) to Host-A is still ok at around 50megs/sec
host-B#cat /dev/zero | dd | nc host-A 3000
8826036+0 records in
8826035+0 records out
4518929920 bytes transferred in 80.471211 secs (56155858 bytes/sec)

Connecting from the internal server to the internal gateway ip gives a 
good speed around 70megs/sec

host-C#cat /dev/zero | dd | nc host-B(internal interface ip) 3000
6176688+0 records in
6176688+0 records out
3162464256 bytes transferred in 42.100412 secs (75117181 bytes/sec)

Interestingly connecting to the external interface of the gateway from 
the internal machine still gave good speeds around 70megs/sec

host-C# cat /dev/zero | dd | nc nc host-B(external interface ip) 3000
7107351+0 records in
7107351+0 records out
3638963712 bytes transferred in 49.451670 secs (73586265 bytes/sec)

I used to run the gateway with polling but ditched it when upgrading 
from 6.0 to 6.1 since the improved em driver came into 6.1
Would any one have any explaination as to why incomming data from Host A 
thru B to its most distant interface from Host-A would give such poor 
performance (1meg/sec) while going the other way seems to be fine?
Obviously its something going on inside the FreeBSD kernel as interface 
to interface tests are fine.


Its a its a Dell 1850 with 6.1-release-amd64 with pf rules enabled. The 
only only special kern

Re: Is the fsync() fake on FreeBSD6.1?

[Michael Vince]

Greg 'groggy' Lehey wrote:


On Tuesday, 27 June 2006 at 10:18:47 +0800, leo huang wrote:
 


Hi,

I benchmarked MySQL 4.1.18 on FreeBSD 6.1 and Debian 3.1 using Super Smack
1.3 some days ago.

...

The result surprise me. The MySQL Performance on FreeBSD6.1 is about
10 times of on Debian3.1??and the output of iostat also shows it.

I know that MySQL uses fsync() to flush both the data and log files
at default when using innodb engine(
http://dev.mysql.com/doc/refman/4.1/en/innodb-parameters.html). Our
evaluating computer only has a 1RPM SCSI hard disk. I think it
can do about 200 sequential fsync() calls per second if the fsync()
is real.

Is the fsync() on FreeBSD6.1 fake?
   



My understanding from the last time I looked at the code was that
fsync does the right thing:

The fsync() system call causes all modified data and attributes of fd to
be moved to a permanent storage device.  This normally results in all in-
core modified copies of buffers for the associated file to be written to
a disk.

This is not the case for Linux, where fsync syncs the entire file
system.  That could explain some of the performance difference, but
not all of it.  I suppose it's worth noting that, in general, people
report much better performance with MySQL on Linux than on FreeBSD.

 


I mean than the data is only written to the drives memory and so can
be lost if power goes down.
   



I don't believe that fsync is required to flush the drive buffers.  It
would be nice to have a function that did, though.

 


And how I can confirm this?
   



Trial and error?

Greg
--
See complete headers for address and phone numbers.
 

I actually tried once mounting /var/db/mysql on a md device to see if it 
could give any difference in performance.
After some supersmack benchmarking I decided it made just to a few % 
points to no difference, you are using a larger data set though in your 
benchmark maybe there would be a noticeable difference.


I saw a post a few months ago that on -current there was about a per CPU 
core 90% performance increase on a quad core system, which is very good 
scaling.
I don't know if what ever gave that kind of performance scaling got 
merged in to 6, but his numbers looked very good.


The standard Dell server I bought in late 2005 being 2 socket/2cores 
total now costs the same price as a Dell server with 2 socket ~ 4 CPU 
cores, early next year Intel will release its 4 cores per CPU so the 
standard server will be 8 cores, and will not take long to cost the same 
again.
With performance increasing at such a fast rate I have the daydream 
belief that its is going to be hard to have db performance problems in 
the future CPU wise, well at the very least its where supersmack 
benchmarks tend to be tested for.


Mike




___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: MySQL 5.0.22 , FreeBSD 6.1-STABLE: Benchmark

[Michael Vince]

Hugo Silva wrote:


Today I decided to benchmark MySQL 5 performance on FreeBSD 6.1-STABLE.
This server is a Dual Xeon 2.8GHz, 4GB of RAM and 2x73GB SCSI disks 
that do 320MB/s


For all the tests, I restarted mysqld prior to starting the test,  
waited for about 1 minute for it to settle down, and ran super smack. 
For the consecutive runs, I executed super-smack right after the 
previous run ended.


Switching from HTT to no HTT was achieved by 
machdep.hyperthreading_allowed, and switching from/to 
libpthread/libthr was done via libmap.conf.


System:

FreeBSD ?? 6.1-STABLE FreeBSD 6.1-STABLE #3: Mon Jul  3 03:10:35 UTC 
2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DATABASE  i386


Here are the results:


MySQL 5.0.22, built with BUILD_OPTIMIZED=yes and WITH_PROC_SCOPE_PTH=yes


=== 4BSD + libthr + HTT on ===

Run #1
connect: max=4ms  min=1ms avg= 3ms from 10 clients
Query_type  num_queries max_timemin_timeq_per_s
select_index20  0   0   20405.86


I think that this, does show impressive scaling to actually see 
performance increase with HTT enabled, from what I have seen on 
benchmarks on many hardware sites testing on MS Windows is that on the 
average best you get is an extra 5% performance out of HTT per core.
I don't have any quad core machines either, but my dual CPU Dells that 
are around 3.[46]ghz get score of around 25,000


The other promising benchmark I saw on per CPU scaling was a few months 
ago with a posted super smack benchmark on a -current box that was 
getting a score of around 60,000 on a slightly better Quad core AMD64 
machine which proves consistent scaling per core, which as far as my 
memory goes shows good scaling when entering the 4+ core arena on MySQL.


Mike



=== 4BSD + libthr + HTT off ===

Run #1
connect: max=5ms  min=2ms avg= 3ms from 10 clients
Query_type  num_queries max_timemin_timeq_per_s
select_index20  0   0   18253.60



___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: MySQL 5.0.22 , FreeBSD 6.1-STABLE: Benchmark

[Michael Vince]

David Xu wrote:


Michael Vince wrote:



Hugo Silva wrote:


Today I decided to benchmark MySQL 5 performance on FreeBSD 6.1-STABLE.
This server is a Dual Xeon 2.8GHz, 4GB of RAM and 2x73GB SCSI disks 
that do 320MB/s


For all the tests, I restarted mysqld prior to starting the test,  
waited for about 1 minute for it to settle down, and ran super 
smack. For the consecutive runs, I executed super-smack right after 
the previous run ended.


Switching from HTT to no HTT was achieved by 
machdep.hyperthreading_allowed, and switching from/to 
libpthread/libthr was done via libmap.conf.


System:

FreeBSD ?? 6.1-STABLE FreeBSD 6.1-STABLE #3: Mon Jul  3 03:10:35 UTC 
2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DATABASE  i386


Here are the results:


MySQL 5.0.22, built with BUILD_OPTIMIZED=yes and 
WITH_PROC_SCOPE_PTH=yes



=== 4BSD + libthr + HTT on ===

Run #1
connect: max=4ms  min=1ms avg= 3ms from 10 clients
Query_type  num_queries max_timemin_timeq_per_s
select_index20  0   0   20405.86


I think that this, does show impressive scaling to actually see 
performance increase with HTT enabled, from what I have seen on 
benchmarks on many hardware sites testing on MS Windows is that on 
the average best you get is an extra 5% performance out of HTT per core.
I don't have any quad core machines either, but my dual CPU Dells 
that are around 3.[46]ghz get score of around 25,000


The other promising benchmark I saw on per CPU scaling was a few 
months ago with a posted super smack benchmark on a -current box that 
was getting a score of around 60,000 on a slightly better Quad core 
AMD64 machine which proves consistent scaling per core, which as far 
as my memory goes shows good scaling when entering the 4+ core arena 
on MySQL.


Mike



Actually, with proper scheduling behaviour, HTT is usefull,
I saw very high performance boosts when running sysbench :

sysbench --test=oltp --oltp-table-size=100 
--mysql-host=192.168.82.170 --mysql-user=test --mysql-db=test 
--oltp-read-only --num-threads=256 --max-requests=1 run


This benchmark runs on my Dual XEON (2.8Ghz, HTT enabled), when the
scheduler is SCHED_CORE, it only requires 30 seconds, while a 4bsd 
scheduler needs 52 seconds, last time, I wrongly wiped some code in

SCHED_CORE (which is now in tree), performance is degraded.
I need some time to make the scheduler works properly.

David Xu


That sounds very promising.
Also note when I said 5% performance improvement as average best I was 
referring to real world benchmark tests that you see typically on 
Anandtech and so on, maybe this rule of thumb has changed over time, (I 
remember reading as Anands view on HTT at one time in the past)


I have tended to see (and also read it so ) that HTT is largely just a 
5% real world freebie that Intel created to get software developers 
thinking MP so when the real dual and eventually quad cores were 
released, there would be some software for mainstream consumers to 
benefit from, ready to take advantage of their new CPUs.
Its probably hard for Intel to forget that it took MS 10 years since the 
release of the i386 chip to release a mass consumer almost purely 32bit 
OS that being Windows 2000 and XP (don't argue NT4 was for the average 
home user).
HTT was Intels best early stab to help path the way for their multi core 
technologies to come into use as quickly as possible for the masses over 
just the server end.


Mike






___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: AMD64 Diablo 1.5 JDK and libthr

[Michael Vince]

Greg Lewis wrote:


On Wed, Jul 26, 2006 at 10:32:38AM +1000, Michael Vince wrote:
 


Greg Lewis wrote:
   


On Mon, Jul 24, 2006 at 05:57:24PM +1000, Michael Vince wrote:
 


I just ran it for you now, lower then the others.
libc_r average hits per minute: 6,859
libc_r session average: 3,441 
libc_r transactions per minute: 2,310
   


Is the machine UP or SMP?

 

SMP, it was rebuild using a generic 6.1 SMP kernel for all these tests, 
with HT turned off.
I did actually record load numbers per minute and Java memory usage. I 
didn't post these numbers as load reports via top vary greatly from the 
various threading libraries.
   



libc_r is pretty much automatically going to lose then, since it can only
use one of the CPUs.  It would be interesting to see the comparison on a
UP machine.
 

OK I rebuilt the kernel to use GENERIC with no SMP for the Java 
performance tests.
The results between libc_r and libthr are quite similar on single CPU, 
libc_r runs faster on a single CPU over 2 and is actually one of the 
better for single CPU machines compared libpthread, as libpthread was 
surprisingly low on a single CPU.


libc_r average hits per minute: 8,841
libc_r session average:4,481
libc_r transactions per minute: 2,947

libthr average hits per minute: 9,020
libthr session average: 4,380
libthr transactions per minute: 3,004

libpthread average hits per minute: 6,128
libpthread session average: 3,139
libpthread transactions per minute: 2,043

For completeness here is a repaste of the SMP kernel results
libc_r average hits per minute: 6,859
libc_r session average: 3,441 
libc_r transactions per minute: 2,310


libthr average hits per minute: 11,581
libthr session average: 5,573
libthr transactions per minute: 3861

libpthread average hits per minute: 8,823
libpthread session average: 4,500
libpthread transactions per minute: 2891

Mike





___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: AMD64 Diablo 1.5 JDK and libthr

[Michael Vince]

Massimo Lusetti wrote:


On 8/1/06, Michael Vince <[EMAIL PROTECTED]> wrote:


libc_r average hits per minute: 8,841
libc_r session average:4,481
libc_r transactions per minute: 2,947

libthr average hits per minute: 9,020
libthr session average: 4,380
libthr transactions per minute: 3,004

libpthread average hits per minute: 6,128
libpthread session average: 3,139
libpthread transactions per minute: 2,043

For completeness here is a repaste of the SMP kernel results
libc_r average hits per minute: 6,859
libc_r session average: 3,441
libc_r transactions per minute: 2,310

libthr average hits per minute: 11,581
libthr session average: 5,573
libthr transactions per minute: 3861

libpthread average hits per minute: 8,823
libpthread session average: 4,500
libpthread transactions per minute: 2891




Just to clarify. This is all with and AMD64 cpu under i386 mode while
under amd64 mode libthr fails with a core dump. Right?
Thanks for this infos, very interesting and useful.


Yes, although I find that way a difficult way to describe it :)

Mike


___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Help with improving mysql performance on 6.2PRE

[Michael Vince]

Yeah the static compiling recommendations by MySQL documents are really 
more a linux thing more then anything else.
The other other thing to check is to make sure you use larger buffer 
settings I recommend the large-my.cnf

cp /usr/local/share/mysql/my-large.cnf /var/db/mysql/
Then restart MySQL.

The disk IO doesn't play much into this as far as I know because the 
supersmack benchmark doesn't generate a large database to play with, 
also because its a med-high end Dell 1950 it should have the 256meg read 
and battery backed write cache controller card which would also hold a 
lot of that data without doing much real access.


Yup there you have it, even though you didn't know about the best tweaks 
for MySQL you still managed to practically post some of the highest 
MySQL benchmarks posted here on performance out of the box with libthr, 
it also shows how much libthr gives extra performance when you have 4 
CPU cores over most peoples posts with 1 or 2 CPU cores.




Jerry Bell wrote:


Many thanks to all who responded.  You are an incredibly smart group of
people.

The recompiling without static yielded much better results:

2950# super-smack -d mysql select-key-mysql.smack 10 1
Query Barrel Report for client smacker1
connect: max=1ms  min=0ms avg= 0ms from 10 clients
Query_type  num_queries max_timemin_timeq_per_s
select_index20  0   0   51118.22


From ~34k qps to ~51k qps is quite an improvement!


I always thougt that compiling something static increased performance, but
then that's probably true for things that have to startup and shutdown
frequently.

Thanks again.

Jerry
 


Jerry Bell wrote:

   


I have a Dell PE2950 with 2 dual core 3.73Ghz processors and 4G of ram.
I've looked through some of the lists here and have seen super-smack
results in the 42k qps range on a 2 dual core opteron system.  I'm able
to
get up to about 34k with the wide at the back of my server whilest
rubbing
the side of it.

Here's what I've done:
built both mysql 5.0 and 5.1 from ports with build_static and
optimazations on.
changed the clock to TSC

added the following to my /etc/libmap.conf file:
[mysqld]
libc_r.so.5 libthr.so.2
libc_r.so.6 libthr.so.2
libthr.so.2 libthr.so.2
libpthread.so.1 libthr.so.2
libpthread.so.2 libthr.so.2
 


[...]

As Nick Evans said, you can't use static version of MySQL daemon if you
want to use /etc/libmap.conf

I tested both (static vs. dynamic with libmap.conf), dynamic with libthr
performs much better than static on Dual Xeon 3GHz SMP system with 2GB
of RAM.

My /etc/libmap.conf is just

[/usr/local/libexec/mysqld]
libpthread.so.2  libthr.so.2
libpthread.solibthr.so

Miroslav Lachman
___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to
"[EMAIL PROTECTED]"

   




___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
 



___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: WHT thread: FreeBSD vs. CentOS

[Michael Vince]

Scott I. Remick wrote:


Just wanted to give those on the list a heads-up about this thread over on
WebHostingTalk:

http://www.webhostingtalk.com/showthread.php?t=563624

It's been going on a few months now. Apparently a number of webhosts are
finding poor FreeBSD performance when compared with CentOS. Perhaps
someone on here would like to pipe in with some assistance?

 

This filesystem benchmark for his particular raid card seems a bit silly 
to judge the whole OS on.
It could simply be that the driver for that particular raid card wasn't 
as well coded/tuned for performance for FreeBSD as the linux version, 
you can't judge a whole OS on that for the most part his server hardware 
seems a bit rare and weird.


That score on linux is not much more then 10% higher, I mean if 10% 
makes all the difference between all the possible advantages you can get 
or not get on a particular OS I think its just thinking a bit too 
square, this seems to be a bit of a epidemic way of thinking.


Its the same was of thinking when I see benchmarking with MySQL people 
can spot a difference between Linux and FreeBSD of up to 30%? when doing 
100,000 threads of queries at the same time, when most MySQL databases 
are doing around 20 threads? And in more higher cases maybe 500 threads 
at the same time max, in this ball park its impossible to see a 
difference between OS/MySQL performance.


For judging a OS on a particular performance of a particular raid card 
driver is part of the same group of thinking.
It would be nice in the future if people judge a OS with a wider range 
of factors.


Mike

___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Java performance on AMD64

[Michael Vince]

Hey All,
I been benchmarking Diablo Java under AMD64 on 6.2R and using the same 
methods I posted a while ago detailed somewhat here

http://lists.freebsd.org/pipermail/freebsd-java/2006-August/005576.html

The difference here is that libthr now works under Amd64.
But it appears libthr to be about half the speed of libpthread under 
AMD64 mode which is the opposite behavior when using it under i386.
The only other difference is that I am now using a 4 core server (total) 
Intel Core2 cpus, I tried testing under a dual core (total) server and 
the performance was just about exactly neck and neck between libpthread 
and libthr which is also somewhat wierd.
The servers are under stock 6.2R and I did have a multi IP jail patch 
applied and I tried removing that and it had no difference on performance.


Does any one know with there is such a large amount of difference of 
behavior between i386 and Amd64 on Java?


Thanks,
Mike



___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Java performance on AMD64

[Michael Vince]

Kris Kennaway wrote:

On Thu, Apr 19, 2007 at 12:32:53PM +1000, Michael Vince wrote:
  

Hey All,
I been benchmarking Diablo Java under AMD64 on 6.2R and using the same 
methods I posted a while ago detailed somewhat here

http://lists.freebsd.org/pipermail/freebsd-java/2006-August/005576.html

The difference here is that libthr now works under Amd64.
But it appears libthr to be about half the speed of libpthread under 
AMD64 mode which is the opposite behavior when using it under i386.



That's contrary to my benchmarks :( Dunno what might be wrong though,
assuming you have checked all the obvious.

Kris
  

OK,
I did more testing and it appears the 6.1R Diablo Java binary package on 
Amd64 on 6.2/libthr appears to be the problem, it's as much as 60% 
slower then libpthread.


On 6.2R Amd64 I built the ports version of jdk1.5 and libthr appeared to 
be around 25% faster then libpthread.
But using the Diablo jdk package for 6.1R on 6.2 under libpthread is 
even faster by around 15% over anything I could do for any combination 
of Java and libthr.


I would guess that a new 6.2R Amd64 Diablo package would probably turn 
it around again for libthr and I would guess it would again around 20% 
faster then anything I can get from Java under AMD64 6.2R, what's going 
on here exactly I don't know.


Cheers,
Mike

___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"