david_xia

Hey, didn't notice your comment when I posted mine. But I'm seeing similar behavior on GKE 1.15.12-gke.3: CPU throttling even when CPU usage < CPU limits. https://news.ycombinator.com/item?id=24351566

I work on a team that operates multitenant GKE clusters for other engineers at our company. Earlier this year I read this blog post [1] about a bug in the Linux kernel that unnecessarily throttles workloads due to a CFS bug. Kernel versions 4.19 and higher have been patched. I asked GCP support which GKE versions included this patch. They told me 1.15.9-gke.9. But my team at work is still getting reports of CPU throttling causing increased latencies on GKE workloads in these clusters.

This means

1. we're using a kernel that doesn't contain the patch. 2. the patch wasn't sufficient to prevent unnecessary CPU throttling 3. latency is caused by something other than CPU throttling

To rule out 1, I again checked that our GKE clusters (which are using nodes with Container Optimized OS [COS] VM images) are on a version that contains the CFS patch.

```

dxia@one-of-our-gke-nodes ~ $ uname -a Linux one-of-our-gke-nodes 4.19.112+ #1 SMP Sat Apr 4 06:26:23 PDT 2020 x86_64 Intel(R) Xeon(R) CPU @ 2.30GHz GenuineIntel GNU/Linux

```

Kernel version is 4.19.112+ which is a good sign. I also checked the COS VM image version.

gke-11512-gke3-cos-77-12371-227-0-v200605-pre

The cumulative diff for [COS release notes][2] for cos-stable-77-12371-227-0 show this lineage (see "Changelog (vs ..." in each entry).

cos-stable-77-12371-227-0 77-12371-208-0 77-12371-183-0 77-12371-175-0 77-12371-141-0 <- This one's notes say "Fixed CFS quota throttling issue."

Now looking into 2:

This dashboard [5]. Top graph shows an example Container's CPU limit, request, and usage. The bottom graph shows the number of seconds the Container was CPU throttled as measured by sampling the local kubelet's Prometheus metric for `container_cpu_cfs_throttled_seconds_total` over time. CPU usage data is collected from resource usage metrics for Containers from the [Kubernetes Metrics API][6] which is returns metrics from the [metrics-server][7].

The first graph shows usage is not close to the limit. So there shouldn't be any CPU throttling happening.

The first drop in the top graph was decreasing the CPU limit from 24 to match the CPU requests of 16. The decrease of CPU limit from 24 to 16 actually caused CPU throttling to increase. We removed CPU limits from the Container on 8/31 12:00 which decreased number of seconds of CPU throttling to zero. This makes me think the kernel patch wasn't sufficient to prevent unnecessary CPU throttling.

This K8s Github issue ["CFS quotas can lead to unnecessary throttling #67577"][8] is still open. The linked [kernel bug][9] has a comment saying it should be marked fixed. I'm not sure if there are still CPU throttling issues with CFS not tracked in issue #67577 though.

Because of the strong correlation in the graphs between removing CPU limits and CPU throttling, I'm assuming the kernel patch named "Fixed CFS quota throttling issue." in COS 77-12371-141-0 wasn't enough.

Questions

1. Anyone else using GKE run into this issue?

2. Does anyone have a link to the exact kernel patch that the COS entry "Fixed CFS quota throttling issue." contains? A Linux mailing list ticket or patch would be great so I can see if it's the same patch that various blog posts reference.

3. Anyone aware of any CPU throttling issues in the current COS version and kernel we're using? 77-12371-227-0 and 4.19.112+, respectively.

[1] https://medium.com/omio-engineering/cpu-limits-and-aggressiv...

[2] https://cloud.google.com/container-optimized-os/docs/release...

[5] https://share.getcloudapp.com/o0u8KoEn

[6] https://kubernetes.io/docs/tasks/debug-application-cluster/r...

[7] https://github.com/kubernetes/kubernetes/tree/master/cluster...

[8] https://github.com/kubernetes/kubernetes/issues/67577

[9] https://bugzilla.kernel.org/show_bug.cgi?id=198197

[COS]: https://cloud.google.com/container-optimized-os/docs

Thanks. It seems like these are specifically for web pages where you need to add a script tag to a page you control.

I was thinking very generally of just having the device specify an HTTP(S) proxy and having that remote server be able to inspect any HTTP(S) traffic whether its from a browser or native apps.

another one https://images.turbotax.intuit.com/tto/flash/state_import_an...

I think you are mistaking the dramatic flourishes of the essay for its true message. It's a well-written piece that has a twist ending (not entirely unexpected).

"Maybe we go out in order to fall short . . . because we want to learn how to be good at being people . . . and moreover, because we want to be people."

She's saying that addiction to people is not the same as addiction to cigarettes. This is a good kind of addiction because human beings are by nature social creatures and should interact with one another.

I would also like to see a detailed explanation of how they prepared the box to safely allow people to play (ie logins, permissions, etc). How to restrict privileges yet allow just enough to make it varied and fun.

First play with the webpage after entering the correct credentials. Then read through the PHP script that generates that page and understand what's going on behind it. Do you see any vulnerabilities in it?

Anyone have the text? There's some database error right now.

I think these socially sponsored ads are going to be money-making and also insidious if done right. It's a nuanced, strange mix of social content and advertising. They're trying to make all ads social or all their open graph actions into ads. If you play this out to its logical conclusion, that's kinda scary.

Imagine a world where a large chunk of your online interactions are actually being used as content/ads targeted at your friends.