Amdump is terribly slow: Difference between revisions
Jump to navigation
Jump to search
(rv - spam) |
(reformatted from previous troubleshooting page) |
||
| Line 1: | Line 1: | ||
{{Troubleshooting Category|Amdump}} | |||
{{Troubleshooting Problem}} | |||
The performance of Amanda is not close to what your hardware is capable of. | |||
{{Troubleshooting Solution}} | |||
The plots generated by running [[amplot]] on the amdump.X files can quickly point to some bottlenecks in the setup. | The plots generated by running [[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 | |||
Revision as of 04:06, 7 April 2007
Template:Troubleshooting Category Template:Troubleshooting Problem The performance of Amanda is not close to what your hardware is capable of.
Template:Troubleshooting Solution The plots generated by running 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.
- 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.