Amdump is terribly slow: Difference between revisions
Jump to navigation
Jump to search
Paul.bijnens (talk | contribs) No edit summary |
(→Solution: man links) |
||
| (4 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
{{Troubleshooting Header}} | |||
=Problem= | |||
The performance of Amanda is not close to what your hardware is capable of. | |||
The plots generated by running | =Solution= | ||
The plots generated by running {{man|8|amplot}} on the amdump.X files can quickly point to some bottlenecks in the setup. | |||
* Are you using the holding disk? Large dumps may bypass the holdingdisk if that is not large enough. Typical for these DLE's is that dumper and taper speed are the same. You can also grep for 'PORT-DUMP' in the [[Amanda log files]]. | * Are you using the holding disk? Large dumps may bypass the holdingdisk if that is not large enough. Typical for these DLE's is that dumper and taper speed are the same. You can also grep for 'PORT-DUMP' in the [[Amanda log files]]. | ||
* Holdingdisk too small, resulting in less parallelisation? | * Holdingdisk too small, resulting in less parallelisation? | ||
* Is DMA enabled on the harddisks? What values are reported by <tt>hdparm -tT /dev/hda1</tt> (or whatever your drive is)? | |||
* Is DMA enabled on the harddisks? What values are reported by | * Have you specified a wrong value for bandwidth in the interface definitions? | ||
* Check for network problems, like wrong duplex setting on the interfaces? Look at the error counts on the interfaces in <tt>netstat -i</tt>. | |||
* | * Use "compression fast" instead of "compression best", or switch server/client compression if one of those is too slow; disable software compression for slowest computers. Enable hardware compression if your tape drive supports it (introducing a different set of problems!) (See also [[Amdump: data timeout]]) | ||
* Are other heavyweight programs running at the same time as backups are being done? | |||
* | * If estimates are too slow, consider switching to calcsize or server (statistics only) based estimates; see also [[Amdump: results missing]]. | ||
* Use "compression fast" instead of "compression best", or switch server/client compression if one of those is too slow; disable software compression for slowest computers. Enable hardware compression (introducing a different set of problems!) | |||
* | |||
* If estimates are too slow, consider switching to calcsize or server (statistics only) based estimates | |||
Latest revision as of 23:10, 30 June 2008
This article is a part of the Troubleshooting collection.
Problem
The performance of Amanda is not close to what your hardware is capable of.
Solution
The plots generated by running amplot(8) on the amdump.X files can quickly point to some bottlenecks in the setup.
- Are you using the holding disk? Large dumps may bypass the holdingdisk if that is not large enough. Typical for these DLE's is that dumper and taper speed are the same. You can also grep for 'PORT-DUMP' in the Amanda log files.
- Holdingdisk too small, resulting in less parallelisation?
- Is DMA enabled on the harddisks? What values are reported by hdparm -tT /dev/hda1 (or whatever your drive is)?
- Have you specified a wrong value for bandwidth in the interface definitions?
- Check for network problems, like wrong duplex setting on the interfaces? Look at the error counts on the interfaces in netstat -i.
- Use "compression fast" instead of "compression best", or switch server/client compression if one of those is too slow; disable software compression for slowest computers. Enable hardware compression if your tape drive supports it (introducing a different set of problems!) (See also Amdump: data timeout)
- Are other heavyweight programs running at the same time as backups are being done?
- If estimates are too slow, consider switching to calcsize or server (statistics only) based estimates; see also Amdump: results missing.