TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Uncovering performance regressions in the TCP SACKs vulnerability fixes

32 点作者 rxin超过 5 年前

1 comment

djhworld超过 5 年前
This is a fun write up to read, because I experienced exactly the same problem in a similar system dealing with lots of writes to S3. Sporadic 15 minute timeouts for no immediate reason, especially as the files were only a few megabytes in size.<p>It led to me going on a similar journey of diving deep into the stack right into doing diffs on the kernel tree to work out what had changed between kernel versions. Eventually I came to the same conclusion, and only recently the problem has been patched in CENTOS6&#x2F;RHEL6 <a href="https:&#x2F;&#x2F;access.redhat.com&#x2F;errata&#x2F;RHSA-2019:2736" rel="nofollow">https:&#x2F;&#x2F;access.redhat.com&#x2F;errata&#x2F;RHSA-2019:2736</a><p>Interestingly after identifying this problem, I also noticed similar behaviour on AWS Lambda shortly after June 20th, with the TCPWQueueTooBig metric spiking and causing Lambda timeouts. Took a few rounds through AWS support (and our account managers) to get them to look at it, but they eventually fixed it.<p>I think the common thread between this post and my experience is we are both using a Java&#x2F;JVM based stack. When trying to reproduce the bug for Amazon I could only reproduce it with a simple Java example, whereas my attempt with Golang seemed to run fine - so not really sure why that was.<p>Maybe I&#x27;ll write a similar blog about my findings, at least I learnt a lot from it!
评论 #21023556 未加载
评论 #21022781 未加载