Treece, Britt wrote:
Wendy,
Unfortunately our customer has (for the time being) moved their PHP
sessions off of the GFS filesystem because of the instability. Our GFS
performance has returned to normal, but our customer expects us to fix
GFS so that they can have the PHP sessions on GFS. I'm *attempting* to
reproduce the behavior on a lab GFS cluster. Assuming I can
successfully do this I will send strace's of the issue as it occurs.
So this problem doesn't show up in local filesystem ? Is it ext3 ? Also
I prefer thread back trace in kernel mode (sysrq-t and/or crash output)
to strace - since thread kernel back trace can really show where it gets
stuck. If you plan to recreate this in your lab, turn the fencing off
(make heart beat interval very long) so we can get a decent sysrq-t output.
Is Redhat aware of any issues with GFS and flock syscalls?
Will check but I don't recall such issues from top of my head.
Regarding the U7 kernel suggestion you made previously, is this going to
help with the flock issue or is it strictly for keeping the number of
cached locks down?
The new tuning parameters added into U7 do help with several lock
latency issues. Based on your lockspace output, I strongly believe they
can help. However, they can't do much if the bottleneck of your
customer's application is in flock as described in previous post.
-- Wendy
--
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
