lslb - ExtConn timed out while connecting.
 

My lslb error.log is getting flooded by the following notice:

the site is working fine, but what does this message mean?

edit:

debug stuff:

edit:

sometimes I'm getting the following warning:

the problem started after we've changed the connection from our database server to a gigabit port, but this change doesn't affected the loadbalancer or webserver, it just improved the page load speed.

btw. we had the "ExtConn timed out while connecting." notice sometimes before, but not that much like now.

edit:

nginx seems to loadbalance without any problems, so this seems to be a lslb problem

Please try command "telenet 192.168.0.4 80" from command line multiple times, see if you got long delay connecting to the target server sometimes.

edit: wrong section

I've no telnet installed, but I've tried it with nmap and nc, no problems so far.

ohps, could someone move this topic to the loadbalancer forum? my mistake.

I've switched to nginx until there is a solution, lslb doesn't run stable atm, I hope you guys can help us to fix this problem, lslb is our ddos protection and performs way better than nginx.

No problem. moved.
Have you specify the source IP when your configure each node?
Looks like lslb has problem connecting to all backend servers. could it be a problem with NIC port, switch port? If you use dedicate connection communicate with backend servers, you can check the packet loss of that specific NIC.
LSLB uses persistent connections, while nginx does not, there could be more ESTABLISHED connections with LSLB. Is there a firewall between LSLB and web servers?

If you do think it is a LSLB bug, could you strace lslbd while the problem is happening to help analyze the cause of the problem?

clusterHTTP config:
<nodeAddresses>(s1)127.0.0.1->192.168.0.3, (s2)127.0.0.1->192.168.0.4, (s4)127.0.0.1->192.168.0.5</nodeAddresses>

clusterStatic config:
<nodeAddresses>(s3)127.0.0.1->192.168.0.1:81</nodeAddresses>

I'll ask my provider if he could check the ports.

--- 192.168.0.3 ping statistics ---
272 packets transmitted, 263 received, 3&#37; packet loss, time 271515ms
rtt min/avg/max/mdev = 0.110/1.030/10.585/1.856 ms

I've disabled persistent connections in both clusters that I use.

nope

I'll do, but first I need to read some strace howto's :p

I think the problem is the source IP, should use a 192.168.0.x IP assigned to that server, or not use a source IP.

I've tried both, same problem.

3% packet loss for a LAN environment is extremely high.