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? Kjell -- -------------------------------------- Kjell Rilbe DataDIA AB E-post: kj...@datadia.se Telefon: 08-761 06 55 Mobil: 0733-44 24 64 ------------------------------------------------------------------------------ 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
