[sisyphus] ovz-smp#2.6.16-alt7 и numfile

[sisyphus] ovz-smp#2.6.16-alt7 и numfile

[Nikolay A. Fetisov]

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

Есть четыре машины с указанным ядром и на всех наблюдается одно и то
же занятное явление: с течением времени растёт значение счётчика
открытых файлов numfile для Hardware Node. Проблема в том, что
значение данного счётчика не уменьшается. Есть впечатление, что
закрытие файлов это на счётчике не отражается.

Т.е., например, на машине i586 с uptime порядка 50 часов для HN
при 296 процессах numfile - 11737048.

На машине с ядром x86_64 ситуация та же.

В контейнерах счётчики ведут себя вполне нормально.

Особенно неприятно то, что с ростом numfile также растёт и
значение kmemsize, при этом для указанной машины его размер сейчас уже
примерно равен барьерному значению в 2^31 - и единственным решением
является перезагрузка. 

С ядрами -alt3 и -alt4 данной проблемы не наблюдается.

Соответственно, вопросы: 
- проявляется ли это ещё у кого-нибудь?
- как бы это поправить. 

Да, на всякий случай - # 10154

-- 
С уважением,	
Николай Фетисов

Re: [sisyphus] ovz-smp#2.6.16-alt7 и numfile

[Konstantin A. Lepikhov]

<цитата от="Nikolay A. Fetisov">
> Здравствуйте!
>
> Есть четыре машины с указанным ядром и на всех наблюдается одно и то
> же занятное явление: с течением времени растёт значение счётчика
> открытых файлов numfile для Hardware Node. Проблема в том, что
> значение данного счётчика не уменьшается. Есть впечатление, что
> закрытие файлов это на счётчике не отражается.
У меня это не воспроизводится. Один раз машину пришлось перегружать из-за
того, что утекал Xorg server.

-- 
WBR et al.

Re: [sisyphus] ovz-smp#2.6.16-alt7 и numfile

[Nikolay A. Fetisov]

On Thu, 19 Oct 2006 10:25:21 +0400 (MSD)
Konstantin A. Lepikhov wrote:

> У меня это не воспроизводится. Один раз машину пришлось перегружать из-за
> того, что утекал Xorg server.

Очень интересно... У меня с этим ядром (было) 6 машин, с совсем разным
железом, от Celeron-433 до Opteron-265. С Sisyphus от разных дат,
начиная от конца августа до текущего. С разными версиями vzctl. С
разной историей жизни системы, от ведущей существование от Master
2.4 до установленной с сентябрьского LifeCD. Как с XOrg так и вообще без
него.
Общие вещи только две - ядро 2.6.16-ovz-smp-alt7 и плавное нарастание
numfile. Переход на -alt3 без изменения чего-либо проблему снимает.

Правда, есть ещё один момент: на 64-битных системах это заметить сложно.
Поскольку барьеры там 2^63-1, то расти до него kmemsize может очень
долго. А вот 32-битные машины к своему барьеру в 2^31-1
приближаются достаточно быстро.

И ещё, здесь _физически_ память не течёт. Просто обновление счётчиков
идёт только в сторону увеличения. Но превысить барьерное значение ядро
всё равно не даёт...


Да, а насчёт # 10157 - на HN ядро использует только один процессор
из доступных - это тоже только мне (с тремя машинами) не везёт?


... поехал последнюю машину на -alt3 переводить....
uptime неделя, numproc=56, numfile=586956, kmemsize=103176293 при
физически установленных 256 Mb...

-- 
С уважением,	
Николай Фетисов

Re: [sisyphus] ovz-smp#2.6.16-alt7 и numfile

[Dmitry Lebkov]

Konstantin A. Lepikhov wrote:
> <цитата от="Nikolay A. Fetisov">
>> Здравствуйте!
>>
>> Есть четыре машины с указанным ядром и на всех наблюдается одно и то
>> же занятное явление: с течением времени растёт значение счётчика
>> открытых файлов numfile для Hardware Node. Проблема в том, что
>> значение данного счётчика не уменьшается. Есть впечатление, что
>> закрытие файлов это на счётчике не отражается.
> У меня это не воспроизводится.

Таки воспроизводится на трех разных машинах - 2хXeon-3.2 (x86_64),
2xXeon-2.4 (i586), 1xP4-3.2 (c включенным HT).

Счетчик в HN только увеличивается, а в VSэ'ах значения "плавают".

-- 
WBR, Dmitry Lebkov

Re: [sisyphus] ovz-smp#2.6.16-alt7 и numfile

[Konstantin A. Lepikhov]

[-- Attachment #1: Type: text/plain, Size: 885 bytes --]

Hi Dmitry!

Thursday 19, at 06:33:38 PM you wrote:

> Konstantin A. Lepikhov wrote:
> > <цитата от="Nikolay A. Fetisov">
> >> Здравствуйте!
> >>
> >> Есть четыре машины с указанным ядром и на всех наблюдается одно и то
> >> же занятное явление: с течением времени растёт значение счётчика
> >> открытых файлов numfile для Hardware Node. Проблема в том, что
> >> значение данного счётчика не уменьшается. Есть впечатление, что
> >> закрытие файлов это на счётчике не отражается.
> > У меня это не воспроизводится.
> 
> Таки воспроизводится на трех разных машинах - 2хXeon-3.2 (x86_64),
> 2xXeon-2.4 (i586), 1xP4-3.2 (c включенным HT).
> 
> Счетчик в HN только увеличивается, а в VSэ'ах значения "плавают".
если не сложно, попробуйте пересобрать ядра без exec-shield и altsec и
сравнить. Если результат не изменится, придется откатывать ovz патч.

-- 
WBR et al.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] ovz-smp#2.6.16-alt7 и numfile

[Michael Shigorin]

On Thu, Oct 19, 2006 at 10:57:45AM +0400, Nikolay A. Fetisov wrote:
> Общие вещи только две - ядро 2.6.16-ovz-smp-alt7 и плавное нарастание
> numfile. Переход на -alt3 без изменения чего-либо проблему снимает.
> Правда, есть ещё один момент: на 64-битных системах это
> заметить сложно.  Поскольку барьеры там 2^63-1, то расти до
> него kmemsize может очень долго. А вот 32-битные машины к
> своему барьеру в 2^31-1 приближаются достаточно быстро.

Подтверждаю на alt10:
# fgrep numfile /proc/user_beancounters
            numfile                    746688               746769  9223372036854775807  9223372036854775807                    0
            numfile                      5035                 7218                32768                32768                    0
            numfile                        94                  990                 2048                 2048                    0
            numfile                      1219                13389                16384                32768                    0
            numfile                       197                 1095                16384                16384                    0
# fgrep kmemsize /proc/user_beancounters       
         0: kmemsize                210749995            212080235  9223372036854775807  9223372036854775807                    0
       102: kmemsize                  8389279             12073187             33554432             67108864                    0
       108: kmemsize                   407972              3080016              5242880              5592405                    0
       109: kmemsize                  1434486             16477277            268435456            335544320                    0
       201: kmemsize                   363932              2823505             33554432             67108864                    0

numfile вроде уже починили:

<lakostis> http://git.openvz.org/?p=linux-2.6.16-openvz;a=commitdiff;h=46d1e25bce7440b23652caf7f463670a5360890a;hp=d55df66c6e0f7917d13737cadee7b064e69a9a23 -f e 

Исправится squashfs, получится собрать.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] ovz-smp#2.6.16-alt7 и numfile

[Konstantin A. Lepikhov]

[-- Attachment #1: Type: text/plain, Size: 1732 bytes --]

Hi Nikolay!

Thursday 19, at 10:57:45 AM you wrote:

> On Thu, 19 Oct 2006 10:25:21 +0400 (MSD)
> Konstantin A. Lepikhov wrote:
> 
> > У меня это не воспроизводится. Один раз машину пришлось перегружать из-за
> > того, что утекал Xorg server.
> 
> Очень интересно... У меня с этим ядром (было) 6 машин, с совсем разным
> железом, от Celeron-433 до Opteron-265. С Sisyphus от разных дат,
> начиная от конца августа до текущего. С разными версиями vzctl. С
> разной историей жизни системы, от ведущей существование от Master
> 2.4 до установленной с сентябрьского LifeCD. Как с XOrg так и вообще без
> него.
> Общие вещи только две - ядро 2.6.16-ovz-smp-alt7 и плавное нарастание
> numfile. Переход на -alt3 без изменения чего-либо проблему снимает.
> 
> Правда, есть ещё один момент: на 64-битных системах это заметить сложно.
> Поскольку барьеры там 2^63-1, то расти до него kmemsize может очень
> долго. А вот 32-битные машины к своему барьеру в 2^31-1
> приближаются достаточно быстро.
> 
> И ещё, здесь _физически_ память не течёт. Просто обновление счётчиков
> идёт только в сторону увеличения. Но превысить барьерное значение ядро
> всё равно не даёт...
А что насчет -alt10? + я исправил
http://bugzilla.openvz.org/show_bug.cgi?id=322 в новой сборке -alt12, но
из-за саботажа со squashfs, она никак до сизифа не дойдет :(

> 
> 
> Да, а насчёт # 10157 - на HN ядро использует только один процессор
> из доступных - это тоже только мне (с тремя машинами) не везёт?
> 
> 
> ... поехал последнюю машину на -alt3 переводить....
> uptime неделя, numproc=56, numfile=586956, kmemsize=103176293 при
> физически установленных 256 Mb...
у меня все равно не поспроизводится :)

-- 
WBR et al.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] ovz-smp#2.6.16-alt7 и numfile

[Konstantin A. Lepikhov]

[-- Attachment #1: Type: text/plain, Size: 1494 bytes --]

Hi Michael!

Tuesday 07, at 11:29:45 AM you wrote:

> On Thu, Oct 19, 2006 at 10:57:45AM +0400, Nikolay A. Fetisov wrote:
> > Общие вещи только две - ядро 2.6.16-ovz-smp-alt7 и плавное нарастание
> > numfile. Переход на -alt3 без изменения чего-либо проблему снимает.
> > Правда, есть ещё один момент: на 64-битных системах это
> > заметить сложно.  Поскольку барьеры там 2^63-1, то расти до
> > него kmemsize может очень долго. А вот 32-битные машины к
> > своему барьеру в 2^31-1 приближаются достаточно быстро.
> 
> Подтверждаю на alt10:
> # fgrep numfile /proc/user_beancounters
>             numfile                    746688               746769  9223372036854775807  9223372036854775807                    0
>             numfile                      5035                 7218                32768                32768                    0
>             numfile                        94                  990                 2048                 2048                    0
>             numfile                      1219                13389                16384                32768                    0
>             numfile                       197                 1095                16384                16384                    0
Майк, прочти еще раз комментарии vsu@ и xemul@ к этой баге, это нормально, что
счетчики растут. Другое дело, что они показывают при этом полную ерунду.

https://bugzilla.altlinux.org/show_bug.cgi?id=10154#c11

-- 
WBR et al.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[sisyphus] [JT] s@b0

[Michael Shigorin]

On Tue, Nov 07, 2006 at 12:42:39PM +0300, Konstantin A. Lepikhov wrote:
> но из-за саботажа со squashfs, она никак до сизифа не дойдет :(

Чё-т у тебя сплошные саботажники вокруг ;)
Они всё-таки сперва люди и коллеги.
Мы все регулярно ошибаемся.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] ovz-smp#2.6.16-alt7 и numfile

[Michael Shigorin]

On Tue, Nov 07, 2006 at 12:47:38PM +0300, Konstantin A. Lepikhov wrote:
> Майк, прочти еще раз комментарии vsu@ и xemul@ к этой баге, это
> нормально, что счетчики растут. Другое дело, что они показывают
> при этом полную ерунду.

Н-да, это огорчает.

> https://bugzilla.altlinux.org/show_bug.cgi?id=10154#c11

Похоже, мне почта от багзилы приходит -- письмо из десятка.
Не в спаме при этом.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] ovz-smp#2.6.16-alt7 и numfile

[Nikolay A. Fetisov]

On Tue, 7 Nov 2006 12:42:39 +0300
Konstantin A. Lepikhov wrote:

> Thursday 19, at 10:57:45 AM you wrote:
> ....
> А что насчет -alt10? + я исправил
> http://bugzilla.openvz.org/show_bug.cgi?id=322 в новой сборке -alt12, но
> из-за саботажа со squashfs, она никак до сизифа не дойдет :(
> 

-alt10 на простеньком Celeron живёт третьи сутки, пока полёт нормальный.
На 2xPIII-933 я успешно получил за полдня два раза вышеупомянутый #322,
и откатился обратно на -alt3.


Меня сейчас больше занимает  
> > ... # 10157 - на HN ядро использует только один процессор
> > из доступных ...

Я понимаю, что на серверах, где практически всё живёт именно в VPS,
такое поведение правильно. Но на настольной машине, где в VPS живут
сборочные среды, да разные эпизодически нужные вещи, очень досадно
наблюдать бездействующий процессор. 

Очень хочется рубильник... 


> ....
> у меня все равно не поспроизводится :)

Хочу это ядро :-)

-- 
С уважением,	
Николай Фетисов