I see a problem in your results. You have a 41,87% iowait and only 20MB/s read and a marginal write.
4 cases : * An untypical select (I have try the sum to avoid temp table creation and select * from table) which lead to random reads (btrees?). Can you post your query and maybe table creation please (maybe the generation script)? * A very poor hard drive or misconfigured. * The database file which is fragmented. * You have another idea I tried on two computers, using jdk 6 from sun and the openjdk. Same results. I try dropping cache (thanks for the tips) with watch -n 1 "echo 3 > /proc/sys/vm/drop_caches" I doesn't change things so much. Nevertheless I was able to test to give enough system cache to load the whole data file. iowait @ 0%. Doesn't change performances so much as iowait was low already. On 9 jan, 15:31, Peter W <[email protected]> wrote: > Here's my figures when running a typical SELECT (see first post). > Flushed disk caches before (seehttp://linux-mm.org/Drop_Caches), > shows I/O bottleneck: > > avg-cpu: %user %nice %system %iowait %steal %idle > 6,40 0,00 2,46 41,87 0,00 49,26 > Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn > sdb 227,00 19,64 0,88 19 0 > > Running the query again (when the 1,5gb table is cached by os) shows > user cpu bottleneck: > > avg-cpu: %user %nice %system %iowait %steal %idle > 45,77 0,00 10,95 0,00 0,00 43,28 > Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn > sdb 0,00 0,00 0,00 0 0 > > So I'd say, depending on how much memory you have, large tables can > have big I/O bottlenecks. > > What do you think? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/h2-database?hl=en -~----------~----~----~----~------~----~------~--~---
