Каталог / tmp: 0 файлов, но показывает полный?

Связано с другим постом, где я наконец смог удалить файлы в / tmp благодаря другому постеру.

Однако, в конце концов, системный администратор должен был восстановить снимок, сделанный несколько дней назад, чтобы восстановить службу mysql.

Я пришел к выводу, что сервер mysql не работает и не работает. Одна ошибка заключалась в том, что он не мог записать в каталог tmp для создания файлов mysqld.sock / .pid, чтобы они не существовали.

Таким образом, сервер был перезапущен / перезагружен и, наконец, восстановлен из предыдущего снимка, так что все теперь работает, но этот снимок был сделан несколько дней назад, так что в этом выводе присутствуют сигнальные знаки:

drwxrwxrwt  2 root  root  34471936 Oct  8 20:47 tmp
[117 ] Это большое число все еще как-то «запоминается», и я пытаюсь выяснить, что пишет в эту папку? В Drupal путь к файлам предварительного просмотра установлен в этот каталог, но я только что провел серию тестов (на сайте нет учетных записей / только для данных) загрузка, предварительный просмотр и т. Д., И номер файла никогда не менялся в папке / tmp, так что пишет в эту папку?

Это веб-сервер, который не отключается / не перезагружается, если нет каких-либо проблем. Несмотря на это, каталог / tmp не очищается при перезапуске. Кроме того, в файле rsC значение TMPTIME=0 по-прежнему используется по умолчанию.

Итак, я не уверен, где еще искать или как исследовать, что сохраняет этот размер 3441936, когда фактический каталог пуст? Или как искать, какие процессы используют этот каталог.

Это только для установки Drupal. Ubuntu 12.

3
задан 16.04.2020, 06:48

1 ответ

Попробуйте это.

$ sudo lsof | egrep '^COMMAND|deleted'

Пример вывода, который я вижу в моей системе ...

COMMAND     PID        USER   FD      TYPE             DEVICE   SIZE/OFF       NODE NAME
mysqld     2842      mysql    5u      REG                9,1        4633    6209543 /tmp/ibLRNV1i (deleted)
mysqld     2842      mysql    6u      REG                9,1         424    6209545 /tmp/ibnnYl1y (deleted)
mysqld     2842      mysql    7u      REG                9,1           0    6209546 /tmp/ib5ViM0O (deleted)
mysqld     2842      mysql    8u      REG                9,1           0    6209547 /tmp/ibh9U55F (deleted)
mysqld     2842      mysql   13u      REG                9,1           0    6209548 /tmp/ibRzqtwm (deleted)
mysqld     2842      mysql  319u      REG                9,1    25894907    6209553 /tmp/MLFxqPDX (deleted)
mysqld     2842      mysql  350u      REG                9,1   267677827    6209550 /tmp/MLFBkHbP (deleted)

Общей характеристикой многих файловых систем * nix является тот факт, что ничто не мешает процессу продолжать чтение / запись в / из удаленного файла, и ничто не препятствует удалению файла, который процесс все еще имеет открыт.

Один из способов, которыми некоторые программы гарантируют, что временные файлы не задерживаются (и, возможно, также в качестве меры безопасности, хотя я не уверен, насколько это «безопасно»), - это открывать их и немедленно «отсоединять» (удалять). их. Если процесс неожиданно завершается, дисковое пространство освобождается. MySQL делает это:

MySQL организует удаление временных файлов в случае завершения mysqld. На платформах, которые его поддерживают (например, Unix), это делается путем отсоединения файла после его открытия. Недостатком этого является то, что имя не отображается в списках каталогов, и вы не видите большой временный файл, который заполняет файловую систему, в которой находится каталог временных файлов. (В таких случаях lsof + L1 может быть полезен при идентификации больших файлов, связанных с mysqld.)

& mdash; http://dev.mysql.com/doc/refman/5.6/ ru / временный-files.html

Важный момент: Когда файл, который все еще открыт, удаляется, пространство фактически не освобождается на диск до последнего процесса, держащего дескриптор файла, закрывает его. Пока файл не будет закрыт, никто, включая root, не сможет освободить это пространство, кроме как путем уничтожения процесса. И наоборот, уничтожение (или постепенное прекращение, если возможно) процесса должно всегда освобождать пространство.

Поэтому я бы порекомендовал вам взглянуть на то, что ваша система может иметь в плане открытия и удаления файлов, и это может дать вам кое-что для продолжения.

В моей системе в MySQL открыто несколько временных файлов, некоторые из них довольно большие.

Если вы хотите заглянуть в эти файлы, это легко сделать, хотя характер того, что вы сможете различить, сильно различается. Возьмите PID и цифры в FD, которые делают это ... пример, PID 2842 FD 350:

$ sudo strings /proc/2842/fd/350 | less

Если MySQL действительно удалил открытые временные файлы, остановка и перезапуск MySQL освободит это пространство, и затем вам нужно будет выяснить, что может удерживать тех, кто открыт, потому что они задерживаются дольше, чем нужно, и есть ли у вас запросы, которые генерируют чрезмерно большие временные таблицы и исчерпывают ваше пространство / tmp. Если ваш каталог / tmp является собственным разделом / файловой системой, то df -h даст вам лучший ответ относительно свободного и используемого пространства. Вам, вероятно, не нужно слишком беспокоиться о реальном размере самой записи каталога.

И, конечно, это может быть не MySQL. :)

6
ответ дан 16.04.2020, 06:49

Теги

Похожие вопросы