Solaris 10 performance improvements??
Hello list, It has been my understanding from reading this list for a few years that Solaris doesn't match Linux on MySQL performance. I don't recall the exact reasons (different threading code?). Anyway, I'm exploring the latest Solaris 10. The virtualization features (Containers) are enticing. However, I can't consider using it unless MySQL performs well. Any ideas or personal experience with MySQL 4.1.x on Solaris 10? Also, what is the official MySQL word on special attention to optimizing for other platforms? I know MySQL has committed to optimizing MySQL for Power5 on Linux. Are there any other optimization projects the MySQL team can tell us about; such as Solaris 10 on Opteron ;-). thanks, Jon -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Solaris 10 performance improvements??
Shankar Unni wrote: Jon Hancock wrote: However, I can't consider using it unless MySQL performs well. Any ideas or personal experience with MySQL 4.1.x on Solaris 10? Well, for one thing, your workload is unique, so the only way you can make your decision *is* for you to actually *consider* it. Install Solaris 10, and Linux (your preferred flavor) on two identical boxes (or on one box, with dual boot), and compare performance on an actual workload. Shankar, Thanks for the input. I understand the route you suggest, but it doesn't get at the heart of my issue. The info I'm interested in isn't really about my particular app performance. I'm looking for issues in regards to how the MySQL code executes against Solaris vs. Linux. I have read in the past that roots of certain performance issues on Solaris/MySQL had been identified (such as different thread models and thread creation time: Solaris v. Linux, etc...). The kind of input I'm looking for is: Does anyone know if Solaris 10 has made any changes to the things that were identified to be dragging MySQL on Solaris? Since I'm also studying freeBSD 5.3, I would also like to know if anyone has ideas on this as well. IOW, has freeBSD 5.3 fixed/changed things that in previous versions were a cause of slowness in MySQL. thanks, Jon -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Lucene with MYSQL
Carlos Proal wrote: Hi, i have been using Lucene MySQL but separately, MySQL is written in C/C++ with a JDBC driver available and Lucene is coded in Java, so (besides the mysql team opinion) you can mix searches throught both apis and referring to each other with the PrimaryKey. Does anyone know if/how a JVM using Lucene could be used in the MySQL 5 Stored Procedure architecture (or maybe as Functions in the 4.0 architecture). If the architecture (MySQL 5) would allow for a continuous running JVM with an entry point into the Java search code then could you use Lucene code against the MySQL DB tables directly? There are obvious places where too much data marshalling between C and Java may make the solution too slow, but I would like to investigate the possibilities. thanks, Jon This combination works fine for some scenarios but it doesnt for others, in some cases the best choice is to use the FullText feature available in MySQL which employs the same Vectorial Model that Lucene's do. One advantage of Lucene is that is composed of layers and you can modify it to use different models instead of uniquely the Vectorial; on the other hand Lucene doesnt support concurrency which can be a serious problem in your application or maybe not. Hope my 5 cents works to you :) Carlos Proal Original Message Follows From: leegold [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Lucene with MYSQL Date: Thu, 29 Jul 2004 13:36:56 -0400 Is it possible to use the Lucene fulltext search on a MYSQL database - say for text type fields? _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
so long I keep longing
for 4.1.1... .anyone have a good guess for getting a build of 4.1.1 ??? thanks, Jon
Re: MySQL/InnoDB-4.0.16 is released + sneak peek of 4.1.1
Heikki, I have two questions in regards to the tablespace changes: 1 - You mention being able to store indexes in a seperate tablespace. How far off is this for MySQL to implement? I would like to see FULLTEXT indexes stored in seperate tablspace (seperate RAID channel) so the two features (InnoDB FULLTEXT) would both need to be available. 2 - Is there any value to using Journaled file systems with the InnoDB tablespaces? A new system I'm putting together will have seperate drives for only InnoDB data. Is a Journaled file system extra overhead? If so, is Raw significantly more efficient? How does this choice effect backup soultion? thanks, Jon - Original Message - From: Heikki Tuuri [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, October 24, 2003 9:55 PM Subject: Re: MySQL/InnoDB-4.0.16 is released + sneak peek of 4.1.1 Eduardo, to make the user interface simple, I decided to take the table per file approach. Each .ibd file is internally a 'tablespace'. The simple approach I chose is similar to how MyISAM now works. I thought it would be nice for current MySQL users. In Oracle, one can store several tables into a single named tablespace, and can also split indexes and data of a single table to separate tablespaces. Nothing prevents adding those features to InnoDB, too. It just requires new syntax in CREATE TABLE to specify these options. Best regards, Heikki Innobase Oy http://www.innodb.com InnoDB - transactions, row level locking, and foreign keys for MySQL InnoDB Hot Backup - hot backup tool for InnoDB which also backs up MyISAM tables .. From: Eduardo D Piovesam ([EMAIL PROTECTED]) Subject: Re: MySQL/InnoDB-4.0.16 is released + sneak peek of 4.1.1 View this article only Newsgroups: mailing.database.myodbc Date: 2003-10-23 14:43:28 PST (Sorry for the last email, it's not complete). Hello Heikki, Sorry, but I didn't understand the concept of tablespace applied. It's different from Oracle, right? AFAIK, tablespace is utilized to logically group tables into one (or more) files. And to group indexes into another files... But you said that the each table (with its indexes) will be in one file... is there an reason? Is it better than split tables and indexes? Thank you. Eduardo -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Partial replicate InnoDB - MyISAM
This thread started as Re: MySQL/InnoDB-4.0.16 is released + sneak peek of 4.1.1. I may want to have one MySQL server as the Read only Search server. If I did this and I have all InnoDB table on my Master, then could I replicate only certain columns into the MyISAM slave ? Any other efficient ideas on how to do this? thanks, Jon - Original Message - From: Chris Nolan [EMAIL PROTECTED] To: Jon Hancock [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, October 27, 2003 8:45 PM Subject: Re: MySQL/InnoDB-4.0.16 is released + sneak peek of 4.1.1 Hi, As I have said before, I'm not Heikki, but I'm such a massive geek I'm likely to have one or two useful bits of info for you. :-) 1. You'd have a rough time getting indexes and tables to be seperated out, unless you were willing to set up your various symlinks/hardlinks by hand. Even then, you may be inviting problems. Additionally, no date has been announced for FULLTEXT indexing on InnoDB tables, and Heikki considers it a low priority by the looks of things (not having a go at the god of multiversioned DBs, just making a possibly incorrect observation). 2. I personally use ReiserFS for all of my stuff, most of which is based upon InnoDB. One thing you have to remember is that InnoDB treats the space inside the tablespace as a Berkeley Fast Filesystem-style space, using the underlaying filesystem minimally. To quote the manuals, raw partition usage can speed up IO on a number of UNIXes (and Windows too seemingly). Regarding backup, you'd need to use mysqldump or InnoDB Hot Backup to backup a raw-partition setup. This isn't a bad thing though - I use mysqldump and can get a consistant snapshot of a 12 GB DB without problems while the thing is running. Hope this helps! Regards, Chris Jon Hancock wrote: Heikki, I have two questions in regards to the tablespace changes: 1 - You mention being able to store indexes in a seperate tablespace. How far off is this for MySQL to implement? I would like to see FULLTEXT indexes stored in seperate tablspace (seperate RAID channel) so the two features (InnoDB FULLTEXT) would both need to be available. 2 - Is there any value to using Journaled file systems with the InnoDB tablespaces? A new system I'm putting together will have seperate drives for only InnoDB data. Is a Journaled file system extra overhead? If so, is Raw significantly more efficient? How does this choice effect backup soultion? thanks, Jon - Original Message - From: Heikki Tuuri [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, October 24, 2003 9:55 PM Subject: Re: MySQL/InnoDB-4.0.16 is released + sneak peek of 4.1.1 Eduardo, to make the user interface simple, I decided to take the table per file approach. Each .ibd file is internally a 'tablespace'. The simple approach I chose is similar to how MyISAM now works. I thought it would be nice for current MySQL users. In Oracle, one can store several tables into a single named tablespace, and can also split indexes and data of a single table to separate tablespaces. Nothing prevents adding those features to InnoDB, too. It just requires new syntax in CREATE TABLE to specify these options. Best regards, Heikki Innobase Oy http://www.innodb.com InnoDB - transactions, row level locking, and foreign keys for MySQL InnoDB Hot Backup - hot backup tool for InnoDB which also backs up MyISAM tables .. From: Eduardo D Piovesam ([EMAIL PROTECTED]) Subject: Re: MySQL/InnoDB-4.0.16 is released + sneak peek of 4.1.1 View this article only Newsgroups: mailing.database.myodbc Date: 2003-10-23 14:43:28 PST (Sorry for the last email, it's not complete). Hello Heikki, Sorry, but I didn't understand the concept of tablespace applied. It's different from Oracle, right? AFAIK, tablespace is utilized to logically group tables into one (or more) files. And to group indexes into another files... But you said that the each table (with its indexes) will be in one file... is there an reason? Is it better than split tables and indexes? Thank you. Eduardo -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Partial replicate InnoDB - MyISAM
see below... - Original Message - From: Chris Nolan [EMAIL PROTECTED] To: Jon Hancock [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, October 28, 2003 10:49 AM Subject: Re: Partial replicate InnoDB - MyISAM Hmm How much lag time can you afford between the master's contents being updated and the slave being updated? Taking advantage of MyISAM's compressed table features might help performance if that is an issue. I need to put copy things into MyISAM from InnoDB anyway in order to use FULLTEXT. Right now, we are doing double inserts into InnoDB and then an insert into MyISAM (only the searchable fields). O would like to solve this at the DB level. Can I use FULLTEXT on compressed tables? Should there be any speed degragation other than the normal compress overhead? Every independant test out there shows that in the cases where InnoDB is slower for reads than MyISAM, the speed differential is quite small. In those cases, the differences come from InnoDB's higher disk space and RAM usage seemingly. Just some of my thoughts. Regards, Chris On Tue, 28 Oct 2003 01:40 pm, Jon Hancock wrote: This thread started as Re: MySQL/InnoDB-4.0.16 is released + sneak peek of 4.1.1. I may want to have one MySQL server as the Read only Search server. If I did this and I have all InnoDB table on my Master, then could I replicate only certain columns into the MyISAM slave ? Any other efficient ideas on how to do this? thanks, Jon - Original Message - From: Chris Nolan [EMAIL PROTECTED] To: Jon Hancock [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, October 27, 2003 8:45 PM Subject: Re: MySQL/InnoDB-4.0.16 is released + sneak peek of 4.1.1 Hi, As I have said before, I'm not Heikki, but I'm such a massive geek I'm likely to have one or two useful bits of info for you. :-) 1. You'd have a rough time getting indexes and tables to be seperated out, unless you were willing to set up your various symlinks/hardlinks by hand. Even then, you may be inviting problems. Additionally, no date has been announced for FULLTEXT indexing on InnoDB tables, and Heikki considers it a low priority by the looks of things (not having a go at the god of multiversioned DBs, just making a possibly incorrect observation). 2. I personally use ReiserFS for all of my stuff, most of which is based upon InnoDB. One thing you have to remember is that InnoDB treats the space inside the tablespace as a Berkeley Fast Filesystem-style space, using the underlaying filesystem minimally. To quote the manuals, raw partition usage can speed up IO on a number of UNIXes (and Windows too seemingly). Regarding backup, you'd need to use mysqldump or InnoDB Hot Backup to backup a raw-partition setup. This isn't a bad thing though - I use mysqldump and can get a consistant snapshot of a 12 GB DB without problems while the thing is running. Hope this helps! Regards, Chris Jon Hancock wrote: Heikki, I have two questions in regards to the tablespace changes: 1 - You mention being able to store indexes in a seperate tablespace. How far off is this for MySQL to implement? I would like to see FULLTEXT indexes stored in seperate tablspace (seperate RAID channel) so the two features (InnoDB FULLTEXT) would both need to be available. 2 - Is there any value to using Journaled file systems with the InnoDB tablespaces? A new system I'm putting together will have seperate drives for only InnoDB data. Is a Journaled file system extra overhead? If so, is Raw significantly more efficient? How does this choice effect backup soultion? thanks, Jon - Original Message - From: Heikki Tuuri [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, October 24, 2003 9:55 PM Subject: Re: MySQL/InnoDB-4.0.16 is released + sneak peek of 4.1.1 Eduardo, to make the user interface simple, I decided to take the table per file approach. Each .ibd file is internally a 'tablespace'. The simple approach I chose is similar to how MyISAM now works. I thought it would be nice for current MySQL users. In Oracle, one can store several tables into a single named tablespace, and can also split indexes and data of a single table to separate tablespaces. Nothing prevents adding those features to InnoDB, too. It just requires new syntax in CREATE TABLE to specify these options. Best regards, Heikki Innobase Oy http://www.innodb.com InnoDB - transactions, row level locking, and foreign keys for MySQL InnoDB Hot Backup - hot backup tool for InnoDB which also backs up MyISAM tables .. From: Eduardo D Piovesam ([EMAIL PROTECTED]) Subject: Re: MySQL/InnoDB-4.0.16 is released
install script errors
Hello, I am installing mysql 4.1.0 rpm on SuSE 8.2. I am logged in as root and run the rpm command as follows: rpm -Uvh MySQL-server-4.1.0-0.i386.rpm The script completes but gives two errors. The errors in mysql_install_db are on lines 166 and 383. Both lines are the same: if test $in_rpm -eq 0 || $windows -eq 0 I thought maybe the errors could be ignored, but I immediately try to execute the required commands to set the root password, the command is not found: /usr/bin/mysqladmin -u root password 'newpassword' So I guess the install didn't go so well. This same problem happened to me last month when I tried to install on another clean copy of SuSE 8.2 and also when I tried on Mandrake 9.1. Am I doing something ovbvious that is wrong?? thanks, Jon -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: innodb and fragmentation
When you issue this null ALTER TABLE, is the entire table locked during the build? i.e. Is the only way to defragment to effectively take the table offline during the rebuild? Is there a method to estimate time to do this rebuild? thanks, Jon - Original Message - From: Per Andreas Buer [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, September 19, 2003 6:17 PM Subject: Re: innodb and fragmentation Hello Heikki, Heikki Tuuri [EMAIL PROTECTED] writes: I think a 'null' alter table operation: ALTER TABLE innodbtable TYPE=INNODB; does the defragmentation with just one build of the table. And I think it also preserves FOREIGN KEY constraints. Please test it! It did the job just fine. Thanks. -- Per Andreas Buer -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
utf8 in 4.1 for Windows
I have read in past postings that UTF8 is not yet working with MySQL 4.1 on the Windows build. Can anyone verify this? If it is not yet working, can anyone give an estimate when a build will be available that should work? thanks, Jon
need 4.1 binaries
We are in a critical state with our app. We would like to dump Oracle 9i and go to MySQL. We have to do the due diligence on the port over the next few weeks. However, we must have full native support for UTF8. Its my understanding this is only in MySQL 4.1. Our dev and test platform is Win2000. We have tried very unsuccessfully to do a Windows build of the 4.1 tree. Has anyone tried this? Can anyone give an estimate of when mysql.com will publish 4.1 binaries? thanks, Jon - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
