Может ли количество "грязных" буферов превышать LRU_MAX_DIRTY ? / Informix

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Informix [игнор отключен] [закрыт для гостей] / Может ли количество "грязных" буферов превышать LRU_MAX_DIRTY ?

9 сообщений из 9, страница 1 из 1

Может ли количество "грязных" буферов превышать LRU_MAX_DIRTY ?

#38319650

victor16

Гость

Код: plaintext

1.
2.
3.

informix@myhost:~> onstat -R | tail -4
2714856 dirty, 3999504 queued, 4000000 total, 4194304 hash buckets, 2048 buffer size
start clean at  28.530% (of pair total) dirty, or 12012 buffs dirty, stop at 19.020%

Собственно, вопрос в сабже. Нетрудно посчитать что количество dirty = 2714856 поделить на total = 4000000
получим 67,871%, что значительно больше start clean at 28.530%

С уважением,
Виктор

...

Рейтинг:

0 / 0

03.07.2013, 21:50

| Ответить | Цитировать | Написать

Может ли количество "грязных" буферов превышать LRU_MAX_DIRTY ?

#38319748

GVF112GVF

Гость

victor16,

Можно посмотреть на onconfig ?

onstat -c | grep -i AUTO_LRU_TUNING
onstat -c | grep -i BUFFERPOOL

С уважением,
Вадим.

...

Рейтинг:

0 / 0

03.07.2013, 23:51

| Ответить | Цитировать | Написать

Может ли количество "грязных" буферов превышать LRU_MAX_DIRTY ?

#38319935

GVF112GVF

Гость

victor16,

FYI ..

Minimizing Buffer Turnover Rate - http://ibmdatamag.com/2013/06/minimizing-buffer-turnover-rate/

С уважением,
Вадим.

...

Рейтинг:

0 / 0

04.07.2013, 09:38

| Ответить | Цитировать | Написать

Может ли количество "грязных" буферов превышать LRU_MAX_DIRTY ?

#38320181

victor16

Гость

GVF112GVFМожно посмотреть на onconfig ?

onstat -c | grep -i AUTO_LRU_TUNING
onstat -c | grep -i BUFFERPOOL

Код: plaintext

1.
2.
3.
4.

AUTO_LRU_TUNING 1
BUFFERPOOL      size=2K,buffers=4000000,lrus=95,lru_min_dirty=20.00,lru_max_dirty=30.00
BUFFERPOOL      default,buffers=1000,lrus=7,lru_min_dirty=50.00,lru_max_dirty=60.00
 [code=plaintext]

...

Рейтинг:

0 / 0

04.07.2013, 11:47

| Ответить | Цитировать | Написать

Может ли количество "грязных" буферов превышать LRU_MAX_DIRTY ?

#38320241

GVF112GVF

Гость

victor16GVF112GVFМожно посмотреть на onconfig ?

onstat -c | grep -i AUTO_LRU_TUNING
onstat -c | grep -i BUFFERPOOL

Код: plaintext

1.
2.
3.

AUTO_LRU_TUNING 1
BUFFERPOOL      size=2K,buffers=4000000,lrus=95,lru_min_dirty=20.00,lru_max_dirty=30.00
BUFFERPOOL      default,buffers=1000,lrus=7,lru_min_dirty=50.00,lru_max_dirty=60.00
 [code=plaintext]

Что показывает onstat -F, onstat -p ?

С уважением,
Вадим.

...

Рейтинг:

0 / 0

04.07.2013, 12:18

| Ответить | Цитировать | Написать

Может ли количество "грязных" буферов превышать LRU_MAX_DIRTY ?

#38320296

GVF112GVF

Гость

victor16,

Возможна такая ситуация (при AUTO_LRU_TUNING=1):
...
After a checkpoint has occurred, if a page replacement performed a foreground write during the previous checkpoint interval, the database server increases the LRU settings by 5 percent and continues to increase the LRU flushing at each subsequent checkpoint until the foreground write stops or until the lru_max_dirty for a given buffer pool falls below 10 percent.

Более детально - http://pic.dhe.ibm.com/infocenter/idshelp/v117/topic/com.ibm.perf.doc/ids_prf_276.htm

С уважением,
Вадим.

...

Рейтинг:

0 / 0

04.07.2013, 12:37

| Ответить | Цитировать | Написать

Может ли количество "грязных" буферов превышать LRU_MAX_DIRTY ?

#38320335

victor16

Гость

после перезагрузки

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.

onstat -F

Fg Writes     LRU Writes    Chunk Writes
0             0             2114364

address           flusher  state    data     # LRU    Chunk    Wakeups  Idle Tim
26bbae878        0        I        0        0        10668    28977    18301.555
26bbaf0c8        1        I        0        0        3583     21885    18291.118
26bbaf918        2        I        0        0        275      18546    18254.546
26bbb0168        3        I        0        0        241      18532    18283.491
26bbb09b8        4        I        0        0        221      18532    18311.763
26bbb1208        5        I        0        0        178      18489    18310.723
26bbb1a58        6        I        0        0        116      18427    18310.724
26bbb22a8        7        I        0        0        72       18379    18303.577
26bbb2af8        8        I        0        0        53       18345    18285.218
26bbb3348        9        I        0        0        32       18323    18287.588
26bbb3b98        10       I        0        0        17       18330    18314.260
26bbb43e8        11       I        0        0        8        18321    18314.703
26bbb4c38        12       I        0        0        0        18313    18314.978
26bbb5488        13       I        0        0        0        18313    18314.978
26bbb5cd8        14       I        0        0        0        18313    18314.969
26bbb6528        15       I        0        0        0        18313    18314.978
26bbb6d78        16       I        0        0        0        18313    18314.978
26bbb75c8        17       I        0        0        0        18313    18314.974
26bbb7e18        18       I        0        0        0        18313    18314.977
26bbb8668        19       I        0        0        0        18313    18314.977
26bbb8eb8        20       I        0        0        0        18313    18314.980
26bbb9708        21       I        0        0        0        18313    18314.971
26bbb9f58        22       I        0        0        0        18313    18314.982
26bbba7a8        23       I        0        0        0        18313    18314.973
26bbbaff8        24       I        0        0        0        18313    18314.982
26bbbb848        25       I        0        0        0        18313    18314.984
26bbbc098        26       I        0        0        0        18313    18314.979
26bbbc8e8        27       I        0        0        0        18313    18314.982
26bbbd138        28       I        0        0        0        18313    18314.975
26bbbd988        29       I        0        0        0        18313    18314.973
26bbbe1d8        30       I        0        0        0        18313    18314.977
26bbbea28        31       I        0        0        0        18313    18314.980
      states: Exit Idle Chunk Lru

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.

onstat -p

Profile
dskreads   pagreads   bufreads   %cached dskwrits   pagwrits   bufwrits   %cached
60848092   92937633   2825804860 97.85   2326447    4444615    86043819   97.30

isamtot    open       start      read       write      rewrite    delete     commit     rollbk
2797312703 13056396   61631096   2314501959 31902155   155632     11067      1421352    24

gp_read    gp_write   gp_rewrt   gp_del     gp_alloc   gp_free    gp_curs
4917188    153520     2571273    356        1          0          35

ovlock     ovuserthread ovbuff     usercpu  syscpu   numckpts   flushes
0          0            0          8301.10  764.95   72         10668

bufwaits   lokwaits   lockreqs   deadlks    dltouts    ckpwaits   compress   seqscans
15116      20         2386253850 0          0          61         434019     511295

ixda-RA    idx-RA     da-RA      logrec-RA  RA-pgsused lchwaits
0          607780     4929       0          428172     246484

...

Рейтинг:

0 / 0

04.07.2013, 12:52

| Ответить | Цитировать | Написать

Может ли количество "грязных" буферов превышать LRU_MAX_DIRTY ?

#38320404

victor16

Гость

В принципе я понял, что произошло. Стандартной командой EXECUTE FUNCTION task("defragment","<tablename>");
была запущена дефрагментация одной достаточной емкой таблицы, зеркало которого находится на слабом диске.
В результате, скорость чтения старых фрагментов значительно опережала скорость записи в новый фрагмент, сервер помещал их в буферный пул, помечал их грязными, ну и получилась картина из первого сообщения. Поскольку операция дефрагментирования журналируется, соответствующим образом задействуются логический и физический журналы. Далее в последний помещаются pre-image страниц из старых фрагментов, а скинуться оттуда не успевают (зеркало то слабое, а операции записи идут параллельно), физический журнал забивается, из-за нехватки места генерится контрольная точка, которая через некоторое время блокирует все остальные действия сервера, за исключением сброса буферов в новый фрагмент. Операцию дефрагментации отменять категорически не рекомендуется, пришлось нервно ждать окончания и периодически (в момент входа контрольной точки в состояние "BLOCKED") успокаивать недовольных юзверов. Сейчас то, когда картина ясная, понятно, что нужно было предварительно отключить зеркало перед дефрагментацией.
Впрочем, нет худа без добра, зеркало срочным образом заменили на новый SAS-диск :).

...

Рейтинг:

0 / 0

04.07.2013, 13:21

| Ответить | Цитировать | Написать

Может ли количество "грязных" буферов превышать LRU_MAX_DIRTY ?

#38320635

GVF112GVF

Гость

victor16В принципе я понял, что произошло. Стандартной командой EXECUTE FUNCTION task("defragment","<tablename>");
была запущена дефрагментация одной достаточной емкой таблицы, зеркало которого находится на слабом диске.
В результате, скорость чтения старых фрагментов значительно опережала скорость записи в новый фрагмент, сервер помещал их в буферный пул, помечал их грязными, ну и получилась картина из первого сообщения. Поскольку операция дефрагментирования журналируется, соответствующим образом задействуются логический и физический журналы. Далее в последний помещаются pre-image страниц из старых фрагментов, а скинуться оттуда не успевают (зеркало то слабое, а операции записи идут параллельно), физический журнал забивается, из-за нехватки места генерится контрольная точка, которая через некоторое время блокирует все остальные действия сервера, за исключением сброса буферов в новый фрагмент. Операцию дефрагментации отменять категорически не рекомендуется, пришлось нервно ждать окончания и периодически (в момент входа контрольной точки в состояние "BLOCKED") успокаивать недовольных юзверов. Сейчас то, когда картина ясная, понятно, что нужно было предварительно отключить зеркало перед дефрагментацией.
Впрочем, нет худа без добра, зеркало срочным образом заменили на новый SAS-диск :).

Да, прикольно. ... кто мог подумать, что и такое возможно .. :)

С уважением,
Вадим.

PS: There are more things in heaven and earth, Horatio,
Than are dreamt of in your philosophy.
(W. Shakespeare, Hamlet)

...

Рейтинг:

0 / 0

04.07.2013, 15:04

| Ответить | Цитировать | Написать

9 сообщений из 9, страница 1 из 1

Форумы / Informix [игнор отключен] [закрыт для гостей] / Может ли количество "грязных" буферов превышать LRU_MAX_DIRTY ?

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=44&gotonew=1&tid=1607038]:	0ms
get settings:	28ms
get forum list:	15ms
check forum access:	4ms
check topic access:	4ms
track hit:	41ms
get topic data:	10ms
get first new msg:	9ms
get forum data:	2ms
get page messages:	233ms
get tp. blocked users:	2ms
others:	290ms

total:	638ms