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]

Reply via email to