|
Uh, I forgot to report that I've already tested also with setting
different --syncid for master1/backup2 and master2/backup1 but the
result is the same.
Besides, please note that if I run only 1 syncmaster, the CPU load is
stable at 1.0, with 2 syncmaster is stable at 2.0, so, unfortunately,
this does not help :-(
IMO the problem is in the kernel thread itself.
I've also tried with 2.4.27, but I get an error regarding the "backup"
option which is not supported. So I get only 1 syncmaster running,
which "ps" reports in the state of "S" (sleeping) as it should be and
the load is 0.0.
Thank you anyway for your time.
Cheers,
Luca
On 15/09/05, Graeme Fowler <graeme@xxxxxxxxxxx> wrote:
> Hi
>
> Just thinking out loud... are these two getting trapped in a sort of
> "deadlock" - syncmaster1 multicasts, syncbackup2 picks it up,
> syncmaster2 sends it back via multicast, syncbackup1 picks it up, and
> so on, and so forth.
>
> I notice that you're not setting the --syncid flag in your command
> lines. Wouldn't that mean they're both using the same ID, and therefore
> continually "swapping" data as described above?
>
> --syncid syncid
> Specify the syncid that the sync master daemon fills in the
> SyncID header while sending multicast messages, or the sync
> backup daemon uses to filter out multicast messages not matched
> with the SyncID value. The valid values of syncid are 0 through
> to 255. The default is 0, which means no filtering at all.
>
> I'd try a unique syncid for syncmaster1/syncbackup2, and a separate one
> for syncmaster2/syncbackup1.
>
> Graeme
>
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
>
|
