ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Informix [игнор отключен] [закрыт для гостей] / Длинный чек поинт
14 сообщений из 39, страница 2 из 2
  2  все
Длинный чек поинт
    #34759851
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
vasilis
onstat- KyRo
Можно ли сделать что бы приоритет доступа к дискам был у чек поинтов ?

Пусть на вам вопрос ответит тот кто ставил параметр NOFUZZYCKPT .
Подозреваю это были не Вы, если задаете этот вопрос.
Не вижу взаимосвязи.
И судя по всему, вы категорически отрицаете установку этого параметра (NOFUZZYCKPT) ?


Я большее предпочтение отдал бы режиму unbuffered logging нежели параметру NOFUZZYCKPT.

С проблемами падения серверов сталкивался, морочился с битыми фаловыми системами,
но informix на raw в режиме unbuffered logging поднимался всегда и безоговорочно.

vasilis
onstat-Правилный ответ нельзя,
Из этого ответа можно понять, что приоритета нет, но он есть :)


Приоритет то есть , но но изменять поведение checkpoint нельзя.
Или я что то забыл( или не знал ) ? :)

vasilis
onstat-
На основании чего устанавливались такие начения?
RA_PAGES 128 # Number of pages to attempt to read ahead
RA_THRESHOLD 64 # Number of pages left before next group

А что? Нормальные значения. И дальнейшие цифры показывают прекрасную эффективность таких значений.


А помоему (ИМХО) они явились результатом полумер связанных с плохим использованием
индексного поиска приложением.

Если бы это был настоящий DSS или OLAP об увеличенни виртульного сегмента
подумали бы гораздо раньше чем об упреждающем чтении, во всяком случае я бы подумал.

Подозреваю что параметры просто забыли вернуть в дефалтовые значения после постройки индексов.

Для меня чтобы убедиться в в эфективности упреждающего чтения слишком мало данных.

А как эффективность определяли Вы?


vasilis
onstat-
DBSPACETEMP tempdbs1 # Default temp dbspaces

Я бы обязательно добавил еще хотя бы один темповый спейс.


Мне кажется это сильно не поможет, так как основной dbspace всего один и pdq использовать не получится.
Нужно более детально смотреть на нагрузку на temp и добавлять если он является узким местом по ВВ, и при этом пользователей по разным темпакам разводить.


vasilis
Совершенно верно. Там ясно видно, что на время выполнения СР приостанавливаются все активные транзакции, кроме тех, которые находятся в критической части кода, ведущего текущий вв/выв (это вполне естественно для этой модели СР).
И длительные СР чаще всего не от объема работы самой СР, а говорят просто о том, что СР ожидает (находится в стадии ожидания) завершения критической части кода одной из транзакций.


Я все больше склоняюсь к мысли что данный длинный checkpoint в большей степени есть следствием ожидания критической части кода, нежели других факторов, но для установки истины необходим доступ к "телу" БД.
...
Рейтинг: 0 / 0
28.08.2007, 23:31
| Ответить | Цитировать | Написать  
Длинный чек поинт
    #34760480
Алексан
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексан
Участник
vasilis
Алексан
Какими бы большими мы эти параметры не ставили, сервер всё равно считывает за один раз не больше чем 32 страницы.
Если можно - ссылку на такое ограничение, которое я вижу впервые. Возможно, вы путаете с big buffer ?
IBM Informix Dynamic Server Advanced Performance Tuning Workshop,
Volume 1 of 1 Version 2 02-2002 000-8623 March 6, 2002, стр. 6-15:
"IDS divides read ahead values larger than 32 pages into 32 page requests.". Это не похоже на ограничение, это, в общем-то, его внутреннее дело, как выполнять команды... Получается, что увеличивая RA_-значения, можно получить только большие light scan-буфера, что не имеет смысла в OLTP-системах.

vasilis
Алексан
Подсистема ввода/вывода настроена не идеально:
RA_PAGES=128 и RA_THRESHOLD=64 - установите из в 32 и 30 соответственно и, после этого, мониторьте использование упреждающего чтения, сравнивая ixda-RA+idx-RA+da-RA и RA-pgsused из выхода onstat -p - они должны быть очень близки.
Дальнешие цифры показали прекрасную эффективность параметров (128 и 64). Так что не надо их уменьшать и уж тем более, до разницы в 2 страницы. Такие примеры (32 и 30) приводились для старых и медленных дисков, сейчас это неактуально. А что актуально?

vasilis
Алексан
Кроме того, SCSI-шина работает по принципу "один говорит - все молчат", поэтому пытаться ставить такое большое значение - значит наступать себе на хвост.
Если это эффективно, т.е. почти 100% считанных страниц будет использовано в дальнейшем, то какая разница ? Даже лучше, если мы "дернем" один раз, вместо двух.
Пока информикс будет считывать прозапас несколько десятков страниц, остальные несколько сотен приложения и сама операционная система будут ждать. "Лучшесть" не может быть определена здесь в рамках одного сервера баз данных.
...
Рейтинг: 0 / 0
29.08.2007, 10:47
| Ответить | Цитировать | Написать  
Длинный чек поинт
    #34760510
Алексан
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексан
Участник
onstat-
vasilis
onstat-
На основании чего устанавливались такие начения?
RA_PAGES 128 # Number of pages to attempt to read ahead
RA_THRESHOLD 64 # Number of pages left before next group

А что? Нормальные значения. И дальнейшие цифры показывают прекрасную эффективность таких значений.
А помоему (ИМХО) они явились результатом полумер связанных с плохим использованием
индексного поиска приложением.
Присоединяюсь.
...
Рейтинг: 0 / 0
29.08.2007, 10:55
| Ответить | Цитировать | Написать  
Длинный чек поинт
    #34760636
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
АнатоЛой
Участник
onstat-Нужно более детально смотреть на нагрузку на temp и добавлять если он является узким местом по ВВ, и при этом пользователей по разным темпакам разводить.

Э-э-э-э-э
Это как?

П.С.: Век живи - век учись
...
Рейтинг: 0 / 0
29.08.2007, 11:23
| Ответить | Цитировать | Написать  
Длинный чек поинт
    #34760650
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
АнатоЛой
Участник
Точнее, я хотел сказать: "Это как же пользователей по разным темпакам разводить?"
...
Рейтинг: 0 / 0
29.08.2007, 11:26
| Ответить | Цитировать | Написать  
Длинный чек поинт
    #34760785
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vasilis
Участник
onstat-Я большее предпочтение отдал бы режиму unbuffered logging нежели параметру NOFUZZYCKPT.
Я тоже. Но мы то говорили о NOFUZZYCKPT для ЭТОГО случая. И я даже привел СВОИ доводы для конкретных ситуаций.
onstat-
vasilis
onstat-
На основании чего устанавливались такие начения?
RA_PAGES 128 # Number of pages to attempt to read ahead
RA_THRESHOLD 64 # Number of pages left before next group

А что? Нормальные значения. И дальнейшие цифры показывают прекрасную эффективность таких значений.

А помоему (ИМХО) они явились результатом полумер связанных с плохим использованием
индексного поиска приложением.

Вы хотите сказать, что в других системах эти параметры не дадут такой эффективности ?
Все, что я видел - давали, не менее 95%. Во первых, использование индексов двлеко не всегда эффективно и оптимизатор это прекрасно знает, во-вторых - движок достаточно умный и использует Read Ahead только в тех случаях, когда это необходимо, а не в любом случае чтения.
onstat-
Если бы это был настоящий DSS или OLAP об увеличенни виртульного сегмента
подумали бы гораздо раньше чем об упреждающем чтении, во всяком случае я бы подумал.

Ну при чем здесь одно и другое ? Вы все время пытаетесь перескочить с одной темы на другую.
И все время пытаетесь доказать что "лучше быть богатым и здоровым, чем бедным и больным" :))
onstat-
Для меня чтобы убедиться в в эфективности упреждающего чтения слишком мало данных.
А как эффективность определяли Вы?
По букварю.
У меня в запросах это выглядит так
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
-- Read Ahead Utilization: (RApgsused / (ixdaRA + idxRA + daRA)) * 100
        ,round((select value from sysprofile where name='rapgs_used')/
                ((select value from sysprofile where name='btradata')
                 +(select value from sysprofile where name='btraidx')
                 +(select value from sysprofile where name='dpra')
                )* 100 , 2 )                                                __ra_effectiv
  ,sh_rapages           ra_pages
  ,sh_rathreshold       ra_threshold
        ,(select value from sysprofile where name='rapgs_used')         ra_pages_used
-- Какой % от общего числа прочитанных страниц с диска был прочитан по RA --
        ,round(((select value from sysprofile where name='btradata')
                 +(select value from sysprofile where name='btraidx')
                 +(select value from sysprofile where name='dpra'))/
               (select value from sysprofile where name='pagreads')* 100 , 2 ) _RA_pread_ratio
onstat-
vasilis
Я бы обязательно добавил еще хотя бы один темповый спейс.

Мне кажется это сильно не поможет, так как основной dbspace всего один и pdq использовать не получится.

А при чем здесь PDQ ? При записи (а потом и чтении) временных таблиц и файлов сортировки сервер всегда распараллеливает операции на количество временных спейсов без всяких параметров PDQ. Давние опыты показывали неплохой прирост производительности даже на одном физическом диске.
...
Рейтинг: 0 / 0
29.08.2007, 11:55
| Ответить | Цитировать | Написать  
Длинный чек поинт
    #34760940
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vasilis
Участник
Алексан vasilis
Алексан
Какими бы большими мы эти параметры не ставили, сервер всё равно считывает за один раз не больше чем 32 страницы.
Если можно - ссылку на такое ограничение, которое я вижу впервые. Возможно, вы путаете с big buffer ?
IBM Informix Dynamic Server Advanced Performance Tuning Workshop,
Volume 1 of 1 Version 2 02-2002 000-8623 March 6, 2002, стр. 6-15:

К сожалению, доступа к таким документам у меня нет.
Алексан
"IDS divides read ahead values larger than 32 pages into 32 page requests.". Это не похоже на ограничение, это, в общем-то, его внутреннее дело, как выполнять команды... Получается, что увеличивая RA_-значения, можно получить только большие light scan-буфера, что не имеет смысла в OLTP-системах.

Я бы уточнил, в ЧИСТЫХ OLTP-системах. А чистыми они бывают очень редко.
Алексан
А что актуально?

Актуальна производительность конкретной системы и эффективность параметров, если ее можно измерить.
В любом случае, чтобы не скатиться в "философские споры" :) советую всем, кто точно не знает, как влияет RA на производительность системы, использовать дефолтовые настройки (хуже не будет). Другие могут поэкспериментировать с обязательным замером результатов.
Сам я, обычно, всегда увеличиваю дефолтовые настройки, как минимум, до 64 48 и еще не разу не видел неэффективность таких параметров.
...
Рейтинг: 0 / 0
29.08.2007, 12:27
| Ответить | Цитировать | Написать  
Длинный чек поинт
    #34760946
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vasilis
Участник
АнатоЛойТочнее, я хотел сказать: "Это как же пользователей по разным темпакам разводить?"
по моему, это , мягко говоря, не здравая идея :)
...
Рейтинг: 0 / 0
29.08.2007, 12:29
| Ответить | Цитировать | Написать  
Длинный чек поинт
    #34761860
Фотография Andron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andron
Участник
vasilis
Сам я, обычно, всегда увеличиваю дефолтовые настройки, как минимум, до 64 48 и еще не разу не видел неэффективность таких параметров.

Если почитать документацию то эти значения можно будет смело увеличить как минимум в разы если не десятки раз ... Ну а эффективность ReadAhead можно оценить не прибегая к хитрым запросам, достаточно посмотреть вывод команды onstat -p (после некоторого времени работы сервера под нагрузкой, чтобы статистические данные накопились), т.е. сравнить сумму значений полей ixda-RA idx-RA da-RA с значением RA-pgsused - если они примерно одинаковые то и эффективность хорошая.
...
Рейтинг: 0 / 0
29.08.2007, 15:20
| Ответить | Цитировать | Написать  
Длинный чек поинт
    #34764766
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vasilis
Участник
Andron
Ну а эффективность ReadAhead можно оценить не прибегая к хитрым запросам, достаточно посмотреть вывод команды onstat -p (после некоторого времени работы сервера под нагрузкой, чтобы статистические данные накопились), т.е. сравнить сумму значений полей ixda-RA idx-RA da-RA с значением RA-pgsused - если они примерно одинаковые то и эффективность хорошая.
"хитрым запросам" это относится к тому, что я выше приводил ?
А что в нем хитрого ? Именно то же и делает, о чем вы говорите. У меня просто плохо получается в уме складывать семизначные цифры - пусть комп их сложит и выдаст оценку не "примерно одинаковые", а точный процент эффективности.
...
Рейтинг: 0 / 0
30.08.2007, 14:45
| Ответить | Цитировать | Написать  
Длинный чек поинт
    #34948786
KyRo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KyRo
Участник
Всем добрый день.
Долго не получалось отловить этот самый чек поинт и все же споймал .

При создании бекапа в оживленное время сразу же возник ! При этом на консоль вывода и в лог системы поссыпались следующие сообщения !
автор
ov 19 10:55:34 ix1 kernel: post_create: setxattr failed, rc=28 (dev=dm-0 ino=853016)
Nov 19 10:55:34 ix1 kernel: post_create: setxattr failed, rc=28 (dev=dm-0 ino=853020)
Nov 19 10:55:38 ix1 kernel: post_create: setxattr failed, rc=28 (dev=dm-0 ino=853016)
Nov 19 10:55:38 ix1 kernel: post_create: setxattr failed, rc=28 (dev=dm-0 ino=853020)
Nov 19 10:55:38 ix1 kernel: post_create: setxattr failed, rc=28 (dev=dm-0 ino=853021)
Nov 19 10:55:38 ix1 kernel: post_create: setxattr failed, rc=28 (dev=dm-0 ino=853022)
Nov 19 10:55:38 ix1 kernel: post_create: setxattr failed, rc=28 (dev=dm-0 ino=853023)
Nov 19 10:55:38 ix1 kernel: post_create: setxattr failed, rc=28 (dev=dm-0 ino=853024)


Как я понимаю это действительно какой то конфликт подсистемы ввода вывода , но вот какой и как его устранить пока что не знаю.

Вот на всякий случай выкладываю вам выгрузки сделаные во время зависания чек поинта.
автор
onstat -a
sar 3 3
ipcs -a

Выгрузка onstat -a урезана из за размеров если что то лишнее обрезал пишите , я буду выкладывать .

Посмотрите мож вы что подскажите !
...
Рейтинг: 0 / 0
19.11.2007, 13:34
| Ответить | Цитировать | Написать  
Длинный чек поинт
    #34949433
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
KyRoВсем добрый день.
Долго не получалось отловить этот самый чек поинт и все же споймал .

При создании бекапа в оживленное время сразу же возник ! При этом на консоль вывода и в лог системы поссыпались следующие сообщения !


Посмотрите мож вы что подскажите !

Ааааа.... знаем , плавали, у меня на этом приложении informix или жутко тормозил ( system CPU > 90% ) или падал
раз в 3 дня при попытке какой либо сессии вызвать функцию по не существующему указателю.
Все излечилось само собой после изучения принципов работы манагера виртуальной памяти
LInux и перевода informix на настоящие raw ( у которых первая буква 'c' в выводе ls -al )
Linux ядро было 2.4.9 ( кажись) база 9.40 UC4 .

В моем случае база общалась с линками и мне достаточно было пересоздать линки
на /dev/raw/rawXX, предварительно вызвав соответствующий набор команд raw , для мапинга девайсов.
В Вашем же случае незнаю что делать, так как девайсы подключены напрямую к базе.

Что касается упреждающего чтения на этой OLTP базе, оно здесь только вредит,
так как на таблицах authorizations & authorizext & groups построены толстые сложные индексы,
и при попытке чтения этих индексов с упреждением, из беферов будут вытесненные
более нужные в данный момент обьекты.
В общем случае упреждающее чтение индексов полностью сводит на нет повышение селективности использования сложных индексов за счет повышения обьема ввода вывода
упреждающим чтением.

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


Если есть вопросы задавайте в личку, правда informix версия сейчас отсутствует,
а юзается оракловая версия данного приложения .
...
Рейтинг: 0 / 0
19.11.2007, 16:22
| Ответить | Цитировать | Написать  
Длинный чек поинт
    #34958978
KyRo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KyRo
Участник
onstat-
Если есть вопросы задавайте в личку, правда informix версия сейчас отсутствует,
а юзается оракловая версия данного приложения .


А как хдесь писать в личку ? Я что то не могу найти !
...
Рейтинг: 0 / 0
22.11.2007, 16:22
| Ответить | Цитировать | Написать  
Длинный чек поинт
    #34959360
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
KyRo onstat-
Если есть вопросы задавайте в личку, правда informix версия сейчас отсутствует,
а юзается оракловая версия данного приложения .


А как хдесь писать в личку ? Я что то не могу найти !

Имелось ввиду что у меня в профиле есть e-mail,
туда можно писать.
...
Рейтинг: 0 / 0
22.11.2007, 17:48
| Ответить | Цитировать | Написать  
14 сообщений из 39, страница 2 из 2
  2  все
Форумы / Informix [игнор отключен] [закрыт для гостей] / Длинный чек поинт
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]