Import/Export Tool Usage

jnapier · Post by **jnapier** » Tue Aug 29, 2006 12:09 am

I need to move a large piece of a repository to another repository. I did a test export on a small piece of the repository and it took much longer than I anticipated. The Import/Export utility reported that I had 508 transactions. It took 2.5 hours to complete the export. The test folder contains only 20 items and is no way representative of the data that I plan on exporting.

Does this sound like a proper time frame for exporting 508 transactions? Do you have any usage reccomendations?

lbauer · Post by **lbauer** » Tue Aug 29, 2006 9:36 am

It took 2.5 hours to complete the export.

Export will be dependent on the type of hardware for the Vault Server and SQL Server. For instance, our own testing of folder export yielded about 5-6 seconds per transaction. This was on a 3.2 GHz P4, 4 GB RAM, striped RAID disk IO.

Some considerations:

Make sure you database is optimized:

http://support.sourcegear.com/viewtopic.php?t=2924

If other users are using Vault at the same time, it can slow things down.

It other apps are competing for the machine's resources or if it's not a particularly fast machine, that can slow things down as well.

Did you notice any lags in the import -- for instance, in syncing up to the database, etc. Check the Export log (VaultFolderExportImport.txt in the same directory os the ExportImport tool) for transactions that seem to take longer than others, or any error messages.

jnapier · Post by **jnapier** » Tue Aug 29, 2006 2:49 pm

Ok so assuming I can get the 6 seconds per transaction that you claim, I will be looking at a 3 day process since I have determined that I need to export 36,000 transactions.

What must I do to ensure that there are no timeouts during this process? What if one transaction fails? Can the tool recover from a failed transaction?

I ask these questions because I was doing another test, came back from lunch and saw that I recieved an error that the tool lost contact with the server, another message that a transaction failed, and then a message box asking if I wanted to cancel the export. I cliked no and the tool looked like it continued to work but the transactions processed count never went up after about 5 minutes.

I do not want to get 2 days into this process and have it fail on the 3rd day.

jnapier · Post by **jnapier** » Fri Sep 01, 2006 12:03 am

Hello, hello. anybody out there? I decided to split the pieces of the export up a little bit but they are still a good size. I have one export that has currently been running for 2 days at a steady pace and still holding solid. Luckily no timeouts. I have close to the same setup as you but with a raid 5. Were getting about 15 seconds a transaction. Regardless, exporting seems to be working ok its just incredibly slow.

On the other hand we have importing. I have a 6000 transaction import that has timed out on me three times today. The utility looks like it is working but the transaction count never moves up to a certain point(different point each time). The first time it tried to cancel. Big mistake. The utility just froze up. The second time I got an exception. Heres what we got

An exception occurred during Import Folder creation in ProcessResults_ProcessTransaction(): 86659 on 9/7/2005 10:23:30 AM
Change Set Items (Modified File) $/WebSolutions/NGSolutions/IbisWork/RemoteNet.Northrop.IbisWork.Domain/Model/Process.cs. Failure Exception: An exception occurred processing a transaction.Exported Info by bgonsowski - 86659 on 9/7/2005 10:23:30 AM
Change Set Items (Modified File) $/WebSolutions/NGSolutions/IbisWork/RemoteNet.Northrop.IbisWork.Domain/Model/Process.cs
Imported Change Set - 86659 on 9/7/2005 10:23:30 AM
Change Set Items (Modified File) $/IMP-0608311828/WebSolutions/NGSolutions/IbisWork/RemoteNet.Northrop.IbisWork.Domain/Model/Process.cs [The Vault server could not be contacted to perform the operation. Your network connection to the server may have been interrupted. Please verify your network settings using the Options dialog under the Tools menu in the Vault GUI Client.The operation has timed-out.]

I tried one more time with the same result. Each time the staging folder gets left on my vault server and I have to go manually clean it up. This import isnt even close to as big as the other ones I will be importing. As I requested before, could you please provide me with some best practices for performing large export and imports?

lbauer · Post by **lbauer** » Fri Sep 01, 2006 10:33 am

We'd like to see a copy of the Vault server and import logs for the time period of the import. The log created by an export or import is called VaultFolderExportImport.txt and is located in your user's temp directory, %temp%.

The Vault server log is sgvault.log and is in %windir%\temp\sgvault.

Email these to linda at sourcegear.com

jnapier · Post by **jnapier** » Fri Sep 01, 2006 12:53 pm

the logs have been sent.

lbauer · Post by **lbauer** » Fri Sep 01, 2006 5:08 pm

Thanks, we're reviewing them.

TeamWiSE · Post by **TeamWiSE** » Wed Sep 13, 2006 3:09 am

I'd like to add to this issue. We're also encountering performance problems with the export/import tool. We are trying to move one folder with four files from one repository to another, trying to keep the history. We're talking of 69 transactions. The export is ok. Done on a 3.2GHz P4 with 2GB RAM it takes much less than 5 seconds per transaction. SQL Server runs on another machine, memory usage on the VaultServer rarely passes above 500K RAM. But then the import... Whether we're trying to import on the VaultServer itself or on another client machine, the IIS Vault worker process uses up all CPU and takes 3-10 minutes(!!) per transaction. This ofcourse results in IIS stopping the import after approx. 60 minutes (approx. 6 transactions). We havent't got the faintest idea, what Vault is trying to do. We can observe, that zillions of mutexes (mutants, named VAULT_WF_<nr>) are being created and destroyed, and that the import process seems to be heavily threaded - apparently threading itself to oblivion. Any help in getting these 4 files transferred would be greatly appreciated!

lbauer · Post by **lbauer** » Wed Sep 13, 2006 8:39 am

Could you send us the import log, plus the Vault Server log for the same time period? Import log should be in the Export\Import tool directory and the server log is sgvault.log in %windir%\temp\sgvault. Email to Linda at sourcegear.com.

TeamWiSE · Post by **TeamWiSE** » Wed Sep 13, 2006 11:30 am

Requested logfiles have been sent.

TeamWiSE · Post by **TeamWiSE** » Fri Sep 15, 2006 1:36 am

We did a clean reboot of our VaultServer, in order to activate some patches. After the reboot, Vault was responding much faster. We then retried our import and were able to process our 4 files / 69 transactions in one hour and 34 minutes. Hopefully we'll never have to import bigger folders...

As it seems, some rework may be needed on the import/export tool, since the time needed per transaction increases with the number of transactions processed. As I stated before, the number of mutexes being created and destroyed is enormous. This also happens during normal operation, not only with imports. In the picture attached, you can see how the average transaction time increases steadily during the import, with the first transactions running under one minute, but increasing up to nearly 7 minutes per transaction. If this also happens in normal operation, we should reboot the VaultServer regularly. Any idea what is causing this?

Post by **jclausius** » Fri Sep 15, 2006 8:53 am

There were some fixes on the Vault Import Tool within Vault 3.5.1.

I don't necessarily think they would specifically address this problem, but there were changes to remove the auto-refresh from within the Export / Import tool which was causing problems during Import.

You may want to give it a try with 3.5.1 to see if things have improved. Regardless, on semi-large exported folders against an existing 3 GB repository (about 12,000 folders within the existing repository), our tests have about a 2-4 second per Tx timing. The 1300+ Tx import completes in about an 1.5 hours.

TeamWiSE · Post by **TeamWiSE** » Fri Sep 15, 2006 9:04 am

I'll give it a try with the next "move from one repository to another" task.

TeamWiSE · Post by **TeamWiSE** » Tue Sep 19, 2006 4:00 am

The key to success here lies in switching off the shadow-folders of the repository being imported into. This feature seems to be responsible both for the bad performance as well as for the steady increase in CPU usage. See the related topic.

TeamWiSE · Post by **TeamWiSE** » Sat Sep 23, 2006 2:20 am

To be a bit more specific: after switching off the shadow folders, the import of our 69 transactions in 4 files did not take 1:34:40 (5.680 seconds) elapsed time, but only 12 seconds! That is 0,2% of the original time, or 473 times faster! So far we haven't done any larger imports/exports, but my guess is, that we'll manage to avoid any timeouts in the future. That does not mean ofcourse, that the issues with the shadow folders (see one and the other) should not be resolved.