Skip to content

Commit 4e7c3ee

Browse files
authored
docs: troubleshoot high memory usage (overhangio#810)
On some OS, high ulimit causes some container to use a lot of memory. We do not attempt to resolve this issue in Tutor because this is a mysql/uwsgi issue. Instead, we explain how to resolve it in the troubleshooting docs. Close overhangio#671.
1 parent bfabdfc commit 4e7c3ee

File tree

1 file changed

+31
-3
lines changed

1 file changed

+31
-3
lines changed

docs/troubleshooting.rst

Lines changed: 31 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -84,13 +84,13 @@ The most common reason this happens is that you are running two different instan
8484
tutor dev stop
8585
tutor local stop
8686
tutor k8s stop
87-
87+
8888
And then run your command(s) again, ensuring you're consistently using the correct Tutor variant (``tutor dev``, ``tutor local``, or ``tutor k8s``).
8989

9090
If that doesn't work, then check if you have any other Docker containers running that may using port 3306::
9191

9292
docker ps -a
93-
93+
9494
For example, if you have ever used `Tutor Nightly <https://docs.tutor.overhang.io/tutorials/nightly.html>`_, check whether you still have ``tutor_nightly_`` containers running. Conversely, if you're trying to run Tutor Nightly now, check whether you have non-Nightly ``tutor_`` containers running. If so, switch to that other version of Tutor, run ``tutor (dev|local|k8s) stop``, and then switch back to your preferred version of Tutor.
9595

9696
Alternatively, if there are any other non-Tutor containers using port 3306, then stop and remove them::
@@ -101,7 +101,7 @@ Alternatively, if there are any other non-Tutor containers using port 3306, then
101101
Finally, if you've ensured that containers or other programs are making use of port 3306, check the logs of the MySQL container itself::
102102

103103
tutor (dev|local|k8s) logs mysql
104-
104+
105105
Check whether the MySQL container is crashing upon startup, and if so, what is causing it to crash.
106106

107107

@@ -112,6 +112,34 @@ You can identify which containers are consuming most resources by running::
112112

113113
docker stats
114114

115+
In idle mode, the "mysql" container should use ~200MB memory; ~200-300MB for the the "lms" and "cms" containers.
116+
117+
On some operating systems, such as RedHat, Arch Linux or Fedora, a very high limit of the number of open files (``nofile``) per container may cause the "mysql", "lms" and "cms" containers to use a lot of memory: up to 8-16GB. To check whether you might impacted, run::
118+
119+
cat /proc/$(pgrep dockerd)/limits | grep "Max open files"
120+
121+
If the output is 1073741816 or higher, then it is likely that you are affected by `this mysql issue <https://github.com/docker-library/mysql/issues/579>`__. To learn more about the root cause, read `this containerd issue comment <https://github.com/containerd/containerd/pull/7566#issuecomment-1285417325>`__. Basically, the OS is hard-coding a very high limit for the allowed number of open files, and this is causing some containers to fail. To resolve the problem, you should configure the Docker daemon to enforce a lower value, as described `here <https://github.com/docker-library/mysql/issues/579#issuecomment-1432576518>`__. Edit ``/etc/docker/daemon.json`` and add the following contents::
122+
123+
{
124+
"default-ulimits": {
125+
"nofile": {
126+
"Name": "nofile",
127+
"Hard": 1048576,
128+
"Soft": 1048576
129+
}
130+
}
131+
}
132+
133+
Check your configuration is valid with::
134+
135+
dockerd --validate
136+
137+
Then restart the Docker service::
138+
139+
sudo systemctl restart docker.service
140+
141+
Launch your Open edX platform again with ``tutor local launch``. You should observe normal memory usage.
142+
115143
"Build failed running pavelib.servers.lms: Subprocess return code: 1"
116144
-----------------------------------------------------------------------
117145

0 commit comments

Comments
 (0)