Настраивать
- Убунту 20.04
- Делл PowerEdge R820
- [PERC H710] 2 виртуальных диска (загрузочный RAID-1, рабочий диск RAID-0)
- Все было хорошо 6 месяцев
- Даже не предыдущая, просто вдруг полный привод.
Подробности...
Эта машина используется для построения чиа (криптовалюты) — она работает уже несколько месяцев без проблем.
Я заметил, что процесс прорисовки завис (bladebit) — что довольно необычно, случается, может быть, раз в 2 месяца — поэтому я пошел, чтобы запустить его снова, и сразу же начал получать устройство заполнено виды ошибок.
я выстрелил быстро дф-ч чтобы увидеть, что происходит, и получил это:
Используемый размер файловой системы Доступно Использование % Установлено на
udev 252G 0 252G 0% /dev
tmpfs 51G 2.9M 51G 1%/запуск
/dev/sda2 549G 512G 8.7G 99%/
tmpfs 252G 4.0K 252G 1% /dev/shm
tmpfs 5.0M 0 5.0M 0% /выполнить/заблокировать
tmpfs 252G 0 252G 0% /sys/fs/cgroup
/dev/sda1 511M 5,3M 506M 2% /boot/efi
tmpfs 51G 0 51G 0% /выполнить/пользователь/1000
<...СНИП ...>
/dev/sda2 является загрузочным диском - на самом деле это виртуальный диск RAID-1 (2 диска), управляемый картой RAID H710 на сервере, но я не думаю, что это очень важно.
ОБЫЧНО этот диск заполнен на 3%, на нем установлен только загрузочный Ubuntu Server 20.04 и больше ничего.
Мне пришлось стереть файл tmp в корне и несколько других мусорных файлов, чтобы освободить место, достаточное для того, чтобы все снова заработало, но он почти заполнен.
Я следовал бесчисленным советам «найти самый большой файл на вашем сервере» отсюда и из Интернета, например. Вот этот, с командой sudo du -a / 2>/dev/null | сортировать -n -r | голова -n 20 возвращение:
$ sudo du -a / 2>/dev/null | сортировать -n -r | голова -n 20
[sudo] пароль для пользователя:
1010830919685 /
1010823681740 /мнт
<...СНИП...>
Итак, что-то огромное сидит внутри / по всей видимости? Простой лс ничего интересного там не показывает:
$ лс -лФа /
всего 84
drwxr-xr-x 20 root root 4096 12 января 17:45 ./
drwxr-xr-x 20 root root 4096 12 января 17:45 ../
lrwxrwxrwx 1 root root 7 авг 24 08:41 bin -> usr/bin/
drwxr-xr-x 4 root root 4096 6 января 06:22 загрузка/
drwxr-xr-x 2 root root 4096 28 сентября 14:04 cdrom/
drwxr-xr-x 21 root root 6920 5 января 16:05 dev/
drwxr-xr-x 105 root root 4096 5 января 01:54 и т. д./
drwxr-xr-x 3 root root 4096 28 сентября 14:18 домашняя/
lrwxrwxrwx 1 root root 7 авг 24 08:41 lib -> usr/lib/
lrwxrwxrwx 1 root root 9 авг 24 08:41 lib32 -> usr/lib32/
lrwxrwxrwx 1 root root 9 авг 24 08:41 lib64 -> usr/lib64/
lrwxrwxrwx 1 root root 10 авг 24 08:41 libx32 -> usr/libx32/
drwx------ 2 root root 16384 28 сент. 14:03 потерян+найден/
drwxr-xr-x 2 root root 4096 24 августа 08:42 медиа/
-rw-r--r-- 1 root root 6678 9 января 00:59 MegaSAS.log
drwxr-xr-x 64 root root 4096 5 января 01:48 мин/
drwxr-xr-x 3 root root 4096 30 ноября 18:14 opt/
dr-xr-xr-x 1356 root root 0 3 января 04:40 proc/
drwx------ 7 root root 4096 30 ноября 18:07 root/
drwxr-xr-x 34 root root 1100 12 января 08:04 запуск/
lrwxrwxrwx 1 root root 8 авг 24 08:41 sbin -> usr/sbin/
drwxr-xr-x 9 root root 4096 28 сентября 22:06 snap/
drwxr-xr-x 2 root root 4096 24 августа 08:42 srv/
dr-xr-xr-x 13 root root 0 3 января 04:40 sys/
drwxrwxrwt 13 root root 4096 12 января 17:15 tmp/
drwxr-xr-x 15 root root 4096 24 августа 08:46 usr/
drwxr-xr-x 13 root root 4096 24 августа 08:47 var/
С использованием судо нкду -х / (соединять) как ни странно ничего интересного не показывает:
2,4 ГиБ [##########] /usr
1,5 ГиБ [######] /var
732,5 МБ [## ] /домашний
202,8 МБ [ ] /загрузка
5,5 МБ [ ] /опция
5,4 МБ [ ] / и т. д.
1,9 МБ [ ] / корень
168,0 КиБ [ ] /tmp
<...СНИП...>
Где находятся эти ~ 510 ГБ используемого пространства?
Стрельба из судо lsof | grep удален чтобы увидеть, есть ли какой-то гигантский файл, дал мне это:
SystemD-J 1134 ROOT 36U REG 8,2 134217728 5246838 /var/log/journal/771d7f1addf64a7b930191976176149E/SYSTEM@AE2F8B2397C441F7A286D251444BE75F8B2397C441F7A286D251444BA75F8B2397C441F7A286D251444BA7F8B2397C441F7A286D251444B8F8B2397C441F7A286D251444F8B2397C4441F7A286D25144BA7
unattende 3932 root 3w REG 8,2 113 5246631 /var/log/unattended-upgrades/unattended-upgrades-shutdown.log.1 (удалено)
unattende 3932 3943 gmain root 3w REG 8,2 113 5246631 /var/log/unattended-upgrades/unattended-upgrades-shutdown.log.1 (удалено)
Итак, он держит файл журнала размером 134 МБ, но это все еще не объясняет, почему внезапно стало занято 510 ГБ диска.
Я также попробовал некоторые дополнительные поиски, например Вот этот, и не привело ни к чему полезному.
я в конце концов использовал мегакли чтобы проверить данные SMART с 2 дисков в массиве RAID-0, и у них 0 сообщений об ошибках, поэтому не похоже, что массив поврежден.
Любые идеи или дополнительные приемы копания, которые я мог бы попытаться выяснить, что поглощает это пространство?
ОБНОВЛЕНИЕ №1 - заметил я, когда печатал вершина что баф/кеш был почти точно такой же, как размер ГБ, которые потреблялись на корневом диске. Я знаю, что пространство не считается использовал, но я решил поторопиться:
sudo sh -c "/usr/bin/echo 3 > /proc/sys/vm/drop_caches"
который занял около 3 минут, но в конце концов вернулся - вершина теперь показывает баф/кеш как < 1k, НО дф-ч не показывает никаких изменений в использовании диска.
Я надеялся, что это какой-то таинственный кеш-файл на диске или что-то в этом роде.
