up vote 0 down vote favorite
share [g+] share [fb]

i've set up a test machine (debian squeeze 2.6.32 on a linode 2048 machine) that interact with an api that returns large chunks of json. It calls the API 3000/minutes asynchronously, the api is returning payloads of ~450kb. There's also an http server on the box to display the calls results.

While doing netstat -s (uptime is 20 days):

 254329 packets pruned from receive queue because of socket buffer overrun
 50678438 packets collapsed in receive queue due to low socket buffer

This didn't sound good to me so I've followed these tutorials to tweak the TCP parameters:

http://fasterdata.es.net/fasterdata/host-tuning/linux/test-measurement-host-tuning/

and

http://www.acc.umu.se/~maswan/linux-netperf.txt

but it doesn't seems to help.

Any advice/tutorial/explaination about socket buffers that might help understanding and fixing the problem?

thanks

link|improve this question
When you say "it doesn't seem to help", how do you know? What's the rate (packets/second) at which packets are being prune/collapsed? What percent of total packets are getting pruned/collapsed? How did these values change before and after making the configuration changes you've described? How are you hosting the API? Is it your own code? Are you explicitly calling setsockopt() ? – larsks Jul 6 '11 at 2:50
I've calculate the average number of failure on the period before changing the TCP vars, waited 3 days and have calculated the failure rate on those 3 days, it remained constant. The api is the facebook one and this is my code running in nodejs. – hellvinz Jul 6 '11 at 10:20
feedback

Know someone who can answer? Share a link to this question via email, Google+, Twitter, or Facebook.

Your Answer

 
or
required, but never shown
discard

Browse other questions tagged or ask your own question.