itsericwoodward-site-v2/src/sitePosts/journal/2018/09-18-syncthing-ionice.md

81 lines
3.8 KiB
Markdown

---
title: Making SyncThing Play (IO)Nice
date_pub: 2018-09-18T16:29:00-04:00
date_upd: 2018-12-01T12:21:00-05:00
tldr: My SyncThing instance was using too much CPU, and <a href='https://github.com/opsengine/cpulimit'>CPU Limit</a> didn't help reign it in, so I wound up using <a href='https://manpages.debian.org/testing/util-linux/ionice.1.en.html'>IO Nice</a>.
content_type: journal
tags: SyncThing Ubuntu
---
Every now and then, my laptop (running #Ubuntu 18.04) would freeze up: all the screens would lock, and although my mouse cursor was still on the screen, it was completely unable to interact with anything. After 30-40 seconds, everything would start moving again and return to normal.
The very first thing that I usually did when I get control of my system back was to run the `top` command, and what I frequently saw was [SyncThing](https://syncthing.net/), an open source application that I use for backups, pegging 100% or higher on my CPU usage:
<img src='/images/updates/syncthing.gif' alt='A screenshot showing SyncThing using too much CPU.' class='heroImage' />
Now, I knew that this wasn't supposed to happen, and until I could figure out what was triggering the sudden jump in utilization, I decided to try and limit SyncThing's consumption via some other way.
## Fix #1 - CPU Limit ##
First, I tried [CPU Limit](https://github.com/opsengine/cpulimit), a utility designed to put a hard limit on the CPU usage for a process, which I installed and used as outlined [here](https://inside-out.xyz/technology/limiting-to-50-of-a-cpu-core-for-syncthing.html):
```shell
# Install CPU Limit
> sudo apt install cpulimit
```
+ I edited the `syncthing.service` file to make my `ExecStart` directive look like this:
```shell
# Limit SyncThing to no more than 50% of the available processor
ExecStart=/usr/bin/cpulimit -v -l 50 /usr/bin/syncthing -- -no-browser -no-restart -logflags=0
```
+ Finally, I restarted the SyncThing service:
```shell
# Reload the service files
> systemctl daemon-reload
# or use `systemctl --user daemon-reload` for user-specific services
# Restart the SyncThing service
> systemctl restart syncthing.service
# or use `systemctl --user restart syncthing.service` for user-specific services
```
This worked for a while, but apparently broke after I updated SyncThing from v0.14.43 to v0.14.50 (the service file kept crashing out).
And that's when I switched to...
## Fix #2 - IO Nice ##
The [IO Nice](https://manpages.debian.org/testing/util-linux/ionice.1.en.html) utility (part of the `util-linux` package in Debian and Ubuntu) allows system users / admins to adjust the scheduling class for an application, which indicates when the process should run: in real-time, as a best-effort (but giving way real-time applications), or only when the system is otherwise idle.
```shell
# Install util-linux
> sudo apt install util-linux
```
+ again, I edited the `syncthing.service` file, but this time, I made my `ExecStart` directive look like this:
```shell
# We want syncthing to be run as a "best-effort" application
ExecStart=/usr/bin/ionice -c 2 /usr/bin/syncthing -no-browser -no-restart -logflags=0
```
+ Finally, I restarted the SyncThing service (aain):
```shell
# Reload the service files
> systemctl daemon-reload
# or use `systemctl --user daemon-reload` for user-specific services
# Restart the SyncThing service
> systemctl restart syncthing.service
# or use `systemctl --user restart syncthing.service` for user-specific services
```
It's been a little over a month since I made this change, and I haven't experienced a laptop freeze-up since. I did have a similar problem with SyncThing on the machine that I'm backing up to, and wound up implementing the IO Nice limit on that box, too (with the same result).
I'll update this post (again) if I run into any other issues with SyncThing.