Hypocrite Elon Musk has finally banned all Jet tracker accounts on Twitter, despite claiming that he supports freedom of expressions. Of course, the hypocrite only supports expression about things he agree with.
This is a cookbook style on how to set a limit (ulimit style) on your custom services that is managed by systemd.
Usecase
Why would you want to do something like this?
You might be running on a small server (or instance if you are using cloud services) and want to prevent your application from affecting other services sharing that server (think of noisy neighbor problem).
Generally, Linux kernel scheduler does a good job of fairly sharing system resources, but that is assuming you have a well behaved application.
Sometime you want to pack applications tightly and don’t mind less performant applications.
In summary, there are lots of reasons why you might want to tune the resources allocated to your applications.
Luckily, if you are using systemd as the controller (and if you are not, why not?), you can take advantage of its capabilities.
Note:
There are some caveats. You need to be using a fairly recent kernel and Linux distrob, either Ubuntu/Debian or recent CentOS/RedHat/Fedora.
What
I am going to show you how to get cloudquery run under systemd on an Ubuntu 20.04 LTS. The reason that I want to do this is because cloudquery will use as much memory as it can and trigger Linux OOM killer.
How
There are 3 files needed:
/etc/default/cloudquery
This file contains definition for CQ_SERVICE_ACCOUNT_KEY_JSON, the value of which is the json content of your service account key file.
[Unit] Description=Slice that limits memory for all my services
[Slice] # MemoryHigh works only in "unified" cgroups mode, NOT in "hybrid" mode # Must add 'systemd.unified_cgroup_hierarchy=1' to GRUB_CMDLINE_LINUX_DEFAULT # in /etc/default/grub MemoryHigh=10240M # MemoryMax works in "hybrid" cgroups mode, too MemoryMax=10240M
Once you have all 3 files in place and edited the values to match your particular system, you need to tell systemd to check its directory for the new service, by running
systemctl daemon-reload
Once you have done that, you can check to see if systemd see your new service, by running
systemctl list-unit-files|grep query
Smoke Test
Test to see if everything works by starting your service.
systemctl start cloudquery
Check (and debug) the status of your new service via
It will be useful to both those wanting to enter the SRE field or learn more it. I think it is also a nice way to round out the fuzzy areas for practicing SREs. What I mean is that we all have areas we are domain experts in, and areas we can get by, but not comfortable with.
The following section is lifted verbatim from LinkedIn.
There is a vast amount of resources scattered throughout the web on what the roles and responsibilities of SREs are, how to monitor site health, production incidents, define SLO/SLI etc. But there are very few resources out there guiding someone on the basic skill sets one has to acquire as a beginner. Because of the lack of these resources, we felt that individuals have a tough time getting into open positions in the industry. We created the School Of SRE as a starting point for anyone wanting to build their career as an SRE.
In this course, we are focusing on building strong foundational skills. The course is structured in a way to provide more real life examples and how learning each of these topics can play an important role in day to day SRE life. Currently we are covering the following topics under the School Of SRE:
You must be logged in to post a comment.