Inode linux как почистить
Обновлено: 05.07.2024
Inode - это структура данных в которой хранится информация о файле или директории в файловой системе. В файловой системе Linux, например Ext4, у файла есть не только само его содержимое, например, тот текст, но и метаданные, такие как имя, дата создания, доступа, модификации и права. Вот эти метаданные и хранятся в Inode. У каждого файла есть своя уникальная Inode и именно здесь указано в каких блоках находятся данные файла.
Это довольно низкоуровневое понятие, но обычным пользователям приходится взаимодействовать с ним когда эти самые Inode заканчиваются. Возможно вы уже встречались с ошибкой когда место на диске ещё есть, но программа не может создать файл, потому что Inode закончились. В этой статье мы подробно разберемся что такое Inode, а также попытаемся выяснить как избежать связанных с ними проблем.
Что такое Inode в Linux?
Как я уже сказал выше, Inode или I-node или индексный дескриптор - это структура данных, в которой хранятся метаданные файла и перечислены блоки с данными файла. Но начать надо с файловой системы. Файловые системы Ext используют блоки для хранения данных. По умолчанию размер одного блока равен 4092 байта. В начале раздела расположен суперблок, в котором находятся метаданные всей файловой системы, а ним идут несколько зарезервированных блоков, а затем размещена таблица Inode и только после неё блоки с данными. Таким образом, все Inode размещены в начале раздела диска.
Директории - это тоже Inode типа директория, в которых вместо содержимого файла содержится список имён файлов и номера их Inode. Корневая папка в Ext4 имеет номер Inode - 2. Вы можете посмотреть информацию о ней с помощью утилиты debugfs. Утилите в параметрах надо передать диск, на котором расположена файловая система:
sudo debugfs /dev/nvme0n1p5
Затем выполните такую команду:
Здесь указано, что эта Inode имеет тип Directory, права 755. Её владелец и группа root, потому что идентификатор пользователя 0. Чуть ниже расположена информация про время создания, модификации и доступа. А в самом низу находятся блоки с данными этой Inode. Именно там хранится список файлов и папок директории. Вы можете посмотреть содержимое блока командой dump_block:
debugfs: block_dump 9238
Утилита выведет данные в HEX и ASCII формате, и в них будет видно имена папок. Но увидеть номера Inode здесь не получится без дополнительных программ. Проще всего их можно посмотреть с помощью команды ls:
Здесь в первом же столбике находится номер Inode для файла или папки. Для примера можно посмотреть ещё информацию про testfile с номером Inode 1128:
debugfs: stat <1128>
В разделе EXTENTS есть номер блока, в котором находятся данные файла. В данном случае это 6596316. В нём можно посмотреть содержимое файла:
debugfs: block_dump 6596316
Вот так это всё работает на уровне файловой системы. Посмотреть Inode идентификаторы файлов можно также с помощью команды ls. Для этого надо передать ей опцию -i:
Здесь они будут тоже в первой колонке. Обратите внимание, что у каждого файла, папки или символической ссылки уникальный номер Inode. Исключение составляют только жесткие ссылки. Количество Inode в файловой системе ограничено, оно определяется при инициализации файловой системы. Посмотреть текущее количество Inode можно командой tune2fs:
sudo tune2fs -l /dev/nvme0n1p5
Нужная информация находится в поле Inode count. Посмотреть Inode можно с помощью утилиты df передав ей опцию -i:
Как видите, на моём корневом разделе использовано 29% Inode, а блоков у меня уже использовано 95%. Но если бы у меня было очень много мелких файлов, то место бы ещё осталось, а доступные Inode закончились. Тогда бы возникла ошибка создания файла, даже несмотря на то, что место ещё есть. Чтобы избежать такой ситуации надо тщательно планировать как вы будете использовать файловую систему.
Вы не можете изменить количество Inode для существующей файловой системы, зато можете указать для новой с помощью опции -N. Например:
mkfs -t ext4 -N 3000000 /dev/nvme0n1p5
В данном случае будет создана файловая система с тремя миллионами индексов Inode. Ещё можно не указывать точное количество Inode, а указать количество байт в одной Inode, это может быть удобно, если вы знаете средний размер ваших файлов, которые будут хранится в файловой системе. Например:
mkfs -t ext4 -i 2K /dev/nvme0n1p5
В качестве альтернативы, можно использовать файловую систему Btrfs, в которой Inode не могут закончиться потому что они генерируются динамически по мере необходимости.
Выводы
В этой статье мы рассмотрели что такое Inode в Linux, а также что произойдёт если доступное количество Inodes закончатся. Будьте осторожны при создании файловой системы и думайте какие файлы в ней будут размещены и сколько их там будет чтобы избежать проблем с Inode.
Нет похожих записей
Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна.
Прежде чем что то делать, нужно убедиться что проблема с inodes.
Воспользуйтесь командой:
Значения IUsed, IFree, IUse% дадут вам понимание, в какой файловой системе (разделе) у вас проблема.
Потом нужно посмотреть, в какой папке больше всего вложенных элементов (файлов и папок), а потом вывести их списком, список отсортировать в возрастающем порядке, используйте вот такой конвейер:
mindepth 2 или 3 потому, что достаточно просмотреть/посчитать файлы в папках 2/3 уровней вложенности. tail -10 это значит будет показан топ 10 папок с наибольшим количеством элементов.
На самом деле, когда в системе все сделано правильно, то такой проблемы как недостаток inodes не возникает.
Как минимум это подтверждает мой опыт использования SCO UNIX 3.2v4.2 на промышленном предприятии, SCO Open Desktop 3, OpenServer 5 в банке для работы банковской системы, RedHat Linux, CentOS в разных "диспетчерских" (колл-центрах). Не было проблем с инодами.
количество файлов может быть больше чем количество inode, но обычно совпадает с большой точностью :)
ставь утилиту ncdu, удобная консольная вещица для прочистки диска от лишнего
в ней есть режим c - показ количество единиц содержимого каждого каталога со всеми подкаталогами.
смотри help.
мож перейти на фс с динамическим количеством inode ??
мож перейти на фс с динамическим количеством inode ??
XFS — высокопроизводительная 64-битная журналируемая файловая система, созданная компанией Silicon Graphics для собственной операционной системы IRIX. 1 мая 2001 года Silicon Graphics выпустила XFS под GNU General Public License. XFS отличается от других файловых систем тем, что она изначально была рассчитана для использования на дисках большого объёма (более 2 терабайт, см. например, RAID-массивы).
Поддержка XFS была включена в ядро Linux версий 2.4 (начиная с 2.4.25, когда Марчело Тозатти (Marcelo Tosatti) посчитал её достаточно стабильной) и 2.6, и, таким образом, она стала довольно универсальной для Linux-систем. Инсталляторы дистрибутивов openSUSE, Gentoo, Mandriva, Slackware, Ubuntu, Fedora и Debian предлагают XFS как вариант файловой системы для установки. FreeBSD стала поддерживать XFS в режиме чтения в декабре 2005 года, с июня 2006 была представлена экспериментальная поддержка записи. Несмотря на это, её предполагалось использовать только для облегчения миграции с Linux, но не основной файловой системы. Поддержка XFS была удалена в FreeBSD 10.[1]
Особенности
64-битная файловая система.
Журналирование только метаданных (если не задать иное параметрами).
Выделение места экстентами (Extent — указатель на начало и число последовательных блоков). В экстентах выделяется место для хранения файлов, а также экстентами хранятся свободные блоки.
B-tree индексы активно используются для хранения различных данных файловой системы: для списка блоков с inode-ами, списка экстентов с содержимым файла, каталогов файлов, списков экстентов свободных блоков (свободные блоки проиндексированы и по размеру блока, и по расположению). Однако использование b-tree индексов не догма — небольшой файл или каталог может быть размещен прямо внутри inode.
Отложенное выделение места (Delayed allocation). При записи файла для него выделяется место в памяти, а на диске выделяется место только при записи файла на диск. Таким образом под файл оптимально выделяется место на диске, что уменьшает фрагментацию.
Изменение размера «на лету» (только увеличение).
Размещение в нескольких линейных областях (по умолчанию — 4 шт.) т. н. «allocation groups» (увеличивает производительность путём выравнивания активности запросов как к разным дискам на RAID-массивах типа «stripe», так и при асинхронном обращении к файловой системе на обычном диске.)
Дефрагментация «на лету».
API ввода-вывода реального времени (для приложений жёсткого или мягкого реального времени, например, для работы с потоковым видео).
Интерфейс (DMAPI) для поддержки иерархического управления носителями (HSM).
Инструменты резервного копирования и восстановления (xfsdump и xfsrestore).
«Индексные блоки» inode выделяются динамически (по мере надобности) и неиспользуемые inode могут освобождаться (высвобождая место для хранения данных).
Малые «накладные расходы» — размер служебных структур данных. На вновь созданной файловой системе XFS на служебные нужды тратится порядка 0,54 %. Это достигается малым количеством заголовков для групп (allocation groups), а также за счет динамического выделения inode.
Невозможно уменьшить размер существующей файловой системы. Если раздел на диске занят XFS, его размер нельзя будет изменить в меньшую сторону (это важно принимать во внимание при разбивке диска).
Восстановление удалённых файлов в XFS — очень сложный процесс, поэтому на данный момент (2014 год) для этого существует всего лишь несколько программных продуктов, например «Raise Data Recovery for XFS» для ОС Windows.
Возможность потери данных во время записи при сбое питания, так как большое количество буферов данных хранится в памяти при том, что метаданные записываются в журнал (на диск) оперативно. Это характерно и для других файловых систем с журналированием метаданных.
Нередки случаи, когда причиной проблем на сервере становится переполнение файловых дескрипторов ( inode ). Симптомы точно такие же, как при переполнившемся диске, только вот диск при этом может оказаться свободным.
Количество inode каждой файловой системы определяется при разворачивании ОС. И для большинства серверов этого хватает с головой. Чаще всего во время установки ОС создаётся 1 inode на каждые 2 Кбайт пространства по умолчанию. Это много, но для некоторых — все равно недостаточно.
Если у вас закончились inode , вы не сможете создать новый файл. Ваша система или любая её служба также не сможет это сделать.
Первый шаг, который требуется в этом случае, проверить наличие свободных inode командой:
Отметим, что эта команда обычно применяется в паре с df -h , которую используют для проверки места на диске. Иначе говоря, проверяя место на диске, не забудьте проверить и файловые дескрипторы.
Вывод команды будет примерно таким:
Как и в случае с дисковым пространством, нас интересует строчка с dev -устройством, в которое файловая система помещает наши файлы. В примере это /dev/vda5 и процент использования inode 100%. Хотя мы видим, что 159 дескрипторов еще свободно, для корректной работы системы этого может быть мало уже сейчас или хватит совсем ненадолго.
Как возникла эта проблема? В какой-то директории создано большое количество файлов, т.е. условно говоря, у системы есть ограничение на создаваемые файлы, и это ограничение было превышено. Задача — найти эту директорию или директории. Нам поможет следующая команда:
Вывод будет примерно таким:
Здесь указывается директория и ниже — количество файлов в ней.
Наиболее распространенный случай, когда множество файлов создается в папке хранения сессий. В нашем примере это директория /var/www/user1/data/mod-tmp. Очистить ее можно командой:
Учтите, что процесс может быть долгим, так как удаление большого количества мелких файлов требует времени.
Для удаления этих файлов у PHP есть встроенный механизм сборщика мусора, который так и называется — garbage collector . И для сессий он отрабатывает по довольно простой схеме, работа которой задается переменными в настройках PHP.
Для всех файлов сессий, которые были созданы больше, чем « session.gc_maxlifetime » секунд назад (обычно это — 1440 секунд, 24 минуты) есть вероятность, что файл будет удален. Вероятность равна « session.gc_probability », разделенная на « session.gc_divisor ».
Делитель обычно задается стандартный, равный 1000, а вот параметр session.gc_probability — и есть ключевая переменная в вероятности срабатывания. И у вас она может быть выставлена в 0 , что будет означать, что PHP никогда не очищает старые сессии. Из-за чего у вас и может накопиться их несколько миллионов. Выставите параметр в 1 , сессии будут очищаться.
Далее видим, что и в почтовой очереди скопилось много файлов. Если проблему с переполнившимися айнодами уже решили, то лучше не очищать почтовую очередь и проанализировать ее с помощью нашей статьи. Если вопрос срочный, очищаем ее также как сессии PHP:
Мы рассмотрели наиболее встречаемые случаи и пути их решения. В отличие от дискового пространства, с айнодами частных случаев гораздо больше, но в одной статье обо всех рассказать невозможно. Если ваш случай не попал в статью, вы всегда можете обратиться в поддержку за помощью.
Linux старается оптимизировать использование памяти, занимая свободное место кэшем. Если память никак не используется, то это память, потраченная впустую.
Кэш заполняется данными по мере работы системы и когда приложениям требуется память, ядро ищет среди страниц кэша блок подходящего размера, освобождает его и выделяет приложению.
В некоторых случаях этот процесс может влиять на производительность, поскольку освобождение кэша занимает больше времени, чем просто доступ к неиспользуемой оперативной памяти. Поэтому иногда можно наблюдать снижение производительности.
Причина этого исключительно в том, что оперативная память используется на полную мощность, и других симптомов, кроме случайного эпизодического увеличения задержек, может и не быть. Такая же картина может наблюдаться, если жесткий диск не справляется с чтением и записью. Влияние может быть и на такие компоненты операционной системы как сетевая карта / iptables / ebtables / iproute2 — вместо реальной причины вы видите проблемы в сетевой задержке. В этой статье обсудим это подробнее и посмотрим, как минимизировать воздействие на систему.
Объяснение
В Linux есть несколько видов кэшей:
dirty cache — блоки данных, которые еще не записаны на диск (в файловых системах, поддерживающих кэширование, например, ext4). Этот кэш можно очистить командой sync. Очистка этого кэша может привести к снижению производительности. При обычном режиме работы не стоит этого делать, если только вам не нужно сбросить данные на жесткий диск, например, при аварии.
clean cache — блоки данных, которые для ускорения доступа находятся и на жестком диске и в памяти. Очистка clean cache может привести к снижению производительности, поскольку все данные будут считываться с диска.
inode cache — кэш информации о местоположении inode. Его можно очистить аналогично clean cache, но также с последующим снижением производительности.
slab cache — хранит объекты, выделенные приложениям с помощью malloc, таким образом, что в будущем они могут быть повторно выделены с уже заполненными данными объекта, что ускоряет выделение памяти.
С dirty cache мало что можно сделать, но другие типы кэшей можно очистить. Их очистка может привести к двум результатам. В приложениях, потребляющих много памяти, таких как Aerospike, задержки уменьшатся. Но с другой стороны, замедлится скорость ввода-вывода, так как все данные придется считывать с диска.
Очистка slab cache может привести к временному кратковременному снижению скорости. По этой причине очищать кэш не рекомендуется. Вместо этого, лучше сообщить системе, что определенный объем памяти всегда должен быть свободен и его нельзя занимать кэшем.
При необходимости очистку кэша можно выполнить следующим образом:
Большую часть памяти занимает page cache, поэтому если очищаете кэш, то рекомендуется очищать его (echo 1).
Для исправления проблемы можно установить минимальное количество свободной памяти. Рассмотрим следующий пример:
В этом примере свободно 10 ГБ памяти, ограниченной с использованием параметра minimum free . В случае, если потребуется выделить 5 ГБ памяти, то сделать это можно мгновенно. Для обеспечения 10 ГБ свободной памяти освобождается часть кэша. Выделение памяти будет происходить быстро, а кэш динамически уменьшаться, чтобы 10 ГБ всегда оставались свободными. Распределение памяти будет выглядеть следующим образом:
Точная настройка этих параметров зависит от вашей нагрузки. Для Aerospike, если это позволяет доступный объем памяти, должно быть не менее 1,1 ГБ свободной памяти в min_free_kbytes . Тогда кэш будет в достаточном объеме, оставляя место для размещения приложений.
Настройка выполняется следующим образом:
NUMBER - количество килобайт, которые должны быть свободны в системе.
Чтобы на компьютере со 100 ГБ оставить 3% памяти незанятыми, выполните следующую команду:
Aerospike рекомендует оставлять не менее 1,1 ГБ в min_free_kbytes , т.е. 1153434.
В системе с общим объемом памяти более 37 ГБ следует оставлять не более 3% свободной памяти min_free_kbytes , чтобы ядро не тратило слишком много времени на ненужное восстановление памяти. В таких системах это будет составлять от 1,1 ГБ до 3% от общего объема оперативной памяти.
При установке этого параметра следует проявлять осторожность: слишком маленькое или слишком большое значение может отрицательно сказаться на производительности системы. Слишком низкое значение min_free_kbytes не позволит системе освободить память. Что может привести к зависанию системы или уничтожению процессов через OOM.
Слишком большое значение (5-10% от общей памяти) приведет к тому, что в системе быстро закончится память. Linux для кэширования данных файловой системы использует всю доступную оперативную память. Установка высокого значения min_free_kbytes может привести к тому, что система будет тратить слишком много времени на восстановление памяти.
RedHat рекомендует поддерживать min_free_kbytes на уровне 1-3% от объема памяти в системе. При этом Aerospike рекомендует оставлять не менее 1,1 ГБ, даже если это выше официально рекомендуемого значения.
Также рекомендуется либо уменьшать параметр swappiness до нуля, либо не использовать своп. В любом случае для операций с низкой задержкой использование свопа резко снизит производительность.
Установите значение swappiness в 0 , чтобы уменьшить потенциальную задержку:
Примечания
ВАЖНО: Все изменения, указанные выше, НЕ сохраняются. Они действуют только во время работы машины. Чтобы изменения были постоянными, необходимо внести их в /etc/sysctl.conf .
Добавьте следующие строки:
Как всегда, будьте внимательны при редактировании подобных параметров. Проверьте их на тестовых серверах перед внесением изменений в продакшн-окружение.
Еще один параметр, аналогичный вышеуказанному, — zone_reclaim . К сожалению, этот параметр вызывает агрессивное восстановление и сканирование. Поэтому лучше его отключить. Во всех новых ядрах и дистрибутивах этот параметр по умолчанию выключен.
Для проверки, что zone_reclaim отключен используйте следующую команду:
Перевод материала подготовлен в рамках курса "Administrator Linux. Advanced".
Если вам интересно узнать о курсе подробнее, приглашаем на день открытых дверей онлайн, где преподаватель расскажет о формате обучения и программе.
РЕГИСТРАЦИЯ
Читайте также: