Skip to main content

Posts

Force page reclaim in cgroups when their cache usage is higher than the specified threshold

Linux cgroup-aware out-of-memory (OOM) killer accounts RSS, kmem, and cache when calculating memory usage for a cgroup. A process that is running in a cgroup cannot directly control its cache usage. It is a good practice in Kubernetes to set a memory limit for containers. However, even if your program does not consume more than the limit, OOM killer can still kill your container if the total usage (RSS+cache) is bigger than the limit. To address this issue, I have created a simple tool called cgroup-memory-manager. You can run it as a separate process on a Kubernetes worker node, or as a DaemonSet in Kubernetes itself. This program periodically scans all the child cgroups of the specified parent cgroup and analyzes their memory consumption. When cgroup cache usage is higher than the specified threshold, it triggers a forced page reclaim for that cgroup, but not more than once in the specified time frame. https://github.com/linchpiner/cgroup-memory-manager
Recent posts

Rust is #20 in TIOBE Index for June 2020

Rust has been Stack Overflow’s most loved language for four years in a row, indicating that many of those who have had the opportunity to use Rust have fallen in love with it. Finally in June 2020 it is in Top 20 languages accordingly to TIOBE index. https://www.tiobe.com/tiobe-index/rust/

Kubegraph: Visualize Your Kubernetes Cluster

Kubegraph is a simple tool that allows visualizing Kubernetes resources (Pods, Deployments, Replica Sets, and so on) from the specified Kubernetes namespace in real-time. Kubegraph also allows you to store the events from a Kubernetes cluster in a file, so you can replay the events again without connecting to the cluster. And last but not least, you can use the saved events to generate a standalone HTML file, that allows you to replay the visualization in your browser without the cluster and Kubegraph itself. Examples: Example 1 Create Replication Controller and Deployment, scale the Deployment up and down, use the Deployment to roll out a new version, and, finally, delete both Replication Controller and Deployment. Example 2 Install Sock Shop application and then delete it. Example 3 Install Sock Shop application and keep it running. The project started as a proof of concept of a new monitoring system for Kubernetes, that works with a cluster through its public API

Gradle for DevOps, Part 4 - Dynamic Tasks

In the 4th part, we will learn how to create dynamic tasks in Gradle using project parameters. Also, we will discuss very useful features, such as task name abbreviation and task rules. Finally, we will implement a simple CLI, which is based on Gradle tasks and uses the same principles as Kubernetes CLI (kubectl). https://linchpiner.github.io/gradle-for-devops-4.html