what journal options should I use on linux?

2007-03-08 Thread Christopher A. Kantarjiev
I'm setting up mysql on linux for the first time (have been using OpenBSD and 
NetBSD with UFS until now). The default file system is ext3fs, and I don't mind 
that, but it seems really silly to use a journaled file system for the database 
data - doubling my writes.


In particular, I have a couple of use cases where I spend a week or so creating 
a 17GB data (table) file and its 15GB index file, and then do sparse queries out 
of it. I need as much write speed as I can get. I certainly don't want to have 
every data block written twice, once to the journal and once to the file, along 
with the extra seeks.


What do people with this sort of large problem use on Linux?

Thanks,
chris


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



Re: stunningly slow query

2006-03-30 Thread Christopher A. Kantarjiev

Mike Wexler wrote:
It doesn't really answer your question, but have you tried INSERT 
DELAYED as a work around?


We've not had a lot of luck with this in the past, but it's worth a try.

Also the updated status is strange, because that generally indicates 
that its looking for the record to be updated, but since the record is 
new, there is no record to be updated. Could it be checking for 
duplicates? Not that it should be this slow, but you might try ALTER 
TABLE xxx DISABLE KEYS and see how that effect performance. At least it 
will tell you whether the problem is in updating the keys, or something 
else.


It's certainly checking for duplicates. There are 10034461 records in the 
link_area table at the moment, and 514408715 in trimble.old_crumb.




--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



Re: very large key_buffer on amd64?

2005-09-20 Thread Christopher A. Kantarjiev



It appears that mysqld won't start if the setting for key_buffer
is more than 2GB.



Maybe you've also hit the quirks of memory management and malloc, just as
we've posted a while ago in http://lists.mysql.com/mysql/186930 ?



It seems to have been a simple issue of not unlimiting the datasize. We're up to 
using 8GB (which seems to be NetBSD's limit) now.


It sure would be nice if MySQL would use mmap to read/write the index!

Thanks,
chris


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]