jcapslock Posted July 6, 2005 Report Share Posted July 6, 2005 I have inherited Retrospect, and am seeing several issues which I do not like. I'm sure there is some sort of configuration issue, but for the life of me I can not locate it. First, the GUI is slow at responding, even when nothing is going on. If I look at the execution tab in the monitor (for example), no jobs are running, but if I just click between tabs to proactive and some of the other tabs it seems to take 2 to 3 seconds sometimes to react to my request. If I look at CPU utilization it is low and anything else in the OS works as expected. The application is just reacting slowly. I am running version 7 of multiserver latest build and patch. Running on Windows XP, AMD Athlon 64, 1 gig of RAM, 3 IDE hard disks on an IDE raid controller. Also, many times when I go to the properties of a client and click on the tools tab, retrospect says not responding in the title bar and the CPU goes to 99% utilization. It never recovers and I have to end task it and restart the backup computer. Finally, I cannot backup to multiple sets on the same hard drive Simultaneously without the application locking up within a few hours. No event log errors. The drives have no activity on them once the app locks up. Today it was when doing a snapshot transfer from 3 sets on 3 seperate drives to 3 sets on a single drive. The operating system is still functioning fine, but requires a reboot because the app is locked up. I look at the volume it was backing up to and it is only half full, so did not run out of space. I can only get it to do Simultaneous backups if the sets are on separate hard disks (volumes). Hopefully that is not a limitation of the software. I wouldn't think it would allow me to create sets on the same drive if it was not possible. I have updated the raid controller to the latest drivers and firmware, updated motherboard bios, tried a new motherboard, disabled Windows firewall, Disabled virus scanner, Tried a regular IDE controller, Tried a different administrative user in the security settings, updated to latest build to retrospect 7 and patch. Not sure what else to try or look at. Thanks, Mark Link to comment Share on other sites More sharing options...
dzenizo Posted July 7, 2005 Report Share Posted July 7, 2005 Retrospect is VERY sensible to network issues. We have had similar behavior when using Dell switches (5224). These switches have an issue when dealing with complex networks (WAN/LAN, routers, switches from different vendors), so they seem to often forget the network addresses entries and have to re-learn them, momentarily blocking packet transmission. This makes Retrospect VERY SLOW, and topping CPU utilization at 100% We tried Cisco switches, and now Retrospect flies! Mb/min jumped from about 300 to more than 2,500. Hope this helps. Saludos Link to comment Share on other sites More sharing options...
jcapslock Posted July 7, 2005 Author Report Share Posted July 7, 2005 The backup computer is connected to an HP procurve switch and the application acts slow even right after a fresh reboot with no backup activities going on. Link to comment Share on other sites More sharing options...
mauricev Posted July 13, 2005 Report Share Posted July 13, 2005 What happens if you tell R to to turn off all executions, then quit and restart it? What happens if you quit R, temporarily move the configuration out of the Retrospect config folder and then restart R? Link to comment Share on other sites More sharing options...
jcapslock Posted July 19, 2005 Author Report Share Posted July 19, 2005 Support told me it was probably a corrupt config file. So I painstakingly rebuilt it. Everything seemed to be working fine until the end of the day when I enabled proactive backups. Since I have noticed that the GUI gets unresponsive when proactive backups are enabled during the phase when it scans for its next target. Once it finds a target and marks the rest of the sources as busy then it is responsive again until it finishes and returns to scanning. It also occurs during the matching phase of any backup (proactive or scheduled). Does that make any sense? I haven't had a chance to call and investigate further yet. Link to comment Share on other sites More sharing options...
awnews Posted July 19, 2005 Report Share Posted July 19, 2005 I have also found the GUI to be "unresponsive" (slow) when running Proactive even if no backups are currently running. I usually turn off (red X) Retrospect and/or proactive backups while I'm working with Retrospect (.301), make my changes, then turn it back on. Link to comment Share on other sites More sharing options...
mauricev Posted July 22, 2005 Report Share Posted July 22, 2005 Quote: Support told me it was probably a corrupt config file They should not have told you that. For one thing, the config file never gets corrupted. For another, it's easy to test by moving it out of the way temporarily. What version of Retrospect are you using? 6.5 majorly locked up the UI when proactive was running. This issue was fixed in 7. Link to comment Share on other sites More sharing options...
jcapslock Posted July 27, 2005 Author Report Share Posted July 27, 2005 They should not have told you that. For one thing, the config file never gets corrupted. For another, it's easy to test by moving it out of the way temporarily. What version of Retrospect are you using? 6.5 majorly locked up the UI when proactive was running. This issue was fixed in 7. We did rename the config, and I put it back when I found it not to fix the problem. But I had disabled executions while building the config. All day the UI was blazingly fast, and I thought I had it. At the end of the day when I enabled proactive backs I noticed the UI slowed down again. It is enough to be annoying, so like GoAWest suggested, I have learned to disable proactive backs when I need to do some configuration, or check log files. Otherwise the UI behaves in a bursty way. Pausing for 2 or 3 seconds, then letting me do several operations and repeating. I am using the Version 7 latest build (301) of retrospect, with the latest update file. I could even live with this, but the other problem I am having is the app will sometimes lock up solidly. (Not the computer, but the application). The window for retrospect will be filled with a white background and no text, and all disk activity will be stopped. If I end task it and restart it, it works fine. Just seems to punk out. This occurs even on a fresh reinstall of the operating system. It seems like I can get it to happen for sure when I try to write to multiple disk sets that are on the same logical drive simaltaneously. But lately its been happening even on the backup setup we have now, which is 3 sets on seperate drives. There are no errors in the event log, and the disk controller does not have any alerts. I've tried different disk controllers, different motherboard, reinstalling operating system and backupsoftware. It is becoming very frustrating. I had it suggested that it could be a the software overloading the bus, but I find that ridiculous when the average network backup is running at about 100 MB/min. When the app locks up the CPU utilization is about 1% and there is plenty of RAM left. While running all 3 clients, the network performance monitor rarely gets over 5% utilization. My end goal is to configure a large raid array, and back up to 8 sets simaltaneously, making a snapshot transfer once a week for offsite. But there is no way with the current behavior. Link to comment Share on other sites More sharing options...
knick Posted July 29, 2005 Report Share Posted July 29, 2005 Hi All - I came here today because of similar issues with 6.5.350 MS. We're backing up pieces of about 60 machines to single backup sets spread over many different subnets on a campus. You might imagine the variety of switches/routers/firewalls involved. Backing up on a Server 2003 machine with a 3 Ghz cpu, 1 GB ram to a single AIT tape drive and a single two drive SATA raid 0 array hooked to an Adaptec PCI adapter. Proactive is running, looking for a handful of laptops. This machine does only a little light print serving otherwise. The config65.dat file is up to 17MB+ and the recorded Retrospect Memory Usage often now gets up to 120+ MB. Backup speeds show anywhere from 30-300 MB/min for PC's, depending upon the connection and speed of the client. Mac O/S X clients get up to 450MB/min (perhaps still showing it's roots ). I went through some teething problems upgrading to the SATA external array. Initially the SiliconGraphics card was showing severe driver issues with timeouts, and seemed to be implicated in the symptoms described below, but switching to the Adaptec card and rebuilding the array seems to have solved that issue. All will be well for hours at a time - even a day or two - even with multiple threads actively doing something. Then the GUI gets unresponsive as retrospect.exe pegs the CPU at 50-70%. I can sometimes duplicate this behavior simply by editing a Proactive script. Or it will lock up severely enough overnight to finally force a crude reboot of the machine - showing fatal errors such as "failure at elem.cpp-867 or graf.cpp-1719 or tstring.cpp-1453". Sometimes showing the same behavior of the blank window and no activity as above. Network issues are prevalent: PC clients showing "in use" after a backup, or coming up grayed out, requiring a 'repair' or sometimes an uninstall/reinstall/reconnect to spring back to life. Client not found errors seem to be part of the mix, perhaps part of a complete lockup. I too think Proactive Backup is partially to blame. While reading the previous posts, I've just reset the polling intervals on the active scripts to the max of 60 minutes to see if this makes any difference and will report back. I was hoping that a move to Ver 7 might catch some of these problems, but am now sort of thinking that may not be the case. What size are others config files? I sense that these fairly large files are very cpu intensive for Retrospect to deal with in it's 'in-line' fashion and contributes to the general molasses problem. More on this soon, Nick.. Link to comment Share on other sites More sharing options...
jcapslock Posted August 11, 2005 Author Report Share Posted August 11, 2005 For the last few weeks I have had no problems with backups. I think the problem only occurs when proactive backups and regular scripts are running at the same time. I even have multiple scripts writing to the same raid 5 volume, which is what I was thinking was causing the application to lock up. However, this week when I changed the backup to do proactive backups of all the desktops, and a script backup of the servers, it locked up the app with the patented retrospect window with nothing but a white background. No error messages, no way to see status, no activity on the hard disks. For the last 2 weeks when it was running without issue, I had proactive backups disabled during the night and enabled only during the day for observation. Anyone else have troubles running proactive scripts and regular scripts at the same time? Mark Link to comment Share on other sites More sharing options...
knick Posted September 1, 2005 Report Share Posted September 1, 2005 Hi All - In my environment (see above), there is a definite correlation between the mixed running of regular and proactive scripts versus the molasses quality of gui interaction with Retrospect and the general slowdown as outlined above. When I finally changed all three of the Polling options of the dozen proactive scripts running from the default values to 30 minutes, general responsiveness is better and Retrospect became somewhat more stable. But an even better fix, with vastly improved stability after 4 days with no freezes needing reboots, came after I installed a BIOS update to the Adaptec 1210SA SATA Raid card that connects my two drive Raid 0 array from Granite Digital and updated the driver to one that noted it was a fix to "some problems with large Hitachi SATA drives". In particular, network issues such as not finding clients, etc. no longer _seem_ to send Retrospect into hibernation. I suppose this underlines the importance of all parts of the puzzle when troubleshooting problems of this sort. After another week or so I'll update this post if any changes. Nick Link to comment Share on other sites More sharing options...
Lennart_T Posted September 29, 2005 Report Share Posted September 29, 2005 Quote: I have also found the GUI to be "unresponsive" (slow) when running Proactive even if no backups are currently running. I usually turn off (red X) Retrospect and/or proactive backups while I'm working with Retrospect (.301), make my changes, then turn it back on. This was never a problem for me using version 6.5.350. This week we upgraded to 7.0.326 and immediately noticed the SLOW user interface. It usually takes 2 seconds to respond to a click. Even when clicking a "Cancel" button it takes seconds just to close the window. Turning off Proactive makes it better, but that is only feasable when no client is executing. I consider this behaviour a bug in Retrospect 7 and expect it to be fixed. Link to comment Share on other sites More sharing options...
natew Posted September 30, 2005 Report Share Posted September 30, 2005 Hi Did you try changing the polling interval as outlined above by Nick Keene? Thanks Nate Link to comment Share on other sites More sharing options...
Lennart_T Posted September 30, 2005 Report Share Posted September 30, 2005 Quote: Did you try changing the polling interval as outlined above by Nick Keene? Hi. No, I can't possibly allow 30 minutes waiting between polls. I increased the time from 90 seconds to 5 minutes (since it does take more time than that anyway). We just ran a "New media backup" so there will be no idle time until Monday. The funny thing is: When backup up, Retrospect is responsive. It's when polling for (new) clients it's so slow. Thanks Link to comment Share on other sites More sharing options...
natew Posted October 3, 2005 Report Share Posted October 3, 2005 Hi You may want to delete all the items in your backup report and then close Retrospect. This will reset all of the backup status on your proactive sources to ASAP. It would also remove any corruption related to proactive backup. Thanks Nate Link to comment Share on other sites More sharing options...
Lennart_T Posted October 4, 2005 Report Share Posted October 4, 2005 Quote: You may want to delete all the items in your backup report and then close Retrospect. This will reset all of the backup status on your proactive sources to ASAP. It would also remove any corruption related to proactive backup. That brings up two other problems: 1) We do a New Media Backup every Friday. Immediately after that, the backup report is completely empty, save for a handful of events concerning old client computers. I want to see who haven't been backed up since last week, but I can't. 2) After opening and closing the backup report, the log fills with this message: TGraf:CreateOffScrBitmap: Could not create offscreen bitmap: 4 865 800 x 546 TGraf:CreateOffScrBitmap: Could not create offscreen bitmap: 4 865 800 x 546 TGraf:CreateOffScrBitmap: Could not create offscreen bitmap: 4 865 800 x 546 (The log fills with a rate of about 10 lines per second, so the log very quickly becomes useless) At the same time, the status lines in Activity Monitor: Execution starts to flicker so it's almost unreadable. EDIT: It's always "4 865 800", but the last number ("546") varies between sessions. I exit Retropsect to fix the problem. Anyway, I cleared ALL events from the backup report and I will see it that helps. Link to comment Share on other sites More sharing options...
Lennart_T Posted October 4, 2005 Report Share Posted October 4, 2005 Quote: You may want to delete all the items in your backup report and then close Retrospect. This will reset all of the backup status on your proactive sources to ASAP. It would also remove any corruption related to proactive backup. Hi. It did not help. It's still slow when polling for clients. Regards Link to comment Share on other sites More sharing options...
natew Posted October 5, 2005 Report Share Posted October 5, 2005 Hi I'm wondering if you don't have some corrupt retrospect preference files. The backup report and proactive rely heavily on each other. It looks like they are both hosed to me. Try this: Rename the folowing folder to Retrospect-old. c:\documents and settings\all users\application data\Retrospect Then launch Retrospect and set up some simple proactive test scripts to see if the sluggisness and problems in the backup report occur. Let us know what you find. Thanks nate Link to comment Share on other sites More sharing options...
Lennart_T Posted October 5, 2005 Report Share Posted October 5, 2005 Hi. Renaming the Retrospect folder seemed to do the trick. Although I added just four clients it seemed to work fine when polling and nothing bad happened after opening/closing the backup report. What is the next step? I hope I don't have to add all clients again, redo all scripts etc. Regards Link to comment Share on other sites More sharing options...
natew Posted October 6, 2005 Report Share Posted October 6, 2005 Hi I hate to say it but you may have to do just that. You upgraded from 6.5 right? My guess is the import of preferences from 6.5 to 7.0 didn't go well. There may have been some corruption in your original preferences. One last ditch thing you could try: Remove the two new config70 files from the Retrospect preference folder. Put your 6.5 preferences in there. Launch Retrospect again. This will import your old preferences again. It may work better this time. Thanks Nate Link to comment Share on other sites More sharing options...
Lennart_T Posted October 6, 2005 Report Share Posted October 6, 2005 Hi. I tried the last ditch thing and the "Could not create offscreen bitmap" messages seems to be gone after opening and closing the backup report. The GUI was still slow when polling clients, though. If the backup report empties itself after the New Media Backup tomorrow, we'll have to remove the folder and start from scratch. (sigh). Thanks Link to comment Share on other sites More sharing options...
Lennart_T Posted October 10, 2005 Report Share Posted October 10, 2005 The backup report did NOT clear itself after the New Media Backup. That's the first time for over a year it works. Hooray!! I think I just will have to live with the slow GUI. Link to comment Share on other sites More sharing options...
mwdilday Posted February 7, 2006 Report Share Posted February 7, 2006 It seems that if you open TCP/IP port 2000 on the Windows firewall it solves the problem. I was having it repeatedly - after starting Retroexpress HD it would continue to consume CPU % until it reached 100% utilization and the applications started slowing down. I opened the port and it is working ok now. Link to comment Share on other sites More sharing options...
mwdilday Posted February 7, 2006 Report Share Posted February 7, 2006 I was having the same problem with Retrospect Express HD - CPU % would continue to increase and eventually reach near 100% and computer would slow. Terminating Retrospect.exe would fix it but restarting it began the cycle all over again. I opened TCP/IP port 2000 on the XP firewall and it seems to have fixed it. Link to comment Share on other sites More sharing options...
Mayoff Posted February 8, 2006 Report Share Posted February 8, 2006 The 100% CPU utilization issues have been fixed in Retrospect 7.5. This new version has many new speed improvements. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.