G
George Potemkin
Guest
Comparing the results posted by Stefan and James and the results from our customer I think we can say that the ratio between the times to backup to an existent vs new file is growing as a power of backup's size. And taking into account the units of measurement we, of course, should use a ratio of backup's size to a size of something else. The only candidate that come to my mind is the system memory. James' example: 500MB backup file is, of course, smaller than available RAM and the backup time is the same when it uses an existent or new file. Stefan's example: backup to an exiting file is 2-3 times slower. "20 Minutes to an non existing file" - I guess the size of backup is approximately 40 GB (estimating the backup's writes as 30 MB/sec). Most likely backup's size is a few times larger than RAM. In the case of our customer the size of backup file is almost 150 GB - much bigger than available memory and backup to an exiting file is 16-17 times slower. If the issue indeed depends on ratio between the size of backup and system memory then I would say it's not a Progress issue. I guess the issue can be reproduced by a simple 4GL program (provided you have 40 GB of free space on your disk and available RAM is a few times smaller than 40 GB): OUTPUT TO VALUE(OutputFile) APPEND. SEEK OUTPUT TO 0. DO i = 10000000: PUT StringWith4KSize. END. OUTPUT CLOSE.
Continue reading...
Continue reading...