:s is wafl updating special files in the CP process.
Going on _that_ long....??? A few seconds of special file updates in a CP sure, but that much?
I'd be pretty pushy on getting an answer, id put that in the "its a big bug" bucket. That's not normal IO activity in a healthy system.--
On Thu, Jan 17, 2013 at 8:07 PM, Scott Eno <s.eno@me.com> wrote:Yes, this is what I see. ":s" and all the other protocols go to "0".There's been some correlation, when this happens, to cleanup of VMware snapshots (not NetApp snaps on the volumes, but VMware snapshots of vm's via vcenter). But it happens other times too.On Jan 17, 2013, at 1:47 PM, Brian Beaulieu <brian.beaulieu@gmail.com> wrote:<sysstat - Copy.txt>_______________________________________________3rd time is the charm.I've attached my sysstat from the other night when NFS/CIFS hung up... is this what you've seen as well?During that issue, FCP was also slow.. had some MPIO failovers happening on our AIX LPARs. But, AIX handles that just fine and at least has an alternate path through the other filer. NFS isn't so lucky.I have a 3250+1TB PAM sitting on deck.. you'd think that the 3240+512GB PAM would be sufficient for what we do.While I do have SATA in use for VMWare, it's not heavy hitting VMs.. it's the dormant stuff, mostly.I'm moving a lot of it, though, to 6xDS4243x600GB-15k shelves ASAP.I'm drinking the PAM kool-aid too but do have some measurable results primarily on our PeopleSoft DB2 databases.I definitely wouldn't bet on SATA+PAM == FC/SAS performance.Brian
_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters
---
Gustatus Similis Pullus