Comments on: Internals of InnoDB mutexes http://www.mysqlperformanceblog.com/2006/09/07/internals-of-innodb-mutexes/ Everything about MySQL Performance Tue, 02 Dec 2008 13:51:27 +0000 http://wordpress.org/?v=2.5.1 By: Kaj Arnö’s blog » Blog Archive » MySQL 5.0.33 Community Server released http://www.mysqlperformanceblog.com/2006/09/07/internals-of-innodb-mutexes/#comment-26890 Kaj Arnö’s blog » Blog Archive » MySQL 5.0.33 Community Server released Wed, 10 Jan 2007 17:05:38 +0000 http://www.mysqlperformanceblog.com/2006/09/07/internals-of-innodb-mutexes/#comment-26890 [...] Amongst the bug fixes, there is one that I want to highlight. It is listed as the innocent-looking bullet “InnoDB showed substandard performance with multiple queries running concurrently. (Bug#15815)“. This is a fix to an issue especially surfacing on multiple-core processors. You testing in such environments is much appreciated. As a reference, you may want to read the Bugs database entry bugs.mysql.com/15815 as well as two articles from Peter Zaitsev — one from a week ago, another from last September. [...] [...] Amongst the bug fixes, there is one that I want to highlight. It is listed as the innocent-looking bullet “InnoDB showed substandard performance with multiple queries running concurrently. (Bug#15815)“. This is a fix to an issue especially surfacing on multiple-core processors. You testing in such environments is much appreciated. As a reference, you may want to read the Bugs database entry bugs.mysql.com/15815 as well as two articles from Peter Zaitsev — one from a week ago, another from last September. [...]

]]> By: MySQL Performance Blog » InnoDB benchmarks http://www.mysqlperformanceblog.com/2006/09/07/internals-of-innodb-mutexes/#comment-26292 MySQL Performance Blog » InnoDB benchmarks Wed, 03 Jan 2007 16:29:26 +0000 http://www.mysqlperformanceblog.com/2006/09/07/internals-of-innodb-mutexes/#comment-26292 [...] Thread trashing issues with count of theads 100+. In this case performance of InnoDB degraded dramatically. The problem was in the mutex impelementation and was fixed in 5.1.12 (more info about InnoDB mutexes) [...] [...] Thread trashing issues with count of theads 100+. In this case performance of InnoDB degraded dramatically. The problem was in the mutex impelementation and was fixed in 5.1.12 (more info about InnoDB mutexes) [...]

]]> By: peter http://www.mysqlperformanceblog.com/2006/09/07/internals-of-innodb-mutexes/#comment-2338 peter Fri, 08 Sep 2006 13:42:59 +0000 http://www.mysqlperformanceblog.com/2006/09/07/internals-of-innodb-mutexes/#comment-2338 Charles, First I should note it is best if you ask questions unrelated to blog post at forum - http://forums.mysqlperformanceblog.com. Speaking about your question it is hard to tell without seeing reports - how much data they will have need to analyze as well as which kind of reports are you looking for. Should they be done live or are they going to be requiested and become available at later time after they are created. Processing 10-15GB can take quite a while on low end Celeron box. As you probably know we do MySQL Performance Consulting and will be happy to help you with sizing and application optimization. Charles,

First I should note it is best if you ask questions unrelated to blog post at forum - http://forums.mysqlperformanceblog.com.

Speaking about your question it is hard to tell without seeing reports - how much data they will have need to analyze as well as which kind of reports are you looking for. Should they be done live or are they going to be requiested and become available at later time after they are created.

Processing 10-15GB can take quite a while on low end Celeron box.

As you probably know we do MySQL Performance Consulting and will be happy to help you with sizing and application optimization.

]]> By: charles http://www.mysqlperformanceblog.com/2006/09/07/internals-of-innodb-mutexes/#comment-2329 charles Fri, 08 Sep 2006 04:39:51 +0000 http://www.mysqlperformanceblog.com/2006/09/07/internals-of-innodb-mutexes/#comment-2329 Hi, Sorry for the intrusion. I am a non-technical person who is beginning to sweat a bit over the viability of a system that is being developed for me in mysql. The system will allow users to build statistical reports on foreign trade data. There are dozens of reports and they basically consist of graphs and tables. My worry is that the size of the database might make performance an issue. If you could ease my mind I would appreciate it. The main table will initially have about 10-20 million rows. Each row about 60 fields. Probably about 10-15 GB to start. Each individual row contains information on one import/export transaction (product, quantity, price, date, country of origin, etc.). The system will also pull data from a secondary table that has info on individual companies. The system will grow by about 10 million rows per year. Is it realistic to think that a dedicated server (low end celeron 2.4? with 512mb ram) can handle multiple users building online reports against this database??? Yes? No? Maybe? Thanks. Hi,

Sorry for the intrusion. I am a non-technical person who is beginning to sweat a bit over the viability of a system that is being developed for me in mysql.

The system will allow users to build statistical reports on foreign trade data. There are dozens of reports and they basically consist of graphs and tables.

My worry is that the size of the database might make performance an issue. If you could ease my mind I would appreciate it.

The main table will initially have about 10-20 million rows. Each row about 60 fields. Probably about 10-15 GB to start. Each individual row contains information on one import/export transaction (product, quantity, price, date, country of origin, etc.). The system will also pull data from a secondary table that has info on individual companies.

The system will grow by about 10 million rows per year.

Is it realistic to think that a dedicated server (low end celeron 2.4? with 512mb ram) can handle multiple users building online reports against this database???

Yes? No? Maybe?

Thanks.

]]>