Bug 10154

Действительно воспроизводится на
[root@test vz]# uname -a
Linux test.localdomain 2.6.16-ovz-smp-alt7 #1 SMP Thu Sep 28 12:55:15 MSD 2006 
i686 GNU/Linux
[root@test vz]# rpmquery -a | grep vz
vzctl-3.0.11-alt2
kernel-image-ovz-smp-2.6.16-alt7
vzquota-3.0.8-alt1
[root@test vz]# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Pentium(R) 4 CPU 2.40GHz
stepping        : 7
cpu MHz         : 2394.219
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
bogomips        : 4796.94
[root@test vz]# free
       total       used       free     shared    buffers     cached
Mem:        247464     242700       4764          0      25752      50872
-/+ buffers/cache:     166076      81388
Swap:       248968     101236     147732
[root@test vz]# uptime
 16:13:40 up 20 days,  1:25,  1 user,  load average: 0.10, 0.12, 0.09

Имеем следующую картину
[root@test vz]# head -n 25 /proc/user_beancounters | egrep '(kmemsize|
numfile)'
         0: kmemsize      563042756  563942030 2147483647 2147483647          
0
            numfile         2735509    2735509 2147483647 2147483647          
0

Счетчики на HN только увеличиваются...

В alt4 всё работает, на alt7 подтверждаю такое поведение.

Reassigned to maintainer.

Похоже что alt4, будучи пересобранным в среде текущего Сизифа, начинает вести
себя так же как и alt7.

Вопроизводится с 026test020. Похоже, это бага все-таки в ovz патче. Думаю, багу
следует перевесить в bugzilla.openvz.org.

Если все-таки подождать чуть подольше, счетчик иногда уменьшается. Надо будет
промониторить его-чем нить.

Да, счётчик со временем немного уменьшается, но запаздывание этого уменьшения
таково, что регулярное открытие/закрытие файлов приводит к неудержимому росту
счётчика.

Между прочим, похожее запаздывание уменьшения счётчика заметно и в VE, легко
воспроизводится при использовании hasher внутри VE при относительно небольшом
значении лимита numfile (например, 4096).  Но в случае с VE запаздывание
уменьшения счётчика всё же значительно меньше чем в HN.

(In reply to comment #4)
> Похоже что alt4, будучи пересобранным в среде текущего Сизифа, начинает вести
> себя так же как и alt7.
Это давно известная багофича нашей системы сборки ядер - если собирается старое
ядро, но при этом доступен репозиторий, где лежат более свежие пакеты с патчами,
будут использованы именно новые версии патчей. Нужно либо цеплять старый
репозиторий, либо собирать пакеты скриптами из kernel cvs (без использования
hasher).

(In reply to comment #7)
> Да, счётчик со временем немного уменьшается, но запаздывание этого уменьшения
> таково, что регулярное открытие/закрытие файлов приводит к неудержимому росту
> счётчика.

На самом деле с последней версией патча openvz (ну или хотя бы с
2.6.16-026test019) рост в конце концов должен прекратиться:

http://git.openvz.org/?p=linux-2.6.16-openvz;a=commitdiff;h=4165f1fa371b60cb3a225910faebde95650a1f65

Вообще данная проблема вызвана не совсем правильно работающей оптимизацией
ограничения на количество открытых файлов. Чтобы при каждом открытии и закрытии
файла не модифицировать счётчик в beancounter (и не захватывать при этом
spinlock), в ub_file_charge() и ub_file_uncharge() реализован механизм
precharge: при необходимости открытия новых файлов в ub_file_precharge()
запрашивается более одного дескриптора, при этом неиспользованные дескрипторы
учитываются в current->task_bc.file_precharged; ub_file_uncharge() по
возможности старается возвращать дескрипторы именно в file_precharged, а не в
beancounter. Этот механизм работал нормально в ядре 2.6.9, где при закрытии
файла вызов ub_file_uncharge() чаще всего происходил в контексте процесса,
вызвавшего close(). Однако в ядре 2.6.16 для struct file используется отложенное
освобождение через RCU, в результате вызов ub_file_uncharge() из file_free_rcu()
может происходить в контексте совершенно другого процесса, в результате счётчик
->task_bc.file_precharged может увеличиваться для тех процессов, которым это
совершенно не нужно (в частности, я подозреваю, что эти файлы может получить
даже idle task). Эти файлы будут "потеряны" с точки зрения numfile до тех пор,
пока в ub_file_uncharge() не перестанут выполняться оба условия:

                if (ub_barrier_farnr(pub, UB_NUMFILE) &&
                                ub_barrier_farsz(pub, UB_KMEMSIZE))
                        return;
                if (task_bc->file_precharged < (1UL << task_bc->file_quant))
                        return;

В первом условии проверяется, что лимиты numfile и kmemsize достаточно далеки от
исчерпания (использовано менее 1/8 лимита). Поскольку для HN лимиты выставлены в
LONG_MAX, ждать этого придётся довольно долго. (До 2.6.16-026test019 вторая
половина этого условия отсутствовала, именно это и приводило к необходимости
перезагрузки HN - лимит kmemsize кончался задолго до 1/8 * LONG_MAX для numfile).

Во втором условии проверяется количество сохранённых дескрипторов для текущего
процесса - если их слишком много, часть из них будет освобождена.

Т.е., для освобождения дескрипторов, залипших где-нибудь в idle task или в
длительно работающем процессе, который не закрывает файлы, нужно, чтобы эти
дескрипторы вместе с прочими ресурсами заняли не менее 1/8 kmemsize (либо 1/8
numfile), и при освобождение struct file через RCU произошло бы в контексте
процесса, куда ранее попали эти дескрипторы.

Вообще получается, что при освобождении struct file через RCU механизм precharge
работает совершенно неправильно - при закрытии файлов их может получить в
->task_bc.file_precharged совершенно другой процесс (правда, обязательно из того
же VE - если VE не совпадает, ресурсы в beancounter освобождаются немедленно).
Что можно с этим сделать (помимо игнорирования проблемы):

1) Очевидный вариант - отключить эту оптимизацию совсем; в результате значение
счётчика numfile будет отражать реальную ситуацию, но при большом количестве
операций с файлами резко увеличится использование ub->ub_lock.

2) Вероятно, можно перенести вызов ub_file_uncharge() из file_free_rcu() в
file_free() - в этом случае file_precharged будет увеличиваться в нужном
процессе, но до реального освобождения структур file в file_free_rcu() может
пройти некоторое время, в течение которого эти структуры не будут учитываться в
numfile и kmemsize.

Кирилл, вы не могли бы прокомментировать эту проблему?

Сергей Власов нашел правильный патч и объяснение того, что происходит.

Всвязи с тем, что файлы освобождаются через RCU, механизм не стал работать 
неправильно, просто если раньше освобождение файлов в контексте "чужого" 
процесса происходило _крайне_ редко (но все же происходило), то сейчас эта 
ситуация стала нормальной.

Насчет предложений как можно эту ситуацию улучшить могу сказать следующее.
1) отключение оптимизации - это выход, но, конечно, неприемлемый.
2) перенос ub_file_uncharge() в file_free() лишь растянет процесс роста 
счетчика, поскольку file_free() все-таки может случиться в контексте любого 
процесса, хотя и гораздо реже чем в случае с RCU.

По поводу "залипания" дескрипторов на процессах, которые не используют файлы. 
Для этого есть file_quant, который отражает насколько сильно процессу нужны 
файлы. Для процессов таких как init или демоны, которым файлы обычно не нужны, 
эта величина будет ~4, то есть больше чем 16 файлов на них не задержится.

С найденным патчем проблема, вообще говоря, исчезает - счетчик перестает 
неограниченно расти. Меняется смысл numfile ресурса. Если раньше он показывал 
реальное количество открытых файлов, то теперь это лишь верхняя оценка этого 
числа, причем чем выше limit тем оценка грубее.

(In reply to comment #11)
> По поводу "залипания" дескрипторов на процессах, которые не используют файлы. 
> Для этого есть file_quant, который отражает насколько сильно процессу нужны 
> файлы. Для процессов таких как init или демоны, которым файлы обычно не нужны, 
> эта величина будет ~4, то есть больше чем 16 файлов на них не задержится.

file_quant не проверяется, пока лимит не будет выбран на 1/8, поэтому залипнет
заметно больше, чем 16 файлов. Возможно, стоит поменять условия освобождения,
чтобы файлы не накапливались.

(In reply to comment #12)
> (In reply to comment #11)
> > По поводу "залипания" дескрипторов на процессах, которые не используют 
файлы. 
> > Для этого есть file_quant, который отражает насколько сильно процессу нужны 
> > файлы. Для процессов таких как init или демоны, которым файлы обычно не 
нужны, 
> > эта величина будет ~4, то есть больше чем 16 файлов на них не задержится.
> 
> file_quant не проверяется, пока лимит не будет выбран на 1/8, поэтому залипнет
> заметно больше, чем 16 файлов. Возможно, стоит поменять условия освобождения,
> чтобы файлы не накапливались.

Имелось в виду, что так будет после того, как выберут 1/8. После этого с 
процесса снимут
         nr = task_bc->file_precharged
                        - (1UL << (task_bc->file_quant - 1));

Возможно условие освобождения стоит сменить.

Поставил 2.6.16-ovz-smp-alt10. 

numfile неограниченно расти перестал, однако на 2хPIII где-то через 8 часов 
работы получил следующее в syslog:

-----------
Nov  5 17:50:01 naf177 kernel: Uncharging too much 2147915339 h 1431728, res 
numfile ub 0
Nov  5 17:50:01 naf177 kernel: Uncharging too much 2221302809 h 268646595, res 
kmemsize ub 0
Nov  5 17:50:01 naf177 kernel: UB: Bad refcount (-2146297003) on put of 0 
(c0380e00)
Nov  5 17:50:01 naf177 kernel: UB: Bad refcount (-2146297004) on put of 0 
(c0380e00)
Nov  5 17:50:01 naf177 kernel: UB: Bad refcount (-2146297005) on put of 0 
(c0380e00)
Nov  5 17:50:01 naf177 kernel: Uncharging too much 15 h 0, res numfile ub 0
Nov  5 17:50:01 naf177 kernel: Uncharging too much 23119 h 0, res kmemsize ub 0
Nov  5 17:50:01 naf177 kernel: UB: Bad refcount (-2146297021) on put of 0 
(c0380e00)
...... <и ещё примерно 60 Mb подобных сообщений за 2 часа> .....
-------------

Целенаправлено система убивается где-то часа за два, запуском в HN
$ while ((1)); do ls / &>/dev/null; done

При этом до граничных значений kmemsize не доходит,
 0: kmemsize      218197152  268631574 2147483647 2147483647          0
    numfile         1276733    1568970 2147483647 2147483647          0

(In reply to comment #14)
Это уже выявлено. Скоро будет патч.
http://bugzilla.openvz.org/show_bug.cgi?id=322

Это уже пофиксили.

--- кусь ---
[UBC] Set correct precharge values for init_task.

Otherwise file freeing will happen in "swapper" context
and will spoil all statistics due to "negative" unsigned
long value.
---кусь---

http://bugzilla.openvz.org/show_bug.cgi?id=322
Описание проблемы.

http://git.openvz.org/?p=linux-2.6.16-openvz;a=commit;h=46d1e25bce7440b23652caf7f463670a5360890a
Патч.

Жду новую сборку на тестирование. :-)

(In reply to comment #16)
> Это уже пофиксили.
> 
> --- кусь ---
> [UBC] Set correct precharge values for init_task.
...
> Жду новую сборку на тестирование. :-)
kernel-feat-core-openvz с этим патчем лежит в cvs со вчерашнего дня. Сборку
нового ovz-smp блокирует сломанный feat-fs-squashfs, впрочем, я его скорее всего
выкину.

# uname -r
2.6.18-ovz-smp-alt3
# ls /proc/*/fd | wc -l
5563
# less /proc/user_beancounters
       uid  resource           held    maxheld    barrier      limit    failcnt
        0:  kmemsize      196662888  197263647 2147483647 2147483647          0
            numfile          914996     914996 2147483647 2147483647          0

Как же так? :(

Поправляю сам себя: бин-счётчики так же и ведут себя, как сумасшедшие, однако
это уже не столь фатально для хост-машины. В общем, однозначно советую
переходить на новое, 2.6.18-ovz-smp-alt3

Кто что может сказать о текущем положении дел? У меня пока эта ошибка ни разу не
воспроизвелась.

На 2.6.18-ovz-smp-alt8 и 2.6.16-ovz-smp-alt12 описанной проблемы не наблюдаю.

Наверное, имеет смысл закрыть этот вопрос. Значения счётчиков остаются далёкими 
от действительности (во всяком случае, на одной из машин сейчас у меня 
numfile(HN) < summ numfile(VPS) ), но жить это не мешает. 

1. Nikolay, я не понял замечания про "numfile(HN) < summ numfile(VPS)".
numfile(HN) - это те файлы что использует VE0. поэтому они никак не связаны с
VPS'ами...

2. В 2.6.18 проблема пофикшена. uncharge перенесен из RCU в file_free().

т.е. вроде бы можно закрывать.

Пока закрываю. Если что, опять откроем ;)

PS Кирилл, Сергей, спасибо за вашу помощь в выяснении причины проблемы.
PPS 2All Спасибо за проявленное терпение в поиске причин ошибки и отслеживания
ее статуса.