> El 5/5/2015, a las 12:15, Nick Upson n...@telensa.com [firebird-support] > <firebird-support@yahoogroups.com> escribió: > > Hi > > I have a system that is slowing down the longer it stays running and I'd like > to know why. > > The system is running firebird 2.1.5 on centos 5 with an average of 27 > transactions per second and has now been running for 112 days. The data > throughput is unchanged, data is removed from the db as fast as its added so > the database remains roughly the same size at 130Gb. > > for example: on 1st Feb the backup took 4hr 35 min, last night took 9hrs 30 > min > > Is this a known 2.1 issue (move to 2.5 is in the planning stages)? > > Is there anything I can do to prevent or improve this situation? > > Is there any evidence I can gather before I reboot the system which I expect > (from past experience) will return the system to the better performance > Hello, I think the problem is the database fragmentation along the time. I have databases in production 24x7x365.
Every night I do a sweep and after a backup. The database backup takes more and more time to complete, month by month, and the increase of time is not proportional to increase of db size. Two years ago one of our customer database was 30 Gb and took 1 hour to backup. Today the size is near 50 Gb and takes near 4 hour to backup. In other customers, where the size don't increase in that amount, the backup time increases month by month, more than database increased size. If I backup and restore on a test environment, the time is good. I think that a fresh restore has all table pages not fragmented. gbak backup table by table and having contiguous pages is better for backup performance. When users works on database, pages are not contiguous and to backup a table the hdd heads have to move to more places. Well, this is what I think about the increasing of backup time. I can't restart the server to test if that decrease backup time. I use windows 2008 >
