Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On 06/20/2012 02:34 PM, Phil Frost wrote: > What OS and kernel version are you running? Also, when you say slower > with both nodes present, is it slower enough to indicate that fsync > is working? They're old CentOS boxes running 2.6.18. So far as the latency, I'm not sure, but I doubt it's responsible; we have a direct 10G link between the two machines. For what it's worth, we are running XFS, so it's not a very good comparison. I don't use EXT4 in production environments. > In the case of small synchronous writes, I'd expect any difference in > latency to be indistinguishable from measurement error. FusionIO drives here. Our PostgreSQL sync calls, based on checkpoint logging, are almost 2x slower with a connected DRBD resource, than when it's in standalone. About what you'd expect, actually. We have a test cluster on a simple RAID0 with much newer OS running a 3.2 kernel, too. That's where I noticed a Pacemaker failover would attempt to start the LVM service before DRBD was done promoting during a manual failover. I had to add a 2-second start delay, which tells me the DRBD RA is not waiting long enough before returning control to Pacemaker. I suppose that could be sync related, but I haven't run any specific tests. > For that matter, is anyone absolutely sure that fsync is working on > their DRBD devices? I can confirm it works in our existing setup. We run a 10ktps OLTP database on Postgres and have experienced a few unplanned outages where we failed over to the other node. If DRBD was having trouble, we'd have ripped it out and bought a SAN long ago. I haven't done enough tests in our dev environment with the updated kernel/DRBD to know for sure. If I have time later, I'll run a quick dd test. -- Shaun Thomas OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604 312-444-8534 sthomas at optionshouse.com ______________________________________________ See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email