Период между сообщениями больше года.
Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
мда картина несколько отличается от той что по ссылке session #RSAM total used id user tty pid hostname threads memory memory 88816 informix 64 14336 sf880 3 17006592 16881984 tid name rstcb flags curstk status 88970 ontape 15b09f868 --AP--M 3935 sleeping(secs: 1) 89002 arcbacku 15b098a68 ----X-- 4943 sleeping(Forever) 89003 arcbacku 15b093108 ------- 2879 sleeping(secs: 1) Memory pools count 1 name class addr totalsize freesize #allocfrag #freefrag 88816 V 15e3e2028 17006592 124608 422 19 name free used name free used overhead 0 176 scb 0 144 opentable 0 5664 filetable 0 2696 log 0 6504 temprec 0 1656 keys 0 424 gentcb 0 21336 ostcb 0 2824 net 0 16821328 sort 0 104 sqscb 0 11080 rdahead 0 224 hashfiletab 0 1656 osenv 0 2392 sqtcb 0 3696 fragman 0 80 Informix Dynamic Server Version 7.31.FD6 -- On-Line (Prim) -- Up 2 days 23:34:48 -- 2331648 Kbytes Stack for thread: 89002 arcbackup1 base: 0x000000016e44a000 len: 270336 pc: 0x00000001004e57b0 tos: 0x000000016e48aed1 state: sleeping vp: 4 0x1004e57b0 ?unknown? :: ?unknown? + 0x0 sp=0x16e48b6d0(0x9204f8, 0x5c5d0cd0, 0x925400, 0x5b014ed8, 0x6e4fe0d0, 0x5b014e60) 0x1004fd320 ?unknown? :: ?unknown? + 0x0 sp=0x16e48b780 delta_sp=176(0x5c98dae8, 0x9202d4, 0x3, 0x9204f8, 0x5c98dae8, 0x45) 0x100349f84 ?unknown? :: ?unknown? + 0x0 sp=0x16e48b830 delta_sp=176(0x2000, 0x9253c0, 0x587a4000, 0x800, 0x1, 0x29) 0x10034a954 ?unknown? :: ?unknown? + 0x0 sp=0x16e48ba70 delta_sp=576(0x8, 0x1, 0x6d870400, 0x5, 0x5b0c5e80, 0xb0f48) 0x10041f9ec ?unknown? :: ?unknown? + 0x0 sp=0x16e48bb40 delta_sp=208(0x0, 0x6cdc9c00, 0x3ff800, 0x6e48be44, 0x910e90, 0xd814) 0x10041f868 ?unknown? :: ?unknown? + 0x0 sp=0x16e48bcd0 delta_sp=400(0x6e48be44, 0x6e48be48, 0x265, 0x5d6f8240, 0x5d9dc678, 0x6e48be48) 0x10041e6a4 ?unknown? :: ?unknown? + 0x0 sp=0x16e48bd80 delta_sp=176(0xffffbfff, 0x8590, 0x4f030, 0x1, 0x5d6f8240, 0x1) 0x1004f31a4 ?unknown? :: ?unknown? + 0x0 sp=0x16e48be50 delta_sp=208(0x9204f8, 0x7, 0x925400, 0x5b014ed8, 0x0, 0x5b014e60) 0x1004eb284 ?unknown? :: ?unknown? + 0x0 sp=0x16e48bf00 delta_sp=176(0x0, 0x0, 0x0, 0x0, 0x0, 0x0) ^Constat> CCFLAGS не установлен на днях собираюсь поменять ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2004, 19:30 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
долго не меняли тк решили сначала получить подтверждение суппорта. Подтверждение получили, параметр CCFLAGS установлен, все зашибись! До чекпойнта пока руки не дошли :-( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2004, 12:11 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
Так что, продолжим о чекпойнтах ? Сведем основные предложения и мои рекомендации: - увеличить PHYSFILE - 10000 маловато даже для средней системы. Кстати, я обычно всегда мониторю среднее кол-во КТ и сравниваю его с "нормальным", т.е. по параметру TXTIMEOUT. Резкое отличие (в период работы) говорит, обычно, о срабатывании КТ по заполненности физжурнала, хотя есть и другие причины. Причины длинных КТ по причине, не связанной с сбросом страниц на диск, кстати, тоже могут быть видны в onstat -p (numckpts). - уменьшить LRU_MAX_DIRTY 60 и LRU_MIN_DIRTY 50 до значений, для начала 20 и 5 и мониторить, как уже говорили, заполненность LRU в момент КТ. - увеличить до максимального LRUS 8 (сделать 127). Думаю, что и bufwaits должен уменьшиться - возможно, увеличить CLEANERS 8 до больших значений. Надо мониторить активность по onstat -u и желательно, чтобы всегда был хоть один процесс сброса, у которого ативность на два порядка меньше остальных (для снятия пиковых нагрузок на запись). - RA_PAGES и RA_THRESHOLD тоже неплохо бы использовать, например 128 64, но тут Игорь может постращать глюками на этот счет :)) P.S. > Если такое (слишком частые чекпоинты) бывает часто ... хорошо бы > помониторить кто именно вызывает подобные проблемы. Например, создание > временных таблиц без WITH NO LOG. А вот эта причина меня удивила. Никогда о таком не читал. Т.е. создание временной таблицы в логируемом пространстве вызывает КТ ? А где это вычитал ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.03.2004, 14:53 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
cprдолго не меняли тк решили сначала получить подтверждение суппорта. Подтверждение получили, параметр CCFLAGS установлен, все зашибись! До чекпойнта пока руки не дошли :-( А сейчас дошли? Чем закончилась история? Побороли длинный чекпоинт? И какая версия Информикса при этом использовалась? CCFLAGS на что-то повлиял? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2006, 13:45 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
Тишина... А вопрос ведь интересный. И по прежнему актуальный... -- Legions of Informix forever! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2006, 11:14 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
Проблема действительно интересная. Я не смог ее победить и понять тоже не смог. Для меня осталось загадкой чем занимается информикс во время чекпоинта. Я понял что мои сервера скидывают индексные страницы на диск во время фаззи и не фаззи чекпоинта, но при кол-ве грязных страниц 1%, это не так много. Еще скидывается физ.лог. Т.е. вроде бы получается рекомендация положить данные/индексы на раид с быстрым рандомным доступом, а физ.лог на раид с быстрой последовательной записью. Но возможно проблема в том что при большом кол-ве буферов алгоритм поиска грязных буферов становится неоптимальным. В новых версиях это побеждено, к тому же размер страницы можно сделать 8-16кб, т.е. кол-во буферов уменьшится, уменьшится blevel (если кого-то это заботит). ----------------------------------------------------------------------------------------------------------------------------------------- нужно делать то что нужно, а то что не нужно -- делать не нужно (перефразируя В-Пуха). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2006, 11:34 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
Проблема длинного чекпойнта так и не решена. На сегодняшний момент установлен старт очистителя с 1% грязных страниц до 0. Переехали на SF890 и стало полегче. По проблеме удалось только экспериментально определиться что Solaris Volume Manager не причем (во что впрочем и не очень то верилось). Разворачивал тестовый пример на чистом дбспэйсе на нормальных рав-девайсах без метаустройств - эффект тотже. Чем занят Informix во время сброса чек-пойнта непонятно :-( Уменьшать же количество буферов не выход, т.к. упадет кэширование. К тому же это никакое не решение, а только другой способ заставить работать LRU еще раньше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.09.2006, 20:52 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
cpr... Переехали на SF890 и стало полегче. Кстати что такое SF890? Кэш у нее сколько? Rootdbs (PHYSDBS) не пробовал на отдельный от данных (raid) lun положить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2006, 15:42 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис cpr... Переехали на SF890 и стало полегче. Кстати что такое SF890? Кэш у нее сколько? Rootdbs (PHYSDBS) не пробовал на отдельный от данных (raid) lun положить? sf890 - Ultra SPARC IV , двухъядерный процессор. rootdbs, logdbs, пространства с данными находятся на независимых устройствах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2006, 16:19 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
И еще: предположим во время чекпоинта надо записать 15 мег., мои дисковые массивы при direct random write при 4кб записях показывают от 0.5 до 15 мег/сек (меряю iozone), поэтому легко можно и 30 секунд писать на дешевом массиве с маленьким кэшем на запись. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2006, 16:52 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
cpr Чем занят Informix во время сброса чек-пойнта непонятно :-( Уменьшать же количество буферов не выход, т.к. упадет кэширование. К тому же это никакое не решение, а только другой способ заставить работать LRU еще раньше. А результаты onstat -u по ходу такого чекпоинта можно увидеть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2006, 17:37 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
Добрый день всем. На Вашем сервере слишком малое количество LRU-очередей и они, как следуствие, слишком длинные. Просто просканировать такие очереди занимает время! Кроме того, число клинеров в несколько раз меньше числа чанков. Мне кажется, полегчает, если Вы увеличите количество LRU-очередей хотя бы до 63 (а лучше до 128, тем более что это ничего не стоит) и количество клинеров увеличите до того же числа (ресурсов они не занимают, поскольку эти нити существуют только во время их работы). Эти действия также уменьшат конкуренцию за сами LRU-очереди, если у Вас достаточно много конкурентных пользовательских сессий. ------- С уважением, Александр Спирин ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2006, 17:29 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
АлексанДобрый день всем. На Вашем сервере слишком малое количество LRU-очередей и они, как следуствие, слишком длинные. Просто просканировать такие очереди занимает время! Кроме того, число клинеров в несколько раз меньше числа чанков. Мне кажется, полегчает, если Вы увеличите количество LRU-очередей хотя бы до 63 (а лучше до 128, тем более что это ничего не стоит) и количество клинеров увеличите до того же числа (ресурсов они не занимают, поскольку эти нити существуют только во время их работы). Эти действия также уменьшат конкуренцию за сами LRU-очереди, если у Вас достаточно много конкурентных пользовательских сессий. ------- С уважением, Александр Спирин Вообще то в настоящий момент 34 очереди и никакой разницы с 8-ю. ИМХО механизм скана LRU у Informix сделан оптимально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2006, 19:45 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
АлексанДобрый день всем. На Вашем сервере слишком малое количество LRU-очередей и они, как следуствие, слишком длинные. Просто просканировать такие очереди занимает время! Кроме того, число клинеров в несколько раз меньше числа чанков. Мне кажется, полегчает, если Вы увеличите количество LRU-очередей хотя бы до 63 (а лучше до 128, тем более что это ничего не стоит) и количество клинеров увеличите до того же числа (ресурсов они не занимают, поскольку эти нити существуют только во время их работы). Эти действия также уменьшат конкуренцию за сами LRU-очереди, если у Вас достаточно много конкурентных пользовательских сессий. ------- С уважением, Александр Спирин Делал тестовый скрипт, который запускал на машине с одним чанком, скорость сброса 4 метра в секунду. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2006, 19:47 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
Журавлев ДенисИ еще: предположим во время чекпоинта надо записать 15 мег., мои дисковые массивы при direct random write при 4кб записях показывают от 0.5 до 15 мег/сек (меряю iozone), поэтому легко можно и 30 секунд писать на дешевом массиве с маленьким кэшем на запись. к сожалению все на локальных FC дисках. Возможности поработать с RAID-ом нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2006, 19:48 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
Журавлев ДенисИ еще: предположим во время чекпоинта надо записать 15 мег., мои дисковые массивы при direct random write при 4кб записях показывают от 0.5 до 15 мег/сек (меряю iozone), поэтому легко можно и 30 секунд писать на дешевом массиве с маленьким кэшем на запись. А какое железо с операционкой? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2006, 19:50 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
cpr Журавлев ДенисИ еще: предположим во время чекпоинта надо записать 15 мег., мои дисковые массивы при direct random write при 4кб записях показывают от 0.5 до 15 мег/сек (меряю iozone), поэтому легко можно и 30 секунд писать на дешевом массиве с маленьким кэшем на запись. А какое железо с операционкой?Да разное железо (и p4 с win и parisc с hpux (у меня несколько SAN сетей)), я же про внешние фиберченал дисковые массивы, с кэшами на запись и батарейками. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2006, 10:02 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
Если обратится к документации и почитать про чекпоинты то увидим: 1. Ждать можно на 1-м шаге выход пользовательских нитей из крит. секции (иногда очень долго 10-20-30 мин. :). 2. Ждать можно сброса буферов на шаге 4, с медленными дисками ждать можно долго. Это можно разрулить либо перейдя на LRUwrites LRU_MAX_DIRTY 0.5; либо перейти на собственный чекпоинт CKPTINTVL 9999, в цикле onmode -B&&onmode -C пауза 10 мин. onmode -B -- сброс буферов (нити не блокирует). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2006, 10:29 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
cpr АлексанДобрый день всем. На Вашем сервере слишком малое количество LRU-очередей и они, как следуствие, слишком длинные. Просто просканировать такие очереди занимает время! Кроме того, число клинеров в несколько раз меньше числа чанков. Мне кажется, полегчает, если Вы увеличите количество LRU-очередей хотя бы до 63 (а лучше до 128, тем более что это ничего не стоит) и количество клинеров увеличите до того же числа (ресурсов они не занимают, поскольку эти нити существуют только во время их работы). Эти действия также уменьшат конкуренцию за сами LRU-очереди, если у Вас достаточно много конкурентных пользовательских сессий. ------- С уважением, Александр Спирин Вообще то в настоящий момент 34 очереди и никакой разницы с 8-ю. ИМХО механизм скана LRU у Informix сделан оптимально. Конфигурационый файл вашего сервера относится к 2003 году, и в нём указано 8 очередей. Не предоставите ли Вы свежий выход onstat -a ? Статистика sar -d может подтвердить ваше предположение о недостаточной дисковой подсистеме. ------- С уважением, Александр Спирин ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2006, 10:33 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
cprВообще то в настоящий момент 34 очереди и никакой разницы с 8-ю. ИМХО механизм скана LRU у Informix сделан оптимально. Откуда разница, если механизм LRU writes не работает? По крайней мере он не работал 3 года назад, когда LRU_MAX_DIRTY/LRU_MIN_DIRTY были 60/50 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2006, 14:16 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис Madison Pruet onmode -B does not flush the pages from the buffer pool. It simply writes dirty pages to disk. The page still remains in the buffer pool. onmode -B is probably a much better solution to the long checkpoint issue than using very low LRU values because it uses chunk writes rather than LRU writes. Ранее не видел такого ясного определения и даже сделал FAQ: "Для чего нужен onmode -B - недокументированный ключ стандартной утилиты ?" http://www.sql.ru/faq/faq_topic.aspx?fid=646 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2006, 16:42 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
vasilisРанее не видел такого ясного определения и даже сделал FAQ: Наверно Мэдисон автор фичи, недавно он вообще предположил возможность реализации неблокирующего чекпоинта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2006, 17:22 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
Тан cprВообще то в настоящий момент 34 очереди и никакой разницы с 8-ю. ИМХО механизм скана LRU у Informix сделан оптимально. Откуда разница, если механизм LRU writes не работает? По крайней мере он не работал 3 года назад, когда LRU_MAX_DIRTY/LRU_MIN_DIRTY были 60/50 сейчас LRU_MAX_DIRTY/LRU_MIN_DIRTY были 1/0 вот он то сейчас и работает ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2006, 15:52 |
|
||
|
|
start [/forum/topic.php?fid=44&msg=33989343&tid=1608367]: |
0ms |
get settings: |
7ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
47ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
41ms |
get tp. blocked users: |
1ms |
| others: | 214ms |
| total: | 333ms |
| 0 / 0 |
