Don't worry, I found: now my table has 64,000,000 rows... there is no way it can cache it in memory... Now the problem I have is that connectorJ crashes (hasn't crashed before, when the table had 16,000,000 rows)
I'm going to write another email... thank you anyway.... > -----Messaggio originale----- > Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Inviato: martedi 22 giugno 2004 15.22 > A: Leonardo Francalanci > Cc: Mysql > Oggetto: Re: R: R: why CPU is high while disks are idle in a table > scan??? > > > > Well, this is a very unique question. How can we force MySQL to IGNORE an > index. Is this so you can test your disk systems data throughput? I am > quite interested in why you need to see the disk activity in order to > understand if it's working or not. > > I have concentrated so hard and so long on making sure that it DOES use > indices whenever they are available I am not sure how to answer that > question. I know there is a setting that controls the size of the "key > buffer" perhaps if you tune it to be really small it will force MySQL to > read the indices straight off of the disk (or maybe not, I am not sure). > > Have you tried specifying a "wrong" index in your select statement (so as > to force a table scan) with the USE keyword? > > Another solution could be to just get rid of the indices. Then > ALL lookups > would be table scans. You could replace each primary key with a unique > constraint (not a unique index) to keep out the duplicates. > > Or search on a column that is not part of an index. > > Another solution could be to restart the server just before each test. > Doing that will ensure that the cache is empty and that any data > that needs > to come from disk will do so (including indices). Merely flushing > the cache > while running will commit changes to disk but I don't believe that it will > clear the cache. > > The excellent people on the MySQL internals discussion may be better > equipped to answer this. > > Curiously yours, > Shawn Green > Database Administrator > Unimin Corporation - Spruce Pine > > > > > > > "Leonardo > > Francalanci" To: "Mysql" > <[EMAIL PROTECTED]> > <[EMAIL PROTECTED] cc: > > tel.ie> Fax to: > > Subject: R: R: > why CPU is high while disks are idle in a table scan??? > 06/22/2004 03:55 > > AM > > > > > > > > > > First: thank you for sparing so much time with me. > > > There are 3 major factors determining your performance: 1) the > > speed of the > > CPU, 2) the size if your RAM, and 3) the data transfer speed of > > your disks. > > I thought that the size of tables in the db would have made a difference. > From the analysis you did and from my tests it doesn't look so... > > > 5) If your application is smart enough, you can split your data over > > several servers. This would be a SERIOUS performance increase. > > In fact I'm writing a jdbc driver in java that I hope will be included > in c-jdbc (http://c-jdbc.objectweb.org/), which is a java database > cluster middleware (check it out, it seems very interesting) > > > 2) you can move parts of your data to other disks. Using multiple I/O > > channels should be faster than a single channel. > > That is what I am trying right now, but I am having problems because > it seems that there is no disk I/O if I access by index on my tables, > even if I access most of the table data (while with a table scan > disks work as expected). > > Does it happen because I have 1Gb of Ram? If yes: I know that this > sounds like a silly question but... How can I "fill" the memory of my > machine so it doesn't cache data? (I can't just remove memory, I don't > have physical access to the machine) > > > Thank you > > > -- > 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]
