Что делать, если количество inode систем будет исчерпано через неделю

Стратегия реагирования на истощение inode

Ситуация, когда inode (индексные дескрипторы) файловой системы исчерпываются в течение недели, является критической, но управляемой проблемой. Inode — это структуры метаданных, отслеживающие файлы и каталоги в файловых системах типа ext4, XFS и других. Каждый файл, каталог, символьная ссылка требует как минимум одного inode. Когда inode заканчиваются, невозможно создать новые файлы, даже если на диске есть свободное место, что может парализовать работу приложений, баз данных или систем логирования.

Немедленные действия для диагностики

1. Проверить текущее использование inode: Используйте команды df -i или df -ih для просмотра использования inode по всем смонтированным файловым системам. Обратите внимание на столбцы IUse% и IFree.

   df -ih
   # Пример вывода:
   # Filesystem     Inodes IUsed IFree IUse% Mounted on
   # /dev/sda1       2.0M  1.9M   50K   98%   /
   

2. Определить источники потребления inode: Найдите каталоги с большим количеством мелких файлов. Используйте find или утилиты типа ncdu (с опцией --inodes).

   # Рекурсивный подсчёт inode по каталогам, сортировка по убыванию
   find /path/to/mount -type f -printf '%h\n' | sort | uniq -c | sort -rn | head -20
   

   # Альтернативно: использование ncdu для анализа
   ncdu --inodes /path/to/mount -x
   

Стратегии устранения проблемы

1. Очистка временных или ненужных файлов

• Логи приложений: Проверьте директории логирования (/var/log/). Настройте ротацию логов с помощью logrotate, удалите старые или архивированные логи.

  # Пример очистки старых логов Apache/Nginx
  find /var/log/apache2 -name "*.log.*" -type f -mtime +30 -delete
  

• Кеши и временные файлы: Очистите кеш пакетных менеджеров (/var/cache/apt/, ~/.cache/), временные файлы (/tmp/, /var/tmp/).
• Сессии пользователей или системные временные файлы: Например, файлы сессий PHP, временные файлы загрузок.

2. Управление файловыми дескрипторами и процессами

• Проверьте, не оставляют ли приложения "висячие" файлы. Используйте lsof для поиска удалённых файлов, которые ещё удерживаются процессами:

  lsof +L1 | grep '(deleted)'
  

3. Архивация и консолидация данных

• Если у вас много мелких файлов (например, изображения, конфигурации), рассмотрите их архивацию в tar или сжатие в один файл. Для логов используйте агрегацию в системы типа ELK Stack или Loki.

  # Архивация старых логов
  tar -czf old_logs_$(date +%Y%m%d).tar.gz /path/to/logs/*.log --remove-files
  

4. Увеличение количества inode (если возможно)

• Для некоторых файловых систем (например, ext4) количество inode задаётся при создании и не может быть изменено динамически. Однако можно:
  • Пересоздать файловую систему с увеличенным количеством inode: Используйте mkfs.ext4 -N <inode_count> при условии, что данные перенесены.
  • Рассмотреть использование файловых систем с динамическими inode: Например, XFS или Btrfs, которые выделяют inode по мере необходимости.

5. Мониторинг и автоматизация

• Настройте мониторинг использования inode (через Prometheus, Zabbix, облачные мониторы AWS CloudWatch/GCP Monitoring). Установите алерты при достижении 80-85% использования.
• Автоматизируйте очистку с помощью Cron-заданий или скриптов, например, ежедневное удаление временных файлов старше 7 дней.

Долгосрочные меры профилактики

1. Оптимизация архитектуры приложений:

   • Избегайте хранения миллионов мелких файлов в одной директории. Используйте хешированные поддиректории (например, для загрузок пользователей).
   • Рассмотрите хранение мелких объектов в объектных хранилищах (S3-совместимые) или базах данных типа MongoDB GridFS.

2. Выбор правильной файловой системы:

   • Для рабочих нагрузок с огромным количеством мелких файлов выбирайте XFS (динамические inode, лучшее масштабирование) или ZFS (с продвинутым кешированием).

3. Регулярные аудиты:

   • Внедрите регулярные проверки (раз в месяц) с помощью скриптов, анализирующих распределение файлов по размеру и типу.

Пример скрипта для экстренной очистки

#!/bin/bash
# Скрипт очистки временных файлов и старых логов

LOG_DIR="/var/log/myapp"
TEMP_DIR="/tmp/myapp_cache"
DAYS_TO_KEEP=7

# Очистка логов
find "$LOG_DIR" -name "*.log.*" -type f -mtime +$DAYS_TO_KEEP -delete
# Очистка временных файлов
find "$TEMP_DIR" -type f -mtime +$DAYS_TO_KEEP -delete
# Принудительный запуск logrotate
logrotate -f /etc/logrotate.d/myapp

# Проверка освободившихся inode
echo "После очистки:"
df -ih | grep -E "Filesystem|$LOG_DIR|$TEMP_DIR"

Заключение

Истощение inode — это сигнал о необходимости пересмотра политик хранения данных. Немедленно очистите временные файлы и логи, настройте мониторинг, а в долгосрочной перспективе оптимизируйте архитектуру хранения. Помните: свободное место на диске не означает свободные inode, поэтому включайте метрики inode в стандартные проверки здоровья системы.