LINUX.ORG.RU
ФорумAdmin

Inodes закончились, но файлов нет

 , ,


1

4

Здравствуйте.

Имеется VPS на Xen с Debian и ext4. Некоторое время назад закончились inodes и все не могу найти причину. Из софта - обычный LAMP с ISP Manager 4. Вся проблема в том, что это не тонна сессий PHP и количество файлов в разумных пределах. Так же не проблема в дескрипторах и сервер способен перезагружаться.

Как победить проблему? Вот некоторые листинги:

Filesystem      Inodes   IUsed IFree IUse% Mounted on
rootfs         3932160 3932160     0  100% /
udev             59227     262 58965    1% /dev
tmpfs            63251     215 63036    1% /run
/dev/xvda      3932160 3932160     0  100% /
tmpfs            63251       2 63249    1% /run/lock
tmpfs            63251       2 63249    1% /run/shm
Filesystem     Type     1K-blocks     Used Available Use% Mounted on
rootfs         rootfs    61927420 37390672  21391020  64% /
udev           devtmpfs     10240        0     10240   0% /dev
tmpfs          tmpfs        50604      120     50484   1% /run
/dev/xvda      ext4      61927420 37390672  21391020  64% /
tmpfs          tmpfs         5120        0      5120   0% /run/lock
tmpfs          tmpfs       101200        0    101200   0% /run/shm
/# find . | wc -l
78898
/# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=59227,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=50604k,mode=755)
/dev/xvda on / type ext4 (rw,relatime,errors=remount-ro,user_xattr,barrier=1,data=ordered,usrquota,grpquota)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=101200k)

″e2fsck -f″ запускали?

Смонтируйте /dev/xvda куда-нибудь в /mnt и тогда можно будет видеть, что в каталогах /dev/, /proc/, /run/ и т.д.

mky ★★★★★ ()

Может это не айноды кончились, а едро их неправильно считает? А если систему запустить с другим ядром, то каков результат?

jia ()
Ответ на: комментарий от mky

Не запускал. По идее то все надо делать, запускаясь из другой системы?

Вся проблема в том, что нельзя же отмонтировать корневой раздел на рабочей системе. Да и система относительно рабочая: при загрузке виснет на проверке квот (техподдержка хостера отключила их проверку), так же система виснет при попытке telinit 1.

Mart ()
Ответ на: комментарий от jia

Негде ядро взять, записывать новые файлы нельзя (из-за этого не все ПО то работает). И опять же из доступа SSH и VNC (и то получается подключиться к середине загрузки ядра. GRUB, подключения live cd мне не видать походу. да и меня смущает, что fdisk говорит, что на устройстве нет таблицы разделов... интересно как-то виртуализировано видать).

Честно говоря, уже есть идеи просто поставить чистую Jessie (стоит Wheezy). Опыта мало, доступа нет, но сутки я уже убил на рыскание проблемы по факту из интереса (до последнего не хочется применять метод сноса без разбора полетов). А на счет неправильного подсчета: неужели дебиан не настолько надежен, чтобы такое допускать?

Mart ()
Ответ на: комментарий от Mart

А на счет неправильного подсчета:
неужели дебиан не настолько надежен,
чтобы такое допускать?

Mart errare humanum est! Люди же, не машины код пишут!

Кстати, может дело в железе? Может обратиться к провайдеру, чтобы он свои железки проверил?

jia ()
Ответ на: комментарий от Mart

Для запуска fsck нужно просто, чтобы система была в ro. Для этого нужно завершить процессы, которые держат там открытые для записи файлы. bash и sshd вполне выживают и не мешают перемонировать ФС в ro. Просто после fsck, если он там что-то поправил, нужна будет перезагрузка, чтобы ядро считала все данные с диска.

Но при некоторой сноровке вобще можно скопировать всё нужно на tmpfs и переключить туда корень, тогда /dev/ можно вобще отмонтировать.

что fdisk говорит, что на устройстве нет таблицы разделов.

/dev/xvda

Как и так понятно. Если циферки в конце нет, то и разделов нет. И не нужны внутри вируталки разделы. И вобще, зачем вам понадобилось запускать fdisk на работающей системе?

mky ★★★★★ ()
Ответ на: комментарий от mky

Для запуска fsck нужно просто, чтобы система была в ro. Для этого нужно завершить процессы, которые держат там открытые для записи файлы. bash и sshd вполне выживают и не мешают перемонировать ФС в ro.

С этим проще, я вчера уже убивал процессы до миниума. Но отмонтировать/перейти в однопользовательский режим не выходило. Попробую просто в ro перемонтировать, хотя утилита ругалась и хотела отмонтирования.

Если циферки в конце нет, то и разделов нет. И не нужны внутри вируталки разделы

Так то да. Просто Xen - это не OpenVZ, полноценная виртуальная машина, а не контейнеризация в виде нескольких ФС под общим патченным ядром.

И вобще, зачем вам понадобилось запускать fdisk на работающей системе?

Другого выхода нет, я не уверен, что мне захотят подключить livecd. Но попробовать можно. Хостинг неплохой, но саппорт за бесплатно не админит (но и стоит он дешевле. на более дорогом даже помогали с администрированием).

Mart ()
Ответ на: комментарий от mky

Так-с, немного продвинулся. Через echo u > /proc/sysrq-trigger перемонтировал все ФС в ro. Запустил e2fsck, выдало:

e2fsck -f /dev/xvda
e2fsck 1.42.5 (29-Jul-2012)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/xvda: 3932160/3932160 files (0.0% non-contiguous), 9562343/15728640 blocks

Из этого можно делать вывод, что надо рыть что в xvda лежит?

Mart ()
Ответ на: комментарий от Mart

Вся проблема в том, что нельзя же отмонтировать корневой раздел на рабочей системе.

Вас никто не заставляет отмонтировать.
Смонтируйте ещё раз.

ArcFi ()
Ответ на: комментарий от Mart

Вы пробовали сделать вот это:

Смонтируйте /dev/xvda куда-нибудь в /mnt и тогда можно будет видеть, что в каталогах /dev/, /proc/, /run/ и т.д.

?

ArcFi ()
Ответ на: комментарий от Mart

Да. Монтируйте /dev/xvda куда-нибудь и ищите в этой точке монтирования.

mky ★★★★★ ()
Ответ на: комментарий от ArcFi

Блин, до меня только дошло, что корень можно не трогать (но вот сноровки для построения своего корня в tmpfs - нема), а просто примонтировать куда-то (в ro спокойно перевел). Примонтировал (инодов нет, так что /mnt/, он все-равно пуст):

/# mount /dev/xvda /mnt/ -o ro
/# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=59227,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=50604k,mode=755)
/dev/xvda on / type ext4 (ro,relatime,errors=remount-ro,user_xattr,barrier=1,data=ordered,usrquota,grpquota)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=101200k)
/dev/xvda on /mnt type ext4 (ro,relatime,errors=remount-ro,user_xattr,barrier=1,data=ordered,usrquota,grpquota)
/# cd mnt
/mnt# find . -xdev -type f | cut -d "/" -f 2 | sort | uniq -c | sort -n
      1 srv
      1 v
      2 _old
      3 run
      7 boot
      7 root
     95 sbin
    733 etc
   3279 lib
   8149 var
  27616 usr

Пока не вижу интересного, у сервера 70к файлов. Кстати, есть проблема с проверкой квот при загрузке (он виснет на ней). Сейчас просто в /etc/init.d/quota прописано check=/sbin/NOquotacheck. Может еще здесь собака зарыта?

Mart ()
Ответ на: комментарий от Mart

чем это интересно?

udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=59227,mode=755)

val-amart ★★★★★ ()

пара вопросов:

какая версия ядра?

что происходит если удалить файл на корневой фс? появится ли один свободный айнод или что-то его сразу займет? для теста удалить можно например что-то в /usr/share/doc, только проверте что в выводе `stat $filename` в поле links единица (это кол-во хардлинков, айнод очистится только при удалении последнего хардлинка). еще проверте что ни один процесс не держит этот файл открытым (`lsof $filename`).

ребутался ли сервер? можете ли вы ребутнуть его для проверки?

что показывает `lsof | grep -c deleted`?

val-amart ★★★★★ ()
Ответ на: комментарий от val-amart

«lsof | grep -c deleted» 60 лямов открытых файлов ?

да у него рожа треснет :)

да и на 3 лимона файлов ( это порядка 700 процессов по 4к файлов) было бы заметно.

кроме файлов, ноды занимают символ-линки, сокеты, каталоги.

vel ★★★★★ ()
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от val-amart

Да, самое важное забыл:

# uname -a
Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2 x86_64 GNU/Linux

У меня после остановки процессов как-то появилось 5 свободных Inode, но быстро ушли они тоже. Сервер до этого не раз перезагружался и он довольно долго уже живет с занятыми Inodes (может месяц до момента обнаружения проблемы).

что показывает `lsof | grep -c deleted`?

Удаленное/открытое и т.д. я проверял. На эту команду ответ - ноль.

Mart ()
Ответ на: комментарий от vel

60 лямов открытых файлов ?

перебираю варианты.

кроме файлов, ноды занимают символ-линки, сокеты, каталоги.

да ну, что ты? если уж умничаешь, то давай до конца: символические ссылки это не файлы? или сокеты?

энивей. какие у тебя предложения по сути проблемы?

val-amart ★★★★★ ()
Ответ на: комментарий от Mart

Попробуйте вот так:

mount -o ro /dev/xvda /mnt
find /mnt -xdev | cut -d / -f 2 | sort | uniq -c | sort -n

ArcFi ()
Ответ на: комментарий от val-amart

Так их тоже можно посчитать аналогично файлам. Временными могут быть не только файлы но и каталоги.

for i in f d l s; do find . -xdev -type $i | cut -d "/" -f 2 | sort | uniq -c | awk '{A+=$1} END{print A}'; done

ФС с 3000k нодами это легко, а вот с 37М нодами - это более интересно.

То, что на домашней системе оказалось 18к с-линков из 300к файлов меня немного удивило.

vel ★★★★★ ()
Последнее исправление: vel (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.