couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oriol (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-1986) 04-replication-large-atts.t times out
Date Mon, 31 Mar 2014 16:33:17 GMT


Oriol commented on COUCHDB-1986:


We encountered a similar issue while uploading files to couchdb. For us, what made it really
slow is the fact that we have couchdb behind an nginx proxy, which means that all connections
go through the 'loopback' interface.

The issue was due to the MTU of the 'loopback' interface in linux (MTU:16436) that it is set
much bigger than on a physical ethernet nic (MTU:1500). This has a consequence on the MSS
on the TCP layer which in turn has a consequence on the amount of data that couchdb receives.

When sending a big file, all TCP packets are loaded with maximum payload up until the MSS
size, so more data is sent without any ACK from the server. That means that the receiver buffer
will fill up quicker on a 'loopback' interface than it does on a physical one. The default
socket parameters set in couchdb prevent couchdb to fetch data quick enough from the TCP layer
ending up on a 'TCP window full' situation. Ultimately, the connection is throttling at TCP
level making it really slow.

Increasing the 'recv_buffer size to 131072' prevents the TCP layer to throttle and the file
upload went, in our case, from 90 sec down to 0.7 secs.

Reducing the MTU size of the interface should also work though we haven't check that.

I don't really know if it is related to your specific issue but it may not be really onto
couchdb code but more on the way the connection is made at a TCP level.

Cheers, Oriol

> 04-replication-large-atts.t times out
> -------------------------------------
>                 Key: COUCHDB-1986
>                 URL:
>             Project: CouchDB
>          Issue Type: Bug
>          Components: Replication
>    Affects Versions: 1.5.0
>            Reporter: Jan Lehnardt
> 04-replication-large-atts.t gets stuck around 558, sometimes a little earlier or later,
but it times out eventually, regardless of the timeout. I tried doubling and such.

This message was sent by Atlassian JIRA

View raw message