Каталог/tmp: 0 файлов, но полные шоу?
Связанный с другим сообщением, где мне наконец удалось удалять файлы в/tmp благодаря другому плакату.
Однако в конце системный администратор должен был восстановить снимок несколько дней назад для возвращения mysql сервиса.
Я вывел mysql сервер, не работал, и это не было. Одна ошибка состояла в том, что это не могло записать в tmp dir для создания mysqld.sock/.pid файлов, таким образом, они не существовали.
Таким образом, сервер был перезапущен/перезагружен и наконец восстановлен от предыдущего снимка, таким образом, все теперь работает, но тот снимок был от несколько дней назад, таким образом, говорить - говорит, что знаки находятся в этом выводе:
drwxrwxrwt 2 root root 34471936 Oct 8 20:47 tmp
То большое количество все еще 'помнят' так или иначе, и я пытаюсь узнать то, что пишет в ту папку? В Drupal путь для файлов предварительного просмотра установлен к тому каталогу, но я просто сделал серию тестов (сайт не имеет никаких учетных записей входа в систему / справедливый для данных), загрузка, предварительно просматривая и т.д. и номер документа никогда не изменяли на/tmp папке поэтому, что пишет в ту папку?
Это - веб-сервер, который не получает закрытие / перезагруженный, если нет некоторая проблема. Несмотря на это,/tmp каталог не становится освобожденным после перезапуска. Кроме того, в rsC файле, TMPTIME=0 все еще в значении по умолчанию.
Так, я не уверен, где еще посмотреть или как исследовать то, что сохраняет это 3441936 размер, когда фактический каталог пуст? Или, как искать, какие процессы используют тот каталог.
Это только для установки Drupal. Ubuntu 12.
2 ответа
ext [234] не уменьшает размер каталогов при удалении файлов; он просто помечает записи как удаленные, чтобы их можно было использовать позже. Если вы действительно хотите освободить эти 34 МБ, вам потребуется удалить и заново создать каталог, или загрузиться в режиме восстановления и запустить e2fsck -D на томе.
Попробуйте это.
$ 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. :)