Simon, Thanks for the reply, we were a little surprised at the UNIX cp speed as well. We investigated it with the provider in the past over other file system speed issues and it turned out that they rate limit the IO ops, so you can?t consume them all. Our provider runs many servers out of their data centre and they want to make sure that one company (us!) can?t monopolise all the resources. I can see their point of view and since we are not a critical company we choose to pay an appropriate rate for this. All systems have limitations one way or another. This is one of theirs and is acceptable given the price bracket. Now if we were paying ?1,000 ($1,500)/week we would have had a very different conversation :)
We?ll investigate the BEGIN IMMEDIATE and see what happens. As you say though, a simple script that suspends a message queue whilst a cp takes place and then sim,ply turns the tap back on is very simple to code and to see working. I like easy, simple solutions because I?m simple at heart. Best wishes, Rob On 4 May 2016, at 14:24, Simon Slavin wrote: > On 4 May 2016, at 1:35pm, Rob Willett <rob.sqlite at robertwillett.com> > wrote: > >> I think that unless we can get the C API to back up in a time close >> to that of a cp, the easiest solution is to suspend updates for 10-15 >> mins out-of-hours and do a simple cp from there. Sometimes a change >> in workflow might be the easiest and simplest solution. > > This solution may be what you eventually come up with. But I would > like to comment that I used a Unix platform to copy 15 Gigabytes > through FireWire from an external hard disk yesterday and that took > less than 10 minutes. Simply duplicating a 10 Gigabyte file onto your > boot drive should take considerably less time. > > You may be able to use built-in SQLite mechanisms to suspend updates. > It might be worth using the SQLite shell tool to execute "BEGIN > IMMEDIATE" and see whether that does suspend operations. > > On the other hand there's a lot to be said for running a script at 3am > which quits the update program, takes the snapshot, then starts them > up again. Not only will this perform the task needed but it would > also serve to 'reset' those updating programs in case they have a slow > resource leak or some other long-term bug. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
