Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi drbd-users,
Have been working with DRBD at a basic level for a whole year now with very good results.
But now after changing one of two servers to an old slower machine I got problem with application response
time.
It happends only after QuickSync and Connected drbd servers.
Just now I'm working with drbd version 0.6.12, have tried 0.6.13 with the same result, and kernel 2.4.21-20.
For a lot of reasons I can not change to drbd 0.7.11 or kernel version just now.
Hope it don't look like the Stone Age for you.
I am controlling drbd via drbdsetup commands inside my application on the Secondary server like this:
Connecting with: "drbdsetup /dev/nb0 net <own_server> <partner server> C -r 10M -t 20 -c 4 -s 5000"
Dis-connecting with: "drbdsetup /dev/nb0 disconnect".
Primary is always Connected or WFConnection. No drbd configuration file used.
First time connecting and after a successful "Full Sync" everything is OK and all reponse times are normal!
BUT after a disconnection and a new connect, drbd makes correctly a "QuickSync", the response times when
Connected now follows the "-t 20" parameter value above.
Changing this parameter I can change the respone time accordingly.
The slower machine is always Primary when the problem occurs.
With the help of tcpdump and some trace printouts inside drbd my understanding of drbd behavior look like this:
Connection phase looks Ok, same as after "FullSync".
Then after each data transfer from Primary to Secondary, the Secondary acknowledged at TCP level Ok but
the "DRBD Data Acknowledge" is missing.
After "-t 20" (2 seconds) Primary got response timeout and sends a DRBD_Ping, to try the connection,
which Secondary immediately acknowledged and immediately after this the Secondary also sends
the missing "DRBD Data Acknowledge".
When Primary receives "DRBD Data Acknowledge" it sends next Data block, waits for response 2 seconds,
times out and sends DRBD_Ping "und so weiter"..........
Result is a 2 seconds delay for every disk access..
Have anyone seen this situation and perhaps even know how to solve it.
I would be very grateful for any kind of help and information.
Best Regards, Hans.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20050817/9d1bdeae/attachment.htm>