Как проанализировать утечку памяти Minikube?

У меня локальный кластер с 2 PV

1 Для дампа mysql с 20 ГБ

1 Для Mongo db с объемом около 10 ГБ

Множество различных сервисов, в основном изображения размером около 400 МБ или меньше, и одно устаревшее изображение размером 2,1 ГБ.

Я использую Skaffold + Minikube + VirtualBox

Я получаю следующую ошибку от mysql:

2020-06-09T12:49:49.854701Z 0 [ERROR] InnoDB: Write to file ./ibtmp1failed at offset 0, 1048576 bytes should have been written, only 0 were written. Operating system error number 28. Check that your OS and file system support files of this size. Check also that the disk is not full or a disk quota exceeded.
2020-06-09T12:49:49.854724Z 0 [ERROR] InnoDB: Error number 28 means 'No space left on device'

Затем я начинаю смотреть на текущую системную память следующим образом:

minikube ssh "free -mh"

И я получаю следующее:

-------------total        used        free      shared  buff/cache   available
Mem:          7.8Gi       2.3Gi       2.4Gi       517Mi       3.1Gi       5.3Gi

Я запускаю следующую команду:

minikube ssh "df -h"

И я получаю следующее:

Filesystem      Size  Used Avail Use% Mounted on
tmpfs           7.1G  493M  6.6G   7% /
devtmpfs        3.9G     0  3.9G   0% /dev
tmpfs           3.9G     0  3.9G   0% /dev/shm
tmpfs           3.9G   26M  3.9G   1% /run
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
tmpfs           3.9G   12K  3.9G   1% /tmp
/dev/sda1        70G   69G     0 100% /mnt/sda1
/Users          234G  190G   44G  82% /Users

Я вижу, что /mnt/sda1 может быть основной проблемой, но я не могу отследить, как этот sda1 был заполнен. Как я могу увидеть содержимое / dev / sda1 и возможный виновный процесс, заполнивший это устройство?

Я также выполнил следующие команды:

docker image prune Удаление неиспользуемых изображений docker volume prune Удаление неиспользуемых томов

Я также запускаю skaffold, учитывая документацию с очисткой: skaffoold -f="file-skaffold-config" --no-prune=false --cache-artifacts=false

docker rmi -f [IMAGE_ID], чтобы удалить конкретное изображение по идентификатору и посмотреть, может ли удаление этого изображения в конечном итоге освободить место в / dev / sda1

Но я не вижу лучшей ситуации с моим sda1, а это означает, что minikube ssh "df -h" показывает точно такие же результаты, как и раньше.

Как с помощью minikube / skaffold / docker посмотреть, что заполняется /dev/sda1?


minikube skaffold
person juan garcia    schedule 09.06.2020    source источник
comment
Самый традиционный инструмент, который поможет вам выяснить, что на самом деле занимает пространство, - это команда linux du. Здесь вы можете увидеть несколько вариантов использования случаев, но обычно я запускаю sudo du -s /dev/sda1/*, это покажет размер каждого файла и папки внутри /dev/sda1, затем захожу в самую большую папку и снова запускаю sudo du -s /dev/sda1/example/* и так далее. Это может быть не элегантно, но всегда работает.   -  person Mark Watney    schedule 10.06.2020
comment
Конечно, это один из способов, это также помогло мне увидеть minikube ssh "sudo du -sh /mnt/sda1/*", что /data, который является моим pv, содержит 17 ГБ базы данных, а /var содержит 46 ГБ, где у меня в основном содержимое докера, космический радар немного застрял при попытке анализа, это хороший совет, спасибо.   -  person juan garcia    schedule 10.06.2020

Ответы (1)


arrow_upward
0
arrow_downward

После того, как вы спросите в репозитории github несколько советов о потреблении места в minikube:

https://github.com/kubernetes/minikube/issues/8422

На космический радар указали:

https://github.com/zz85/space-radar/tree/v5.1.0

Я смогу предоставить дополнительную информацию и убедиться, что вызывает это использование диска ... Существует высокая вероятность того, что проблема будет решена путем изменения чего-то в изображениях, которые я запускаю локально, обновлю этот ответ, как только я узнаю, что было случаться.

[ОБНОВИТЬ]

В конце концов, я смог поближе познакомиться с проблемой minikube от моего коллеги, оценив потребление диска моей машиной по отношению к его машине. Как отметил mWatney в комментариях, я сделал:

$ minikube ssh "sudo du -sh /mnt/sda1/*"
17G /mnt/sda1/data
4.0K    /mnt/sda1/hostpath-provisioner
4.0K    /mnt/sda1/hostpath_pv
16K /mnt/sda1/lost+found
46G /mnt/sda1/var

Но у моего коллеги было:

34G /mnt/sda1/data
4.0K    /mnt/sda1/hostpath-provisioner
4.0K    /mnt/sda1/hostpath_pv
16K /mnt/sda1/lost+found
36G /mnt/sda1/var

Это означает, что у него была проблема с постоянными томами, и после исправления на своей машине в прошлом у него по ошибке была резервная копия PV пути к хосту minikube, так что теперь он работает нормально.

person juan garcia    schedule 09.06.2020