Slow running backup
Posted in 2020
Amit Patel asked how to diagnose a slow ontape backup. Art Kagel suggested onstat -z then onstat -D and noted physical-log overhead; Mark Jalkiewicz suggested archiving to /dev/null and onstat -g stq; Andreas Legner suggested onstat -g arc; Doug Lawry suggested BACKUP_FILTER with pigz. John Smith could not stop a runaway onbar archive with onmode -z. Unresolved.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
Topics: Backup & Restore
Hello everyone,
If the backup is running slow thru ontape command , how can we check that and what could be the reason for slow backup?
And what could be the resolution?
Thanks
Amit Patel
------------------------------
AMIT PATEL
------------------------------
#Informix
Amit:
You can check the progress of archives by zeroing out stats at the beginning of the archive (onstat -z) then monitoring the reads with onstat -D where you can see the heavy read activity slide from one chunk to another dbspace by dbspace.
As to causes, heavy update activity can increase activity in the physical log. Pages written there have to be copied to temp tables (one for each dbspace) until the dbspace associated with each is completed and the temp table contents are pushed out to the archive. So, the more update activity the more extra IO for physical log pages. In addition high disk activity will slow the reads the archive needs. Beyond that, contention for the chunk drives and/or archive target from other applications not related to the database and the archive will have an effect. If you are archiving across the network then network contention will also affect performance.
Art
Art S. Kagel, President and Principal Consultant
ASK Database Management
www.askdbmgt.com
Blog:
http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves.
variety of reasons.
a very simple test will be to take a level 0 archive to /dev/null. If the time is still slow then its probably due to either a lot of database activity or i/o transfer rate back from the storage where the db chunks reside. If fast then it's the transfer rate to the backup device that's probably the root cause.
Then again if your backing up to nas device then there is the network to consider.
you can use onstat -g stq to monitor the archive stream queue buffers. See the below link for more info.
https://www.ibm.com/support/pages/node/548407
You can try 'dd' command to see the IO speed where you are taking backup and its an OS utility ------------------------------ Gaurav Kumar ------------------------------
Hi Amit Here is a link to an IBM post from 2018 that attempts to address what seems to be the exact issue that you are experiencing... https://www.ibm.com/support/pages/slow-ontape-backup-or-archive-informix-database-server-instance Bst Rgds Kirit ------------------------------ Kirit Rana ------------------------------
Apart from the good insights from Art and Mark, some concurrent activities like update stats, data purging tasks can actually impact Level-0 performance. Create job schedule that eliminates the concurrent run of such activities.
Can we just stop the backup ? slow backup is still running using more and more virtual memory , i tried onmode -F but nothing changing
i do backup with onbar to a backup manager
thanks
------------------------------
John Smith
------------------------------
You can try to onmode -z the archive session.
------------------------------
Art S. Kagel, President and Principal Consultant
ASK Database Management Corp.
www.askdbmgt.com
------------------------------
yes i just figure it out with some commandes -g mem , the arc process is suffixed with the session id ;) thanks Art :) ------------------------------ John Smith ------------------------------
You'd monitor an ongoing archive through 'onstat -g arc'.
This, between archives, has the spaces' Archive Status only, yet, during an archive, starts on a block detailing spaces' before images temp partitions and current physical position of archive processes scanning the spaces ('scanner' column). Look at that scanner position and monitor its movement.
------------------------------
Andreas Legner
------------------------------
unfortnately does t work withe onmode -z, tried also with pid but the pid is no more present on the system !!
------------------------------
John Smith
------------------------------
One of the most common reasons is that the speed of your system transfer data is faster or slower than that of your backup system. In this case, the backup process will run unusually, such as too slowly. Hence, you ought to adjust the two speeds to match with each other. ------------------------------ Mike Thompson ------------------------------
If the problem is slow network or target file system, consider compressing with multiple threads, for example:
BACKUP_FILTER 'pigz -b 4096 -p 8'
RESTORE_FILTER gunzip
See:
https://zlib.net/pigz
------------------------------Doug Lawry
Oninit Consulting
------------------------------
Related threads
- IDS not writing to online.log
- Help!!! syntax error
- installclientsdk bug?
- RamDisk tempdbs boot script for Linux