Indeed Engineering Blog
engineering.indeedblog.com · Company blog · on HN since 2015
Indeed Engineering Blog is the company blog of the job site's engineers, covering Java, Linux, CI, and infrastructure performance.
What HN saysHN commenters cite its detailed posts on CPU throttling fixes in the Linux kernel and on its LSM-tree architecture.
16HN people shared it
4linked it in comments
14stories submitted
165story points
8 months agolast shared
2015people per year2026
Most-shared posts
- 1JRE 8 needs more codecache than before3 people · 131 points · first shared 2016 · 37 comments on HN
- 2Reducing cgroup CPU throttling on Linux machines with many cores2 people · 4 points · first shared 2019 · discussion on HN
- 3Unthrottled: Fixing CPU Limits in the Cloud2 people · 4 points · first shared 2019 · discussion on HN
- 4Indeed MPH: Fast and Compact Immutable Key-Value Stores1 people · 10 points · first shared 2021 · discussion on HN
- 5How Indeed Replaced Its CI Platform with Gitlab CI1 people · 4 points · first shared 2024 · discussion on HN
- 6Being Just Reliable Enough1 people · 3 points · first shared 2021 · discussion on HN
- 7Speed Matters, but It Isn’t Everything1 people · 2 points · first shared 2022 · discussion on HN
- 8Finding Great (and Profitable) Ideas in the Computer Science Literature1 people · 2 points · first shared 2015 · discussion on HN
- 9The Importance of Using a Composite Metric to Measure Performance1 people · 1 points · first shared 2024 · discussion on HN
- 10How Indeed leverages BitTorrent to geo-replicate data (2016)1 people · 1 points · first shared 2017 · discussion on HN
- 11Become Builders, Not Coders1 people · 1 points · first shared 2026 · 1 comments on HN
- 12Normalizing Resume Text in the Age of Ninjas, Rockstars, and Wizards1 people · 1 points · first shared 2019 · discussion on HN
- 13The FOSS Contributor Fund: Forming a Community of Adopters1 people · 1 points · first shared 2019 · discussion on HN
- 141 1 billion evolution document serving system1 people · first shared 2022
- 15Serving over 1 billion documents per day with docstore v21 people · first shared 2018
What HN people wrote when they linked it
billsmithaustin · 2022-02-09
Indeed published a pair of blog posts back in 2013 on how they evolved their architecture to use LSM trees.
Part 1: https://engineering.indeedblog.com/talks/1-1-billion-evolution-documen…
Part 2: https://engineering.indeedblog.com/blog/2013/10/serving-over-1-billion…
ledneb · 2020-09-02
> https://engineering.indeedblog.com/blog/2019/12/unthrottled-fixing-cpu…
This is a more detailed post on the same thing - part two indicates changes have been back-ported to a number of kernel versions:
Linux-stable: 4.14.154+, 4.19.84+, 5.3.9+
Ubuntu: 4.15.0-67+, 5.3.0-24+
Redhat Enterprise Linux:
RHEL 7: 3.10.0-1062.8.1.el7+
RHEL 8: 4.18.0-147.2.1.el8_1+
CoreOS: v4.19.84+
lovelearning · 2018-03-21
"Contract won't or shouldn't change" seems unrealistically idealistic to me. Java migration - or any platform for that matter - is not just migrating its language features but also its ecosystem - runtime, VM, GC, frameworks.
There are many examples of migration problems for any platform - just have to google it. When information that can challenge our assumptions is just a google search away, I don't see why one should hold on to blind faith in idealistic assumptions. Here's one writeup of a system whose performance suffered simply by migrating to Java 8 without involving any code changes [1].
[1]: http://engineering.indeedblog.com/blog/2016/09/job-search-web-app-java…
hyperpape · 2018-01-17
I'm not aware of any effort to retire tiered compilation. It was even promoted to be the default in Java 8 (2014). http://www.oracle.com/technetwork/articles/java/architect-evans-pt1-22…
The only downside I'm aware of is that it increases the pressure on the code cache. If your code cache is not large enough, it will thrash as methods are discarded then recompiled. We had significant performance problems with a server and it took quite awhile until we realized that was the cause. A cache of 256 mb was more than enough for us running a 2 million LOC monolith under Tomcat, so the absolute memory use isn't that significant. (Reference we found while researching: http://engineering.indeedblog.com/blog/2016/09/job-search-web-app-java…
Once you know this is an issue, it's easy to monitor, but it is one more thing that can go wrong in the JVM.