This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Poor Backup Performance with AppAssure

Has anyone come up with performance tweaks they can share in AppAssure ? 

I frequently have many jobs run at sub 100K transfer speeds and take ten's of hours to finish. During these times the server is utilizing less than 10% of the processors load, the network shows no more than 5% utilized. I am concerned there is something more going on. I talked to support and they have had me make tweaks, but their last response was why don't you try upgrading to 15K SAS drives and see if this helps.  Not really a solution i want to try without hard numbers to back it up.

I have tested with ATTO and Iometer bench tests and can get line speed transferring data. In addition I went as far as to test Unitrends backup software and i can sustain higher 50MB + transfer speeds for backups. Its not making much sense and though i would check with the group and see if anyone else is experiencing this as well. 

No Data
  • I realize it is an old thread but I wasted a lot of time with support to discover they know nothing about the reg tweaks to boost performance. Dell knew nothing, and quest just recycled the dell kbs. Dell fired the engineers who came up with this program long ago, so no one really knows how it works any more. The core settings are VERY hardware specific.

    By default AA/RR sets your bytes per sector to 4096, if your physical drives are 512e, this is ok but you can get slightly better IO setting it to 512 so it doesnt need to run through the emulation.

    This setting youre probably fine with 4096, but it is one thing to check. HKEY_LOCAL_MACHINE\SOFTWARE\AppRecovery\Core\Repositories\{$repoidstring}\FileConfigurations\0\Specification\BytesPer Sector this can also be configured during intial repo setup in the gui

    Write cache policy, anytime you talk to support complaining about speed they will google and come up with an old dell kb saying to set the write cache policy to 3. They arent going to think about what they are doing, theyll just see the article from appassure saying do this to boost speed - criticism accurate as of 7/11/18 and im running Rapid Recovery 6.2. If youre are using server 2012 or later set it to 4 so it is synchronous. You want windows controlling the io. This changed my speeds dramatically. HKEY_LOCAL_MACHINE\SOFTWARE\AppRecovery\Core\Repositories\{$repoidstring}\FileConfigurations\0\Specification\WriteCachingPolicy

    Next thing if youre seeing a lag running rollups or other resource intensive jobs there are 2 fun settings to increase the io. Again, this is very hardware specific. If you are running this on 5K drives its probably not going to do much for you but if you have 15k or ssd drives, you will like this. No one at quest or dell has put effort in to tuning the repo in 10 years so all the default recommendations are from 2008. under HKEY_LOCAL_MACHINE\SOFTWARE\AppRecovery\Core\CoreSettings change max threads and max io threads from 500 to 1000. Why they would statically set this is beyond me. Feel free to experiment, but I doubt you will need more than 1000. If you check the logs and see an io operation taking too long this setting will help fix that.

    This one I have zero explanation for other than trial and error. By default max concurrent operations is set to either 32 or 64. The original dell documentation, which admittedly is kinda worthless, said to tweak this in multiples of 8. So 16, 72, 80, etc. Dont ask me why, 98, even though it isnt a multiple of 8 was my magic number. 99, 97 96, performance jumped off a cliff and landed in Cleveland.  HKEY_LOCAL_MACHINE\SOFTWARE\AppRecovery\Core\Repositories\{$repoidstring}\Specification\MaxconcurrentOperations

    While you are in that key you might want to change 

    HKEY_LOCAL_MACHINE\SOFTWARE\AppRecovery\Core\Repositories\{$repoidstring}\Specification\enabledirectoryautorepair from zero to 1. I like in general when something bad is detected it gets fixed

    Last tip, try and make sure your Meta folder is on a different drive than your data folder. If you can put the meta folder on an ssd even better. 

    Use all these tweaks at your on risk, you need to stop and restart the core service for most of them to take effect. If you break something just revert back to the old setting and restart the core service, there is next to no harm in experimenting. Worst case the repo doesnt load in the web gui, you undo your change, and restart the service. The DVM check will clean up any side effects.

    Snootchie Boochies