Hi Dustin, Quote: "Perhaps Amanda's not *writing* data very quickly at that point - maybe your tape drive is shoe-shining?"
What do you mean by "shoe-shining"? Best, Valeriu On Wed, Sep 15, 2010 at 10:17:04PM -0500, Dustin J. Mitchell wrote: > On Wed, Sep 15, 2010 at 8:08 PM, Valeriu Mutu <[email protected]> wrote: > > /dev/mapper/cronos-amanda-holdingdisk > > ?? ?? ?? ?? ?? ?? ?? ??886G ??116G ??726G ??14% /data3 > > /dev/mapper/cronos-amanda-diskbuffer > > ?? ?? ?? ?? ?? ?? ?? ??394G ??199M ??374G ?? 1% /data4 > > 350G seems a bit large for a disk buffer - what part size are you using? > > > When the problem re-occurs, I change the MTU to a different value: if it's > > 9000bytes, I change it to 1500bytes, and vice-versa. > > > > Does anyone know why this happens? Why does Amanda become slow at reading > > from the holding disk residing on an iSCSI volume? > > I don't know much about iSCSI, but as you know Amanda just accesses > the disk via the normal filesystem, so I suspect that you could see a > similar phenomenon with any application that is reading from or > writing to the partition. > > Perhaps Amanda's not *writing* data very quickly at that point - maybe > your tape drive is shoe-shining? Interrupting the connection by > resetting the MTU (and I don't see why this would interrupt the > connection..) would allow several layers of buffers to flush, > resulting in a surge of read activity when connectivity is restored, > until the buffers are again full. > > It sounds like there are some unresolved network issues with iSCSI, if > the iptables is causing problems with multipathing. > > I would recommend taking a hard look with tcpdump to see what's going > on. You'll always learn something! I've found some people who were > complaining vociferously that Amanda's throughput "sucked", when in > fact their network had a high packet loss rate because their server > was hooked into a hub with a massive number of collisions. Hopefully > your situation isn't quite that dire.. > > Dustin > > -- > Open Source Storage Engineer > http://www.zmanda.com -- Valeriu Mutu
