Comments on: MySQL Performance on Memory Appliance http://www.mysqlperformanceblog.com/2008/03/31/mysql-performance-on-memory-appliance/ Everything about MySQL Performance Tue, 02 Dec 2008 21:11:26 +0000 http://wordpress.org/?v=2.5.1 By: francesco http://www.mysqlperformanceblog.com/2008/03/31/mysql-performance-on-memory-appliance/#comment-358202 francesco Sat, 27 Sep 2008 07:34:17 +0000 http://www.mysqlperformanceblog.com/2008/03/31/mysql-performance-on-memory-appliance/#comment-358202 I am very interested in MySQL on Memory Appiance. We have a database with 50 millions of records (emails), and 50 columns (100byte foreach). We need to be fast (50k-100k request/sec; 20k update/sec). With mySql and a memory applance is it possible? I am very interested in MySQL on Memory Appiance. We have a database with 50 millions of records (emails), and 50 columns (100byte foreach). We need to be fast (50k-100k request/sec; 20k update/sec). With mySql and a memory applance is it possible?

]]> By: Chris Nigh http://www.mysqlperformanceblog.com/2008/03/31/mysql-performance-on-memory-appliance/#comment-315259 Chris Nigh Thu, 19 Jun 2008 22:43:19 +0000 http://www.mysqlperformanceblog.com/2008/03/31/mysql-performance-on-memory-appliance/#comment-315259 5.0.51a sorry.. 5.0.51a
sorry..

]]> By: Chris Nigh http://www.mysqlperformanceblog.com/2008/03/31/mysql-performance-on-memory-appliance/#comment-315254 Chris Nigh Thu, 19 Jun 2008 22:24:00 +0000 http://www.mysqlperformanceblog.com/2008/03/31/mysql-performance-on-memory-appliance/#comment-315254 I forgot to add, we are running RHEL5, and MySQL 5.0.53 on an ext2 file system. Our databases are all read only. I forgot to add, we are running RHEL5, and MySQL 5.0.53 on an ext2 file system. Our databases are all read only.

]]> By: Chris Nigh http://www.mysqlperformanceblog.com/2008/03/31/mysql-performance-on-memory-appliance/#comment-315251 Chris Nigh Thu, 19 Jun 2008 22:17:04 +0000 http://www.mysqlperformanceblog.com/2008/03/31/mysql-performance-on-memory-appliance/#comment-315251 I am running a test with a very similar setup. We have an HP DL380 with 20GB RAM, dual socket, quad core 3.0GHz Xeons attached via a single interface card to a 500GB Violin. Our database(s) total roughly 350GB and we have multiple application servers hitting it to produce a virtually infinite database load. After initially seeing terrible numbers, we disabled the key_buffer and saw a huge improvement. As we added application servers we saw the database server increase in load until we seem to have reached its maximum throughput. I have tried several different database and application configurations and have not seen any real application TPS improvements. At maximum load, we seem to see that we are CPU bound, with high context switching and paging (not swap) activities. We are running multiple MySQL instances, so it is difficult to get the oprofile running for all instances, but I may do that next week. Overall, we are impressed that we have been able to compress an existing environment of many database servers running our data in ramdisk to a single Violin with virtually the same performance. Details below: 03:00:01 PM proc/s 03:01:01 PM 0.22 Average: 0.22 03:00:01 PM cswch/s 03:01:01 PM 101676.65 Average: 101676.65 03:00:01 PM CPU %user %nice %system %iowait %steal %idle 03:01:01 PM all 27.15 0.00 16.21 1.44 0.00 55.21 03:01:01 PM 0 38.58 0.00 22.03 1.28 0.00 38.11 03:01:01 PM 1 20.00 0.00 11.68 2.08 0.00 66.24 03:01:01 PM 2 21.48 0.00 11.05 0.67 0.00 66.81 03:01:01 PM 3 21.82 0.00 13.44 0.85 0.00 63.89 03:01:01 PM 4 26.78 0.00 14.61 1.22 0.00 57.39 03:01:01 PM 5 40.65 0.00 31.89 3.60 0.00 23.86 03:01:01 PM 6 24.12 0.00 12.30 0.90 0.00 62.68 03:01:01 PM 7 23.75 0.00 12.63 0.92 0.00 62.70 Average: all 27.15 0.00 16.21 1.44 0.00 55.21 Average: 0 38.58 0.00 22.03 1.28 0.00 38.11 Average: 1 20.00 0.00 11.68 2.08 0.00 66.24 Average: 2 21.48 0.00 11.05 0.67 0.00 66.81 Average: 3 21.82 0.00 13.44 0.85 0.00 63.89 Average: 4 26.78 0.00 14.61 1.22 0.00 57.39 Average: 5 40.65 0.00 31.89 3.60 0.00 23.86 Average: 6 24.12 0.00 12.30 0.90 0.00 62.68 Average: 7 23.75 0.00 12.63 0.92 0.00 62.70 03:00:01 PM INTR intr/s 03:01:01 PM sum 24732.29 Average: sum 24732.29 03:00:01 PM CPU i000/s i001/s i003/s i008/s i009/s i012/s i014/s i098/s i106/s i130/s i146/s i154/s i162/s i169/s i177/s i185/s 03:01:01 PM 0 1000.15 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 7719.43 0.88 0.00 0.00 0.00 03:01:01 PM 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 18.33 0.00 0.00 0.00 0.00 0.00 0.00 03:01:01 PM 2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 03:01:01 PM 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 03:01:01 PM 4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 03:01:01 PM 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 15993.38 0.00 0.00 0.00 0.00 0.00 03:01:01 PM 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 03:01:01 PM 7 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Average: 0 1000.15 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 7719.43 0.88 0.00 0.00 0.00 Average: 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 18.33 0.00 0.00 0.00 0.00 0.00 0.00 Average: 2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Average: 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Average: 4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Average: 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 15993.38 0.00 0.00 0.00 0.00 0.00 Average: 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Average: 7 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 03:00:01 PM pswpin/s pswpout/s 03:01:01 PM 0.00 0.00 Average: 0.00 0.00 03:00:01 PM tps rtps wtps bread/s bwrtn/s 03:01:01 PM 16095.52 16087.10 8.42 157681.72 1011.03 Average: 16095.52 16087.10 8.42 157681.72 1011.03 03:00:01 PM frmpg/s bufpg/s campg/s 03:01:01 PM 7.47 2.88 -18.95 Average: 7.47 2.88 -18.95 03:00:01 PM TTY rcvin/s xmtin/s framerr/s prtyerr/s brk/s ovrun/s 03:01:01 PM 0 0.00 0.00 0.00 0.00 0.00 0.00 03:01:01 PM 1 0.00 0.00 0.00 0.00 0.00 0.00 Average: 0 0.00 0.00 0.00 0.00 0.00 0.00 Average: 1 0.00 0.00 0.00 0.00 0.00 0.00 03:00:01 PM IFACE rxpck/s txpck/s rxbyt/s txbyt/s rxcmp/s txcmp/s rxmcst/s 03:01:01 PM lo 0.70 0.70 38.73 38.73 0.00 0.00 0.00 03:01:01 PM eth0 9140.03 8010.61 6269830.21 7670767.72 0.00 0.00 0.00 03:01:01 PM eth1 0.50 0.67 85.82 88.82 0.00 0.00 0.00 03:01:01 PM sit0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Average: lo 0.70 0.70 38.73 38.73 0.00 0.00 0.00 Average: eth0 9140.03 8010.61 6269830.21 7670767.72 0.00 0.00 0.00 Average: eth1 0.50 0.67 85.82 88.82 0.00 0.00 0.00 Average: sit0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 03:00:01 PM IFACE rxerr/s txerr/s coll/s rxdrop/s txdrop/s txcarr/s rxfram/s rxfifo/s txfifo/s 03:01:01 PM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 03:01:01 PM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 03:01:01 PM eth1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 03:01:01 PM sit0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Average: lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Average: eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Average: eth1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Average: sit0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 03:00:01 PM call/s retrans/s read/s write/s access/s getatt/s 03:01:01 PM 0.45 0.00 0.00 0.00 0.07 0.28 Average: 0.45 0.00 0.00 0.00 0.07 0.28 03:00:01 PM scall/s badcall/s packet/s udp/s tcp/s hit/s miss/s sread/s swrite/s saccess/s sgetatt/s 03:01:01 PM 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Average: 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 03:00:01 PM pgpgin/s pgpgout/s fault/s majflt/s 03:01:01 PM 78841.19 505.52 2327.63 0.38 Average: 78841.19 505.52 2327.63 0.38 03:00:01 PM kbmemfree kbmemused %memused kbbuffers kbcached kbswpfree kbswpused %swpused kbswpcad 03:01:01 PM 103824 20447528 99.49 92568 16664180 8385768 152 0.00 0 Average: 103824 20447528 99.49 92568 16664180 8385768 152 0.00 0 03:00:01 PM dentunusd file-sz inode-sz super-sz %super-sz dquot-sz %dquot-sz rtsig-sz %rtsig-sz 03:01:01 PM 5603 4080 8992 0 0.00 0 0.00 0 0.00 Average: 5603 4080 8992 0 0.00 0 0.00 0 0.00 03:00:01 PM totsck tcpsck udpsck rawsck ip-frag 03:01:01 PM 1127 872 8 0 0 Average: 1127 872 8 0 0 03:00:01 PM runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15 03:01:01 PM 2 1143 5.11 5.56 5.75 Average: 2 1143 5.11 5.56 5.75 I am running a test with a very similar setup. We have an HP DL380 with 20GB RAM, dual socket, quad core 3.0GHz Xeons attached via a single interface card to a 500GB Violin. Our database(s) total roughly 350GB and we have multiple application servers hitting it to produce a virtually infinite database load.

After initially seeing terrible numbers, we disabled the key_buffer and saw a huge improvement. As we added application servers we saw the database server increase in load until we seem to have reached its maximum throughput. I have tried several different database and application configurations and have not seen any real application TPS improvements.

At maximum load, we seem to see that we are CPU bound, with high context switching and paging (not swap) activities.

We are running multiple MySQL instances, so it is difficult to get the oprofile running for all instances, but I may do that next week.

Overall, we are impressed that we have been able to compress an existing environment of many database servers running our data in ramdisk to a single Violin with virtually the same performance.

Details below:
03:00:01 PM proc/s
03:01:01 PM 0.22
Average: 0.22

03:00:01 PM cswch/s
03:01:01 PM 101676.65
Average: 101676.65

03:00:01 PM CPU %user %nice %system %iowait %steal %idle
03:01:01 PM all 27.15 0.00 16.21 1.44 0.00 55.21
03:01:01 PM 0 38.58 0.00 22.03 1.28 0.00 38.11
03:01:01 PM 1 20.00 0.00 11.68 2.08 0.00 66.24
03:01:01 PM 2 21.48 0.00 11.05 0.67 0.00 66.81
03:01:01 PM 3 21.82 0.00 13.44 0.85 0.00 63.89
03:01:01 PM 4 26.78 0.00 14.61 1.22 0.00 57.39
03:01:01 PM 5 40.65 0.00 31.89 3.60 0.00 23.86
03:01:01 PM 6 24.12 0.00 12.30 0.90 0.00 62.68
03:01:01 PM 7 23.75 0.00 12.63 0.92 0.00 62.70
Average: all 27.15 0.00 16.21 1.44 0.00 55.21
Average: 0 38.58 0.00 22.03 1.28 0.00 38.11
Average: 1 20.00 0.00 11.68 2.08 0.00 66.24
Average: 2 21.48 0.00 11.05 0.67 0.00 66.81
Average: 3 21.82 0.00 13.44 0.85 0.00 63.89
Average: 4 26.78 0.00 14.61 1.22 0.00 57.39
Average: 5 40.65 0.00 31.89 3.60 0.00 23.86
Average: 6 24.12 0.00 12.30 0.90 0.00 62.68
Average: 7 23.75 0.00 12.63 0.92 0.00 62.70

03:00:01 PM INTR intr/s
03:01:01 PM sum 24732.29
Average: sum 24732.29

03:00:01 PM CPU i000/s i001/s i003/s i008/s i009/s i012/s i014/s i098/s i106/s i130/s i146/s i154/s i162/s i169/s i177/s i185/s
03:01:01 PM 0 1000.15 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 7719.43 0.88 0.00 0.00 0.00
03:01:01 PM 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 18.33 0.00 0.00 0.00 0.00 0.00 0.00
03:01:01 PM 2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
03:01:01 PM 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
03:01:01 PM 4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
03:01:01 PM 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 15993.38 0.00 0.00 0.00 0.00 0.00
03:01:01 PM 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
03:01:01 PM 7 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Average: 0 1000.15 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 7719.43 0.88 0.00 0.00 0.00
Average: 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 18.33 0.00 0.00 0.00 0.00 0.00 0.00
Average: 2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Average: 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Average: 4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Average: 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 15993.38 0.00 0.00 0.00 0.00 0.00
Average: 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Average: 7 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

03:00:01 PM pswpin/s pswpout/s
03:01:01 PM 0.00 0.00
Average: 0.00 0.00

03:00:01 PM tps rtps wtps bread/s bwrtn/s
03:01:01 PM 16095.52 16087.10 8.42 157681.72 1011.03
Average: 16095.52 16087.10 8.42 157681.72 1011.03

03:00:01 PM frmpg/s bufpg/s campg/s
03:01:01 PM 7.47 2.88 -18.95
Average: 7.47 2.88 -18.95

03:00:01 PM TTY rcvin/s xmtin/s framerr/s prtyerr/s brk/s ovrun/s
03:01:01 PM 0 0.00 0.00 0.00 0.00 0.00 0.00
03:01:01 PM 1 0.00 0.00 0.00 0.00 0.00 0.00
Average: 0 0.00 0.00 0.00 0.00 0.00 0.00
Average: 1 0.00 0.00 0.00 0.00 0.00 0.00

03:00:01 PM IFACE rxpck/s txpck/s rxbyt/s txbyt/s rxcmp/s txcmp/s rxmcst/s
03:01:01 PM lo 0.70 0.70 38.73 38.73 0.00 0.00 0.00
03:01:01 PM eth0 9140.03 8010.61 6269830.21 7670767.72 0.00 0.00 0.00
03:01:01 PM eth1 0.50 0.67 85.82 88.82 0.00 0.00 0.00
03:01:01 PM sit0 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Average: lo 0.70 0.70 38.73 38.73 0.00 0.00 0.00
Average: eth0 9140.03 8010.61 6269830.21 7670767.72 0.00 0.00 0.00
Average: eth1 0.50 0.67 85.82 88.82 0.00 0.00 0.00
Average: sit0 0.00 0.00 0.00 0.00 0.00 0.00 0.00

03:00:01 PM IFACE rxerr/s txerr/s coll/s rxdrop/s txdrop/s txcarr/s rxfram/s rxfifo/s txfifo/s
03:01:01 PM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
03:01:01 PM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
03:01:01 PM eth1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
03:01:01 PM sit0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Average: lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Average: eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Average: eth1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Average: sit0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

03:00:01 PM call/s retrans/s read/s write/s access/s getatt/s
03:01:01 PM 0.45 0.00 0.00 0.00 0.07 0.28
Average: 0.45 0.00 0.00 0.00 0.07 0.28

03:00:01 PM scall/s badcall/s packet/s udp/s tcp/s hit/s miss/s sread/s swrite/s saccess/s sgetatt/s
03:01:01 PM 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Average: 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

03:00:01 PM pgpgin/s pgpgout/s fault/s majflt/s
03:01:01 PM 78841.19 505.52 2327.63 0.38
Average: 78841.19 505.52 2327.63 0.38

03:00:01 PM kbmemfree kbmemused %memused kbbuffers kbcached kbswpfree kbswpused %swpused kbswpcad
03:01:01 PM 103824 20447528 99.49 92568 16664180 8385768 152 0.00 0
Average: 103824 20447528 99.49 92568 16664180 8385768 152 0.00 0

03:00:01 PM dentunusd file-sz inode-sz super-sz %super-sz dquot-sz %dquot-sz rtsig-sz %rtsig-sz
03:01:01 PM 5603 4080 8992 0 0.00 0 0.00 0 0.00
Average: 5603 4080 8992 0 0.00 0 0.00 0 0.00

03:00:01 PM totsck tcpsck udpsck rawsck ip-frag
03:01:01 PM 1127 872 8 0 0
Average: 1127 872 8 0 0

03:00:01 PM runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15
03:01:01 PM 2 1143 5.11 5.56 5.75
Average: 2 1143 5.11 5.56 5.75

]]> By: Блог без заголовка » Silicon Valley Report in Russian » Полтерабайта оперативной памяти от Vio http://www.mysqlperformanceblog.com/2008/03/31/mysql-performance-on-memory-appliance/#comment-284671 Блог без заголовка » Silicon Valley Report in Russian » Полтерабайта оперативной памяти от Vio Mon, 21 Apr 2008 22:01:52 +0000 http://www.mysqlperformanceblog.com/2008/03/31/mysql-performance-on-memory-appliance/#comment-284671 [...] памяти DRAM в шасси 2U. Петр Зайцев из MySQL Performance Blog тестирует аппаратное решение в контексте MySQL. « Виртуализируем [...] [...] памяти DRAM в шасси 2U. Петр Зайцев из MySQL Performance Blog тестирует аппаратное решение в контексте MySQL. « Виртуализируем [...]

]]> By: Kevin Burton http://www.mysqlperformanceblog.com/2008/03/31/mysql-performance-on-memory-appliance/#comment-273739 Kevin Burton Sat, 12 Apr 2008 02:38:05 +0000 http://www.mysqlperformanceblog.com/2008/03/31/mysql-performance-on-memory-appliance/#comment-273739 Peter. I totally agree that if you remove the IO subsystem limits then you'll become CPU bound. However, InnoDB is pathological in this situation. MyISAM was about 2x faster and didn't use any CPU..... Actually, I think one would saturate the disk IO and or SATA port IO before the CPU would become bottlenecked. Kevin Peter.

I totally agree that if you remove the IO subsystem limits then you’ll become CPU bound.

However, InnoDB is pathological in this situation. MyISAM was about 2x faster and didn’t use any CPU…..

Actually, I think one would saturate the disk IO and or SATA port IO before the CPU would become bottlenecked.

Kevin

]]> By: peter http://www.mysqlperformanceblog.com/2008/03/31/mysql-performance-on-memory-appliance/#comment-273737 peter Sat, 12 Apr 2008 02:34:54 +0000 http://www.mysqlperformanceblog.com/2008/03/31/mysql-performance-on-memory-appliance/#comment-273737 Kevin, I think it is natural for any system - if IO becomes fast enough, system becomes CPU bound. This is not the problem the problem is performance of MySQL/Innodb in such case - penalty for path involving IO is way too large. Kevin,

I think it is natural for any system - if IO becomes fast enough, system becomes CPU bound. This is not the problem the problem is performance of MySQL/Innodb in such case - penalty for path involving IO is way too large.

]]> By: peter http://www.mysqlperformanceblog.com/2008/03/31/mysql-performance-on-memory-appliance/#comment-273736 peter Sat, 12 Apr 2008 02:33:10 +0000 http://www.mysqlperformanceblog.com/2008/03/31/mysql-performance-on-memory-appliance/#comment-273736 Ryan, Sure If I get access again I can check it. By the way they will be exhibition on MySQL Users Conference and I'm sure if you're serious about getting some of these you will be able to test your test case. Also you may learn other interesting stuff on the conference to help with this problem. I just can't share details yet :) BTW. We also did Innodb profiling and patching and we can get it perform better in this case. So at least there is a space for fixes where. Ryan,

Sure If I get access again I can check it. By the way they will be exhibition on MySQL Users Conference and I’m sure if you’re serious about getting some of these you will be able to test your test case.

Also you may learn other interesting stuff on the conference to help with this problem. I just can’t share details yet :)

BTW. We also did Innodb profiling and patching and we can get it perform better in this case. So at least there is a space for fixes where.

]]> By: Kevin Burton http://www.mysqlperformanceblog.com/2008/03/31/mysql-performance-on-memory-appliance/#comment-273617 Kevin Burton Fri, 11 Apr 2008 23:05:00 +0000 http://www.mysqlperformanceblog.com/2008/03/31/mysql-performance-on-memory-appliance/#comment-273617 Ryan. This is the same behavior we're seeing on SSD. You can have super fast IO on MySQL but on InnoDB you become CPU bottlenecked. Hopefully this will be fixed soon. Ryan.

This is the same behavior we’re seeing on SSD. You can have super fast IO on MySQL but on InnoDB you become CPU bottlenecked.

Hopefully this will be fixed soon.

]]> By: Ryan http://www.mysqlperformanceblog.com/2008/03/31/mysql-performance-on-memory-appliance/#comment-273615 Ryan Fri, 11 Apr 2008 22:58:01 +0000 http://www.mysqlperformanceblog.com/2008/03/31/mysql-performance-on-memory-appliance/#comment-273615 We were thinking of getting one of these just to improve upgrade times for customers (faster alter). it would be nice if you could test alter speed on these. In my testing I did notice that on some large tables with 30 indexes the system actually took more CPU rebuilding tables than IO so maybe these wouldn't be worth the investment. It would be good to see some numbers though. -Ryan We were thinking of getting one of these just to improve upgrade times for customers (faster alter). it would be nice if you could test alter speed on these. In my testing I did notice that on some large tables with 30 indexes the system actually took more CPU rebuilding tables than IO so maybe these wouldn’t be worth the investment. It would be good to see some numbers though.

-Ryan

]]>