Egon Burgener wrote:
And you are convinced that drdb's primary-primary is not the
cause for the slowdown. ??
Yes, writing a file is fast. Reading a file has no influence on drbd.

We noticed, that reading a big file on one node while the other node
opened that file in RW mode but without writing anything is still fast.
That's not surprising as both nodes with be holding PR locks on the lockres.

If the writing node writes slowly to the file (e.g. a logline per
second) reading from the other node is also fast.
Here the write nodes lock is ping ponging between EX and PR whereas read nodes
is between NL and PR.

 As soon as the writing
speed increases (e.g. a logline per 1/3 second) reading blocks. While
tcpdumping all these scenarios we noticed, that the blocking scenario
produces much more connections (ocfs2 protocol).
Reading blocks? or is it very slow? How are you doing the reads? tail -f?
Can you share the tcpdumps with me?

Finally we tried to buffer the write operations and flushing it each
second. The result was, that writing many loglines per second did not
block the reading process on the other node
How are you buffering? As in, are you saying that you were using o_sync
and no longer using that (or reducing the number of fsyncs). Or, is the buffering
in the app layer?

I mean, if you are issuing writes (buffered or not), ocfs2 will still take the appropriate
lock level.

_______________________________________________
Ocfs2-users mailing list
[email protected]
http://oss.oracle.com/mailman/listinfo/ocfs2-users

Reply via email to