2011-02-13 1 views
2

Я запускаю ядро ​​Linux 2.6.36, и я вижу некоторые случайные ошибки. Такие вещи, какVFS: максимальный размер файла 1231582 достиг

ls: error while loading shared libraries: libpthread.so.0: cannot open shared object file: Error 23 

Да, моя система не может последовательно запускать команду «ls». :(

Я отмечаю несколько ошибок в моей dmesg вывод:

# dmesg | tail 
[2808967.543203] EXT4-fs (sda3): re-mounted. Opts: (null) 
[2837776.220605] xv[14450] general protection ip:7f20c20c6ac6 sp:7fff3641b368 error:0 in libpng14.so.14.4.0[7f20c20a9000+29000] 
[4931344.685302] EXT4-fs (md16): re-mounted. Opts: (null) 
[4982666.631444] VFS: file-max limit 1231582 reached 
[4982666.764240] VFS: file-max limit 1231582 reached 
[4982767.360574] VFS: file-max limit 1231582 reached 
[4982901.904628] VFS: file-max limit 1231582 reached 
[4982964.930556] VFS: file-max limit 1231582 reached 
[4982966.352170] VFS: file-max limit 1231582 reached 
[4982966.649195] top[31095]: segfault at 14 ip 00007fd6ace42700 sp 00007fff20746530 error 6 in libproc-3.2.8.so[7fd6ace3b000+e000] 

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

# cat /proc/sys/fs/file-max 
1231582 
# cat /proc/sys/fs/file-nr 
1231712 0  1231582 

Это также выглядит немного. мне показалось, что я не знаю, есть ли у меня 1,2 миллиона файлов в этой системе. Я использую его только один, и он не доступен никому за пределами локальной сети.

# lsof | wc 
    16046 148253 1882901 
# ps -ef | wc 
    574 6104 44260 

Я видел некоторые документы, говоря:

файл-макс & файл-Nr:

Ядро выделяет файловые дескрипторы динамически, но пока это не освобождает их снова.

Значение в файле-max означает максимальное количество файловых дескрипторов, которые выделяет ядро ​​Linux. Когда вы получите много сообщений об ошибках об окончании работы с файлами, вы можете увеличить этот предел.

Исторически три значения в файле-nr обозначали количество выделенных дескрипторов файлов, количество выделенных, но неиспользуемых файлов, а также максимальное количество дескрипторов файлов. Linux 2.6 всегда сообщает 0 как количество бесплатных дескрипторов файлов - это не ошибка, это просто означает, что количество выделенных дескрипторов файлов точно совпадает с количеством используемых дескрипторов файлов.

Попытка выделить больше дескрипторов файлов, чем файл-макс, передается с помощью printk, ищите «Достигнутый VFS: максимальный размер файла».

Мое первое чтение этого заключается в том, что ядро ​​в основном имеет встроенную утечку дескриптора файла, но мне очень трудно поверить. Это означало бы, что любая система в активном использовании должна быть перезагружена так часто, чтобы освободить дескрипторы файлов. Как я уже сказал, я не могу поверить, что это было бы правдой, так как для меня нормально, что Linux-системы остаются в течение нескольких месяцев (даже лет). С другой стороны, я также не могу поверить, что моя почти бездействующая система держит более миллиона открытых файлов.

Есть ли у кого-нибудь идеи для исправления или дальнейшего диагноза? Я мог бы, конечно, просто перезагрузить систему, но я не хочу, чтобы это повторяющаяся проблема каждые несколько недель. Как мера остановки, я ушел из Firefox, на который приходилось почти 2000 строк вывода lsof (!), Хотя у меня было только одно окно, и теперь я могу снова запустить «ls», но я сомневаюсь, что это исправит проблема надолго. (отредактируйте: К сожалению, заговорили слишком рано. К тому моменту, когда я закончил набирать этот вопрос, симптом был/вернулся)

Заранее благодарим за любую помощь.

+0

Лучшее сообщение об ошибке сервера – rene

+0

Хм, я не знал об этом. Спасибо за указатель, я отправлю туда вместо этого. –

+0

Эта документация не кажется точным, [linux/fs/file_table.c] (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob; f = fs/file_table.c; hb = HEAD) и выделяет и освобождает дескрипторы файлов. Звучит, как будто у вас есть утечка где-то, и я не уверен, как лучше всего отслеживать его. – ephemient

ответ

4

Ненавижу оставлять открытым вопрос, поэтому резюме для тех, кто это находит.

Я кончался перепроведением вопроса о ServerFault вместо (this article)

Они не смогли придумать ничего, на самом деле, но я сделал еще несколько расследованием и в конце концов нашел, что это настоящая ошибка с NFSv4, в частности, код блокировки на стороне сервера. У меня был клиент NFS, который запускал сценарий мониторинга каждые 5 секунд, используя rrdtool для регистрации некоторых данных в файле, установленном в NFS. Каждый раз, когда он запускался, он блокировал файл для записи, а сервер выделял (но ошибочно никогда не выпускал) открытый файловый дескриптор. Этот скрипт (плюс другой, который работает менее часто) привел к тому, что около 900 открытых файлов потреблялось в час, а два месяца спустя он достиг предела.

Возможны несколько вариантов решения: 1) Вместо этого используйте NFSv3. 2) Прекратите выполнение сценария мониторинга. 3) Храните результаты мониторинга локально, а не на NFS. 4) Дождитесь исправления NFSv4, который исправил это (Bruce Fields на самом деле отправил мне патч, но я не успел)

Я уверен, что вы можете думать о других возможных решениях.

Благодарим за попытку.

+0

5) Используйте другой сервер NFS, возможно [NFS-Ganesha] (http://nfs-ganesha.sourceforge.net/) или тестовый сервер в [pynfs] (http: // freshmeat.net/projects/pynfs/). – ephemient

+0

Можете ли вы подробно рассказать, как вы устранили эту проблему? Как вы обнаружили «виноватый» процесс? – maximi