On 25 August 2017 at 04:47, Vijay Bellur <vbellur@xxxxxxxxxx> wrote:
-- Would it be possible to obtain a statedump of the native client when the application becomes completely unresponsive? A statedump can help in understanding operations within the gluster stack. Log file of the native client might also offer some clues.
I've increased logging to debug on both client and bricks, but didn't see anything that hinted at problems.
Maybe we have to go for Ganesha after all.
But currently we are stuck at the customer having trouble actually generating enough load to test the server with...
When I try to simulate the workload with a script that writes and renames files at the same rate the the video recorders do I can run it without any issue, and can ramp up to the point where I am hitting the network ceiling. So the gluster cluster is up to the task.
But the recorder software itself is running in to issues. Which makes me suspect that it may have to do with the way some aspects of it are coded. And it is there I am looking for answers. Any hints, like "if you call fopen() you should give these flags an not these flags or you get in to trouble"...
Krist
Vriendelijke Groet | Best Regards | Freundliche Grüße | Cordialement
![]()
Krist van Besien
senior architect, RHCE, RHCSA Open Stack
Red Hat Red Hat Switzerland S.A.
krist@xxxxxxxxxx M: +41-79-5936260
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-users
