|
2013/8/22 Julian Anastasov <ja@xxxxxx>:
>
> Hello,
>
> On Thu, 22 Aug 2013, Drunkard Zhang wrote:
>
>> 2013/8/22 Julian Anastasov <ja@xxxxxx>:
>> >
>> > No kernel options should be related to OPS. I assume
>> > you are not using the SH scheduler. Make sure the OPS mode
>> > is properly applied to the virtual service, check for "ops"
>> > in the configuration:
>> >
>> > cat /proc/net/ip_vs
>>
>> Still no lucky here, ops is set in running config, but it's not like
>> that in real world.
>>
>> vs3 ~ # cat /proc/net/ip_vs
>> IP Virtual Server version 1.2.1 (size=1024)
>> Prot LocalAddress:Port Scheduler Flags
>> -> RemoteAddress:Port Forward Weight ActiveConn InActConn
>> UDP 96A46478:0202 wrr ops
>
>> -> 96A46450:0202 Route 25 0 1
>
> The OPS connections are accounted in InActConn
> for a very short period, they live up to 1 jiffie, eg. 10ms.
> Also, WRR should be reliable for OPS while other
> schedulers (eg. *LC) are not suitable.
I noticed this too. While ops working, the InActConn is always
changing too, if it's fixed, the ops is not working.
>> And the traffic routed to each realserver didn't following weight I
>> set, it's routed pretty much one to one. I got 17 udp sources sending
>> to 16 different realservers, the others are bonding to another VIP.
>>
>> Prot LocalAddress:Port CPS InPPS OutPPS InBPS
>> OutBPS
>> -> RemoteAddress:Port
>> UDP x.x.x.120:514 0 67622 0 12339373 0
>> -> x.x.x.65:514 0 29 0 2895 0
>> -> x.x.x.66:514 0 225 0 21850 0
>
> Do you see the same problem with ipvsadm -Ln --stats ?
> ipvsadm -Z may be needed to zero the stats after restoring all
> rules. "Conns" counter in stats should be according to WRR
> weights, it shows the scheduler decisions.
After every restore, the stats also zeroed, right? While, ops still not working.
vs3 ~/pkgs # ./ipvsadm -Z
vs3 ~/pkgs # ./ipvsadm -ln --stats -u [snipped]
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
UDP x.x.x.120:514 0 12497040 0 2572M 0
-> x.x.x.65:514 0 3975 0 394171 0
-> x.x.x.66:514 0 48466 0 4835716 0
-> x.x.x.67:514 0 407051 0 58479621 0
-> x.x.x.68:514 0 561120 0 85289892 0
-> x.x.x.69:514 0 30958 0 3120506 0
-> x.x.x.70:514 0 645475 0 100552K 0
-> x.x.x.71:514 0 147228 0 14560649 0
-> x.x.x.72:514 0 535693 0 84069390 0
-> x.x.x.73:514 0 564787 0 88165140 0
-> x.x.x.74:514 0 346734 0 53256088 0
-> x.x.x.75:514 0 47232 0 4801578 0
-> x.x.x.76:514 0 1175288 0 192699K 0
-> x.x.x.77:514 0 254915 0 25939720 0
-> x.x.x.78:514 0 2701531 0 652417K 0
-> x.x.x.79:514 0 2426686 0 573897K 0
-> x.x.x.80:514 0 2599901 0 629793K 0
-> x.x.x.81:514 0 0 0 0 0
-> x.x.x.82:514 0 0 0 0 0
-> x.x.x.83:514 0 0 0 0 0
-> x.x.x.84:514 0 0 0 0 0
-> x.x.x.85:514 0 0 0 0 0
-> x.x.x.86:514 0 0 0 0 0
-> x.x.x.87:514 0 0 0 0 0
-> x.x.x.88:514 0 0 0 0 0
-> x.x.x.89:514 0 0 0 0 0
> In your rates listing CPS 0 is confusing, even for OPS.
> Is it from the new ipvsadm?
Yes, latest git version. When CPS is changing, the ops works, or it's not.
--
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|
