Urs Rau schrieb: > Michael, > > Michael Chinn wrote: >> One solution I used when rolling out a 40mb module was use a 2 stage >> loader/installer with wpkg. Our reason was to cater for field operators >> who only connect for short periods then go away for weeks at a time. >> eg:- >> Package Loader - Copies the installer to the machine using something >> like Robocopy, stores it in %windir%\temp, tests for file on succeed >> Package Installer - Depends on Loader, runs installer from %temp%, tests >> for program installation, if space is an issue deletes zip file from >> temp and creates a 0 length package.zip so that loader doesnt repeat >> >> One of the benefits of robocopy is you can control the download rate and >> retry on fail. >> > > Thanks so much for this. This 'work-around' will make it work, even if > we choose to install even bigger pkgs like MS Office etc. Your > suggestion is much appreciated.
How about trying to find out what causes the load? How much memory is used/free/used for buffers? I once had a series of Fujitsu-Siemens servers which apparently didn't like increased disk reads/network transfers - something screwed with the interrupts, and the server was practically unresponsive. Disabling ACPI was a workaround, and upgrading to a newer kernel fixed the issue. Although, it may be hard to reproduce the load in production environment? :) -- Tomasz Chmielewski http://wpkg.org ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ wpkg-users mailing list wpkg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wpkg-users
