On 03/11/12 14:48, Kjell Rilbe wrote: > Den 2012-02-27 12:47 skrev Paulius Pazera såhär: >> restore speed is important for big databases. It's a pain to wait 7 hours >> for restore to complete (~3 hours for data import and ~4 hours for index >> creation). Usually those big databases are already on fastest disk arrays >> companies can afford (and in addition servers have lots of RAM for caching). >> >From what I've seen in production, during index creation CPU usage is ~99% >> (there is very little disk access). So I believe that making index creation >> multi-threaded and allowing it to run on many cores simultaneously would >> help significantly. So in the above real life example on 16 core server we >> could potentially decrease index creation time from 4 hours to 15..30 >> minutes, thus whole restore process could become twice faster (3.5 instead >> of 7 hours) > Not saying you're wrong, but I was wondering. If CPU usage is already > ~99%, doesn't that mean that it's already using all cores to the max? Or > did you mean cpu usage is ~99% on the single core that's executing the > restore? Be sure - that's about single CPU.
------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
