ARC max size

Slawa Olhovchenkov написал(а) к All в May 18 15:26:44 по местному времени:

Нello All!

женя, твой любимый костыль сломан:

vfs.zfs.arc_max=367001600
ARC Size: 137.21% 480.24 MiB
Target Size: (Adaptive) 100.00% 350.00 MiB
Min Size (Нard Limit): 43.71% 152.99 MiB
Max Size (Нigh Water): 2:1 350.00 MiB

На самом деле даже это все вранье и ARC жрет в данном случае примерно

28.309 zfsznodecache 264*(112417+23)
36.250 ziodata_buf131072 131072*(78+212)
38.252 dmubuf_implt 232*(168711+4179)
79.938 ziobuf512 512*(160568+3144)
92.703 ziobuf16384 16384*(5829+104)
113.354 dnode_t 728*(160804+2466)
749.027 abd_chunk 4096*(35881+155870)

1138.46MB

PS: к вопросу о говногите: все abd_chunk видят? я вот не знаю как с этим сейчас работать и что это, и будет ли адекватно с ним работать тот код что регулирует ARC size. похоже что нет. т.е. то что у меня будет лучше чем то, что сейчас, но на самом деле надо модифицировать.

... Кто юзал мой логин и весь его выюзал?!
--- GoldED+/BSD 1.1.5-b20110223-b20110223

Eugene Grosbein написал(а) к Slawa Olhovchenkov в May 18 21:14:27 по местному времени:

11 мая 2018, пятница, в 13:26 NOVT, Slawa Olhovchenkov написал(а):

SO> женя, твой любимый костыль сломан:
SO> vfs.zfs.arc_max=367001600
SO> ARC Size: 137.21% 480.24 MiB
SO> Target Size: (Adaptive) 100.00% 350.00 MiB
SO> Min Size (Нard Limit): 43.71% 152.99 MiB
SO> Max Size (Нigh Water): 2:1 350.00 MiB
SO> На самом деле даже это все вранье и ARC жрет в данном случае примерно
SO> 28.309 zfsznodecache 264*(112417+23)
SO> 36.250 ziodata_buf131072 131072*(78+212)
SO> 38.252 dmubuf_implt 232*(168711+4179)
SO> 79.938 ziobuf512 512*(160568+3144)
SO> 92.703 ziobuf16384 16384*(5829+104)
SO> 113.354 dnode_t 728*(160804+2466)
SO> 749.027 abd_chunk 4096*(35881+155870)
SO> 1138.46MB

В таких случаях тащем-то надо упоминать ветку, ревизию и даже платформу,
так как неработа лимита на i386 для меня не новость. И наличие локальных
патчей на ZFS тоже.

Eugene
--
Поэты - страшные люди. У них все святое.
--- slrn/1.0.2 (FreeBSD)

Slawa Olhovchenkov написал(а) к Eugene Grosbein в May 18 16:53:28 по местному времени:

Нello Eugene!

11 May 18, Eugene Grosbein writes to Slawa Olhovchenkov:

SO>> женя, твой любимый костыль сломан:
SO>> vfs.zfs.arc_max=367001600
SO>> ARC Size: 137.21% 480.24 MiB
SO>> Target Size: (Adaptive) 100.00% 350.00 MiB
SO>> Min Size (Нard Limit): 43.71% 152.99 MiB
SO>> Max Size (Нigh Water): 2:1 350.00 MiB
SO>> На самом деле даже это все вранье и ARC жрет в данном случае примерно
SO>> 28.309 zfsznodecache 264*(112417+23)
SO>> 36.250 ziodata_buf131072 131072*(78+212)
SO>> 38.252 dmubuf_implt 232*(168711+4179)
SO>> 79.938 ziobuf512 512*(160568+3144)
SO>> 92.703 ziobuf16384 16384*(5829+104)
SO>> 113.354 dnode_t 728*(160804+2466)
SO>> 749.027 abd_chunk 4096*(35881+155870)
SO>> 1138.46MB

EG> В таких случаях тащем-то надо упоминать ветку, ревизию и даже платформу,
EG> так как неработа лимита на i386 для меня не новость. И наличие локальных
EG> патчей на ZFS тоже.

ой, ну догадайся: 11-STABLE latest, amd64, ванилька (никаких патчей вообще)
стал бы я гундеть, если бы там были какие-то патчи? всегда же можно попытаться стрелки перевести.

... Ошибка пpи загpузке? Не обpащайте внимания.
--- GoldED+/BSD 1.1.5-b20110223-b20110223

Alex Korchmar написал(а) к Slawa Olhovchenkov в May 18 18:49:20 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Slawa Olhovchenkov <Slawa.Olhovchenkov@f500.n5030.z2.fidonet.org> wrote:

SO> На самом деле даже это все вранье и ARC жрет в данном случае примерно
а top что при этом показывает в строке "arc"?

> Alex

--- ifmail v.2.15dev5.4

Slawa Olhovchenkov написал(а) к Alex Korchmar в May 18 19:04:58 по местному времени:

Нello Alex!

11 May 18, Alex Korchmar writes to Slawa Olhovchenkov:

SO>> На самом деле даже это все вранье и ARC жрет в данном случае примерно
AK> а top что при этом показывает в строке "arc"?

Mem: 3516K Active, 47M Inact, 1588M Wired, 320M Free
ARC: 480M Total, 192M MFU, 85M MRU, 32K Anon, 4854K Нeader, 198M Other

виртуалка с двумя гигами.

... Дpужбы наpодов надежный applet
--- GoldED+/BSD 1.1.5-b20110223-b20110223

Alex Korchmar написал(а) к Slawa Olhovchenkov в May 18 19:33:51 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Slawa Olhovchenkov <Slawa.Olhovchenkov@f500.n5030.z2.fidonet.org> wrote:

SO>>> На самом деле даже это все вранье и ARC жрет в данном случае примерно
AK>> а top что при этом показывает в строке "arc"?
SO> Mem: 3516K Active, 47M Inact, 1588M Wired, 320M Free
SO> ARC: 480M Total, 192M MFU, 85M MRU, 32K Anon, 4854K Нeader, 198M Other
па-аанятна, вот почему памяти "внезапно" не хватает.

(этот abd с нами с весны прошлого года, судя по логам. в arc.c
есть такое: kmemcache_reap_soon(abd_chunkcache);

то есть где-то оно его пытается подрезать.


> Alex

--- ifmail v.2.15dev5.4

Slawa Olhovchenkov написал(а) к Alex Korchmar в May 18 19:41:50 по местному времени:

Нello Alex!

11 May 18, Alex Korchmar writes to Slawa Olhovchenkov:


SO>>>> На самом деле даже это все вранье и ARC жрет в данном случае
SO>>>> примерно
AK>>> а top что при этом показывает в строке "arc"?
SO>> Mem: 3516K Active, 47M Inact, 1588M Wired, 320M Free
SO>> ARC: 480M Total, 192M MFU, 85M MRU, 32K Anon, 4854K Нeader, 198M Other
AK> па-аанятна, вот почему памяти "внезапно" не хватает.

AK> (этот abd с нами с весны прошлого года, судя по логам. в arc.c

именно по этому у меня в продакшене до сих пор r318139.
и это вовсе не вопрос гита и его мержа, это вообще перенебрежимый вопрос.

AK> есть такое: kmemcache_reap_soon(abd_chunkcache);

AK> то есть где-то оно его пытается подрезать.

ну с результатом как обычно

... Спать ложился pано утpом, вечеpами все звонил кому-то... (c) Сплин
--- GoldED+/BSD 1.1.5-b20110223-b20110223

Alex Korchmar написал(а) к Slawa Olhovchenkov в May 18 21:34:54 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Slawa Olhovchenkov <Slawa.Olhovchenkov@f500.n5030.z2.fidonet.org> wrote:

AK>> (этот abd с нами с весны прошлого года, судя по логам. в arc.c
SO> именно по этому у меня в продакшене до сих пор r318139.
SO> и это вовсе не вопрос гита и его мержа, это вообще перенебрежимый вопрос.
ну да, когда времени и так нет - еще тратить его на ручное выполнение давно
автоматизированных задач.
Судя по "ifdef illumos", старый патч никуда не денется, разьве что придется
отдельно придумывать новый еще и для этой пакости. Этот, судя по странным
ошметьям копипасты в комит-логе, подарок из линукса. И в нем он завязан на
странные взаимоотношения arc и buffer cache, а нам, как обычно, достался в
сильно порезанном и не факт что работающем виде (судя по опять же логу -
пытались суматошно улучшать, не очень понимая, "где ж могло пойти не так")

AK>> есть такое: kmemcache_reap_soon(abd_chunkcache);
AK>> то есть где-то оно его пытается подрезать.
SO> ну с результатом как обычно
посмотрел - это arckmem_reapnow() - то есть ровно та хрень, которую
заменяли твоим кодом. Результат "как обычно" - все висло к хренам.
Я, правда, не проверял с асинхронной рипалкой, она появилась уже после
того, как я сдал ноут на склад.


> Alex

--- ifmail v.2.15dev5.4

Eugene Grosbein написал(а) к Slawa Olhovchenkov в May 18 03:52:40 по местному времени:

11 мая 2018, пятница, в 14:53 NOVT, Slawa Olhovchenkov написал(а):

SO>>> женя, твой любимый костыль сломан:
SO>>> vfs.zfs.arc_max=367001600
SO>>> ARC Size: 137.21% 480.24 MiB
SO>>> Target Size: (Adaptive) 100.00% 350.00 MiB
SO>>> Min Size (Нard Limit): 43.71% 152.99 MiB
SO>>> Max Size (Нigh Water): 2:1 350.00 MiB
SO>>> На самом деле даже это все вранье и ARC жрет в данном случае примерно
SO>>> 28.309 zfsznodecache 264*(112417+23)
SO>>> 36.250 ziodata_buf131072 131072*(78+212)
SO>>> 38.252 dmubuf_implt 232*(168711+4179)
SO>>> 79.938 ziobuf512 512*(160568+3144)
SO>>> 92.703 ziobuf16384 16384*(5829+104)
SO>>> 113.354 dnode_t 728*(160804+2466)
SO>>> 749.027 abd_chunk 4096*(35881+155870)
SO>>> 1138.46MB
EG>> В таких случаях тащем-то надо упоминать ветку, ревизию и даже платформу,
EG>> так как неработа лимита на i386 для меня не новость. И наличие локальных
EG>> патчей на ZFS тоже.
SO> ой, ну догадайся: 11-STABLE latest, amd64, ванилька (никаких патчей вообще)
SO> стал бы я гундеть, если бы там были какие-то патчи? всегда же можно попытаться
SO> стрелки перевести.

Ну вот у меня есть 11.1-STABLE/amd64 r325097 с 64G памяти,
ZFS и лимитом в 32G. Откуда вообще отквоченные цифры и как
мне посмотреть их у себя?

Eugene
--- slrn/1.0.2 (FreeBSD)

Slawa Olhovchenkov написал(а) к Alex Korchmar в May 18 00:04:30 по местному времени:

Нello Alex!

11 May 18, Alex Korchmar writes to Slawa Olhovchenkov:

AK>>> (этот abd с нами с весны прошлого года, судя по логам. в arc.c
SO>> именно по этому у меня в продакшене до сих пор r318139.
SO>> и это вовсе не вопрос гита и его мержа, это вообще перенебрежимый
SO>> вопрос.
AK> ну да, когда времени и так нет - еще тратить его на ручное выполнение давно
AK> автоматизированных задач.

так ты пальцем-то покажи, что и как там автоматизированно.
ну попростому.
засовываешь в гит версию до ARC compress.
прикладываешь мой патч.
апдейтишь до последней STABLE (ну просто дифф накатываешь).
показываешь какие действия надо сделать с гитом.
показываешь результирующий патч.
ну а мы все делаем "вау! как удобно! и чего мы ебались?"

AK> Судя по "ifdef illumos", старый патч никуда не денется, разьве что
AK> придется отдельно придумывать новый еще и для этой пакости. Этот, судя
AK> по странным ошметьям копипасты в комит-логе, подарок из линукса. И в
AK> нем он завязан на странные взаимоотношения arc и buffer cache, а нам,
AK> как обычно, достался в сильно порезанном и не факт что работающем виде
AK> (судя по опять же логу - пытались суматошно улучшать, не очень
AK> понимая, "где ж могло пойти не так")

ну кажется его можно более-менее вырубить.

booleant zfs_abd_scatter_enabled = BFALSE;

AK>>> есть такое: kmemcache_reap_soon(abd_chunkcache);
AK>>> то есть где-то оно его пытается подрезать.
SO>> ну с результатом как обычно
AK> посмотрел - это arckmem_reapnow() - то есть ровно та хрень, которую
AK> заменяли твоим кодом. Результат "как обычно" - все висло к хренам.
AK> Я, правда, не проверял с асинхронной рипалкой, она появилась уже после
AK> того, как я сдал ноут на склад.

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

... И вновь я не замечен Plug-n-Play'ем...
--- GoldED+/BSD 1.1.5-b20110223-b20110223