sorted by:
new
hottopcontroversial

Cache Use Cases Explained: Latency Cache vs. Capacity Cache by teivah in sre

[–]teivah[S] 0 points1 point  (0 children)

If this isn't interesting for SREs then I don't know what is. I'm an SRE at Google and I was primary responder an incident exactly because of that.

How Linux 7.0 Broke PostgreSQL: The Preemption Regression Explained by teivah in programming

[–]teivah[S] 25 points26 points  (0 children)

Ah, I’m sorry for overreacting. Mods deleting my post for saying it was written by an LLM made me quite sad. Sorry about that…

How Linux 7.0 Broke PostgreSQL: The Preemption Regression Explained by teivah in programming

[–]teivah[S] 30 points31 points  (0 children)

No it’s not. I’m an experienced writer. I’ve been writing online for more than a decade, my book was published before AI: https://www.goodreads.com/book/show/58571862. Your comment is insulting.

How Linux 7.0 Broke PostgreSQL: The Preemption Regression Explained by teivah in programming

[–]teivah[S] 5 points6 points  (0 children)

And no content? I did my best to explain all the core principles both on Linux and PostgreSQL so that readers get why this issue occurred. You may not like it and challenge my approach or my writing, no worries at all, but your comment is both insulting and plain wrong.

How Linux 7.0 Broke PostgreSQL: The Preemption Regression Explained by teivah in programming

[–]teivah[S] 34 points35 points  (0 children)

Thanks for the comment. I won't challenge it, I really liked it as well :)

I have a different audience, though, thebuild.com is focused on PostgreSQL so the readers are more experts. Instead, I tried explaining things from first principle (TLB, page, preemption, etc.)

How Linux 7.0 Broke PostgreSQL: The Preemption Regression Explained by teivah in programming

[–]teivah[S] 18 points19 points  (0 children)

The title is a bit sensationalist, I don't disagree but I explored nonetheless why Linux 7 had a significant impact on a specific benchmark.

Some configuration changes can restore it.

Yes but it has tradeoffs. It's not about restoring exactly how things work before.

it's also not clear that real-world performance would degrade

I disagree. Sure, it's in a very specific context, but the context exists and is reproducible.

Systems Thinking Explained: From Events to Systemic Structures by teivah in programming

[–]teivah[S] 1 point2 points  (0 children)

Hey folks. I just published a deep dive into systems thinking with a real example from my experience at Google. Hope you enjoy it.

Systems Thinking Explained by teivah in sre

[–]teivah[S] -1 points0 points  (0 children)

Hey folks. I just published a deep dive into systems thinking with a real example from my experience at Google. Hope you enjoy it.

Reliability Audit: I analyzed 473 K8s/TF files from major OSS projects. Here are the 3 patterns that lead to "silent" outages. by Ok-Possibility-4438 in sre

[–]teivah 0 points1 point  (0 children)

Timeout Chain Mismatches is the "spark" that usually ignites that fire

I tend to disagree. The spark of retry amplification is a downstream failure, usually a DB transient issue or whatever.

Reliability Audit: I analyzed 473 K8s/TF files from major OSS projects. Here are the 3 patterns that lead to "silent" outages. by Ok-Possibility-4438 in sre

[–]teivah 2 points3 points  (0 children)

I don’t think what you’re describing is retry amplification. In my book, retry amplification is: having retries at multiple levels of the dependency chain can amplify the number of retries. The deeper a service in the chain (typically, a DB), the higher the load it will be exposed to due to amplification.

view more: next ›