Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Caché, Ensemble, DeepSee, MiniM, IRIS, GT.M Новый топик    Ответить
 Утилита ^BLKCOL и другие  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 731
Добрый день, уважаемые форумчане.
Хотелось бы понять, утилита ^BLKCOL позволяет выяснить узкие места в пользовательском программном коде, или в настройках сервера Каше (балансировка памяти и другое)...
Результаты, выдаваемые утилитой, заставляют задуматься, но пищи для размышлений маловато... Отсутствие методик от производителя Каше еще больше мозги кипятит..! А все мануалы в основном направлены на то, чтобы дать возможность получить результаты того, или иного мониторинга... Но что делать с этими результатами, как на них реагировать - ни слова...
Наверняка, у них самих есть лаборатория, персонал, методики, которые позволяют проводить различные нагрузочные тесты, ну или тесты достижения целей, которые позволяют принимать решения о том, что цели достигнуты, производительность улучшена и т.п. Так почему бы не поделиться с нами хотя бы основными моментами оценки результатов мониторинга, чтобы по этим результатам можно было наметить план мероприятий по достижению наших собственных целей, в первую очередь увеличения производительности, ну и других показателей...

Прошу откликнуться тех, кто серьезно занимался данными вопросами, оптимизацией настроек, балансировкой.
Заранее благодарен всем откликнувшимся, думаю что будет интересно почитать очень многим.

P.S. Очень жаль, что в нашем региональном представительстве отсутствует такая лаборатория, которая бы занималась поднятой тематикой, публиковала периодические отчеты, методики, рекомендации...
8 июн 17, 16:44    [20550803]     Ответить | Цитировать Сообщить модератору
 Re: Утилита ^BLKCOL и другие  [new]
DAiMor
Member

Откуда: Volzhsky -> Moscow -> CZ, Brno
Сообщений: 2428
Я занимался поиском узких мест, с целью оптимизировать приложение для ускорения работы.
Если перед началом оптимизации, приложение работало со средним откликом 18секунд на небольшой базе уже не помню предполоим в 200Mb и 100 пользователей. До получения среднего отклика в 5-8 сек на базе в несколько терабайт и несколько тыс конкурентных пользователей.

Если честно, то ни разу не пользовался BLKCOL, но пользовался разными профилировщиками кода, в основном это помогло. Так же для мониторинга производительности а так же расследования разных проблем работает постоянно ^mgstat, логи которого кстати тоже хорошо помогли в решении проблем производительности.

Профилирование наверно самый простой способ найти проблемы с произвоительсностью. Тут можно начать по разному. Например если известны определенные операции, которые работают медленно, и есть большое желание их ускорить. Легко воспроизводимо, значит можно легко запустить под тотальным наблюдением. Тогда нужно запустить тотально профилировщик но на конкретный процесс, который эту задачу выполняет. Это сильно замедлит работу. Но в результате можно примерно получить общую картину, где сколько кода выполняется, и сколько раз выполняется, дальше глубокий анализ о необходимости такого количества выполнений кода. Плюс можно увидеть, сколько чтений данных пришлось на физическую работу диска. если что-то непонятно в помогает еще трассировка (выполняется только в терминале), можно получить бооольшой лог полного построчного выполнения, и понять последовательность выполнения кода, и нужна ли она такая.

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

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

следить за буфером глобалов, он не должен использоваться на 100%, иначе это будет означать что кеш постоянно вымывается. И опять же есть возможность следить за тем, а что в кеше вообще хранится. и надо ли оно там вообще в таких объемах. В некоторых случаях может стоит перейти на локальные переменные. На памяти вообще не стоит сильно экономить. у нас были системы объемом памяти от 32 до 512GB

Вообще очень много вариантов как узнать что медленно и как это изменить, для всего этого нужен мониторинг. и глубокий анализ всех логов начиная с cconsole.log лога журналирования mgstat и прочих. и даже pButtons всего не соберет что надо, но анализ того что он собрал тоже может помочь.
8 июн 17, 17:18    [20550955]     Ответить | Цитировать Сообщить модератору
 Re: Утилита ^BLKCOL и другие  [new]
DAiMor
Member

Откуда: Volzhsky -> Moscow -> CZ, Brno
Сообщений: 2428
Я уже немного уже подзабыл, но примерно помню что да как анализировать.

если хотите, думаю могу помочь на досуге.
8 июн 17, 17:20    [20550961]     Ответить | Цитировать Сообщить модератору
 Re: Утилита ^BLKCOL и другие  [new]
DAiMor
Member

Откуда: Volzhsky -> Moscow -> CZ, Brno
Сообщений: 2428
Практически на всех школах InterSystems в москве да и на саммите, постоянно проходят сессии по производительности, в основном ведет их Антон Умников, что у нас что на саммите. очень полезно
8 июн 17, 17:22    [20550972]     Ответить | Цитировать Сообщить модератору
 Re: Утилита ^BLKCOL и другие  [new]
Alexey Maslov
Member

Откуда: СПб
Сообщений: 1433
DAiMor
следить за буфером глобалов, он не должен использоваться на 100%
Если суммарный размер баз данных >> размера кэша глобалов, он скорее всего будет использоваться на 100%. Хорошо, если при этом RdRation остаётся в разумных пределах (>1000). Если кэш (месяцами) занят не на 100%, то это означает, что мы держим всю БД (точнее, её рабочее подмножество) в памяти; наверное, такое бывает, но я не видел :) Даже если предположить, что рабочее подмножество в какой-то момент влезает в кэш, то оно со временем меняется, и если система месяцами не перезагружается, постепенно будет использован весь кэш: Cache' никогда не вычеркнет буфер из кэша, пока есть свободные буферы; принцип устаревания буферов простой - FIFO. Можно, конечно, представить, что некто, имея БД размером 64GB, отвёл под кэш 96GB, но тогда вопрос: зачем он это сделал?

Серия основательных статей по планированию мощностей и анализу производительности связки СУБД/ОС/ВМ|железо публикуется на community. По оптимизации кода статей не так много, было на хабре по работу с %SYS.MONLBL.
8 июн 17, 19:36    [20551333]     Ответить | Цитировать Сообщить модератору
 Re: Утилита ^BLKCOL и другие  [new]
DAiMor
Member

Откуда: Volzhsky -> Moscow -> CZ, Brno
Сообщений: 2428
Alexey Maslov
Если суммарный размер баз данных >> размера кэша глобалов, он скорее всего будет использоваться на 100%
Только если за время работы кому то понадобится прочитать все данные в базе данных, тогда заполнится. А в нормальной ситуации больше всего данных пишется в базу чтобы быть прочитанными только в ближайшее время. Из практики системы с базами в несколько терабайт и буфером глобала в 256Gb были наполнены на 50% при работе больше месяца. Так что, все зависит от того что попадает в буфер. Он может быть долго не быть заполнен на 100%. Были случаи когда я уменьшал размер буфера глобала, когда видел что необходимости в таком объеме нут и на протяжении нескольких месяцев работы он не достигал 80 % использования. Хотя рост базы в то же время состовлял больше чем объем буфера.
9 июн 17, 00:27    [20551772]     Ответить | Цитировать Сообщить модератору
 Re: Утилита ^BLKCOL и другие  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 731
Спасибо ответившим!
Вижу, что в очередной раз затронул интересную и близкую сердцу для многих тему...
Утилита ^BLKCOL позволяет наблюдать коллизии доступа различных процессов к блокам данным, вероятно и к блокам индексов, глобалов. Насколько я понимаю, такие коллизии приводят к тому, что процесс, требующий доступа и которому отказано, притормаживается, аж пока блок не станет свободным. При этом, совсем не факт, что такой блок отсутствует в буфере глобалов. Почему я пришел к такому выводу..? Утилита ^BLKCOL показывает, что у меня коллизии возникают к одним и тем же блокам, два блока, в этих блоках размещены данные двух разных глобалов, да еще и расположенных в разных базах. При этом, сами по себе глобалы невелики, занимают около 30-60 8К буферов(в буфере глобалов, да и в самой базе они невелики), по сравнению с остальными, которые занимают сотни тысяч и миллионы блоков, об этом мне говорит утилита ^GLOBUFF. Показательно то, что такая ситуация возникает на трех разных серверах с полностью аналогичным ПО, отличие только в данных. Один из этих серверов показывает, что в буфере глобалов занято менее 30% выделенных блоков и не растет. Два других сервера показывают, что свободных блоков довольно таки мало, менее 1%, но все таки, требуемые мне глобалы могли бы быть размещены в свободных блоках полностью и еще место осталось бы. Отсюда вывод, что коллизии наступают не от того, что блоки подкачиваются с диска.
Работа с этими глобалами организована таким способом, что они являются синхронизирующими для целого ряда процессов, т.е. процессы анализируют их содержимое и принимают решение, продолжить дальше свою работу, или отложить до следующего раза. Таким образом, содержимое этих глобалов очень динамично, постоянно создаются и удаляются определенные узлы и ветви различными процессами и каждый из них анализирует состояние узлов и ветвей остальных равноценных процессов. В целях повышения быстродействия синхронизация выполняется без использования команд блокировки, хотелось уменьшить накладные расходы. И тут напрашивается новый вывод, пока некий процесс удаляет свою ветвь глобала, другие, которые пытаются создать свои ветви в этом же глобале, притормаживаются, чтобы дать возможность выровнять содержимое буфера, в котором происходит удаление. Таким образом, пытаясь увеличить быстродействие каждого из конкурирующих процессов на этапе арбитража, я невольно придавливаю такое быстродействие. Сразу же скажу, что это не могут быть локальные переменные, поскольку к ним должен быть доступ от множества процессов, я не могу размещать такие глобалы в ТЕМПОВЫХ глобалах, по ряду причин...
Что еще могу сказать, к таким выводам я прихожу "при наличия отсутствия" соответствующих методик от производителя Каше, а также "при наличия отсутствия" более "глубоких" мануалов, раскрывающих "темные стороны" Каше.
Я уже не говорю о том, что много информации можно почерпнуть с различных индикаторов Портала и по результатам работы системных утилит. При этом в документации очень много сказано как получить такую информацию, но ни слова о том, как ею пользоваться, какие делать выводы... То что на различных конференциях кто-то делится опытом конечно же хорошо, но все это не серьезно со стороны производителя Каше. Да и не все могут присутствовать на подобных конференциях, освещается все в быстром темпе... А если захочется поговорить с докладчиком лично, то надо очень спешить, иначе его уведут пить пиво более шустрые коллеги... Это все напоминает передачу "Очумелые ручки", ну или подробные описания в журнале Радио, как из корпуса и деталей карманного приемника собрать миниатюрный кассетный магнитофон.

Вот и хотелось бы хоть каких то подвижек со стороны производителя в эту сторону...
Или хотя бы на добровольных началах, в рамках этого форума, или чего либо, стоит нашему сообществу задуматься над порождением неких методик, раз производителю Каше такие вопросы "до лампочки", которые кстати отбивают потенциальных заказчиков от технологий Интерсистемс.

P.S. Даже на рулонах туалетной бумаги бывают иногда очень подробные инструкции по эксплуатации.
9 июн 17, 09:23    [20551984]     Ответить | Цитировать Сообщить модератору
 Re: Утилита ^BLKCOL и другие  [new]
DAiMor
Member

Откуда: Volzhsky -> Moscow -> CZ, Brno
Сообщений: 2428
AlexKB
Работа с этими глобалами организована таким способом, что они являются синхронизирующими для целого ряда процессов, т.е. процессы анализируют их содержимое и принимают решение, продолжить дальше свою работу, или отложить до следующего раза. Таким образом, содержимое этих глобалов очень динамично, постоянно создаются и удаляются определенные узлы и ветви различными процессами и каждый из них анализирует состояние узлов и ветвей остальных равноценных процессов. В целях повышения быстродействия синхронизация выполняется без использования команд блокировки, хотелось уменьшить накладные расходы.
Вот на этом месте поподробнее, как выделяются индексы новых узлов? Отказ от явных команд блокировки не означает полный отказ от них. Есть еще атомарные операции которые используют блокировки. Вот статья, думаю будет полезно.

По поводу того что InterSystems "плохо это задокументрировал". Честно не знаю что сказать, все познается в сравнении а мне не с чем сравнивать, у других (MSSQL, Oracle, Mongo и прочие) все хорошо так подробно расписано? В большинстве случаев мне кажется такой контент производится сообществом - потребителей, возможно и не без помощи вендора. Можно и нужно писать статьи об этом, кто что знает, как боролся (правда, где найти время на это :D). Можно попробовать написать совместно одну большую статью сразу нескольким людям, благо сейчас хватает технологий для этого. Так и на книгу может набраться.
9 июн 17, 09:42    [20552017]     Ответить | Цитировать Сообщить модератору
 Re: Утилита ^BLKCOL и другие  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 731
DAiMor,
Да, я знаю что $increment выполняет неявную блокировку и я использую эту функцию в данном случае, но использование Lock будет еще расточительнее, мне нужно отыгрывать микросекунды...
А вот $Sequence мне совсем не подойдет в данном случае, мне не нужны уникальные индексы, мне нужны инкрементно-декрементные индексы со строгим шагом в единицу, а также нужны следящие счетчики, сколько в данный момент процессов выполняет именно такую работу и можно ли разрешить еще одному процессу выполнять аналогичную работу, а если нет, то пусть он как можно скорее покинет систему и не мешает другим...
9 июн 17, 09:55    [20552055]     Ответить | Цитировать Сообщить модератору
 Re: Утилита ^BLKCOL и другие  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 731
DAiMor,
Мне также абсолютно все равно, чем там "пахнет в туалете" у MSSQL, Oracle и других.
Мне очень хочется чтобы у Интерсистемс было лучше всех!

А то что системы документируются таким образом, как я мечтаю - уж поверьте, что были такие и я с ними сталкивался!
Еще в старые Брежневско-Горбачевские времена системы с отличным документированием реально "ложили на лопатки" произведенные в крупных научных центрах(Новосибирские, Зеленоградские, ленинградские и даже из Арзамаса-16), хотя и сами были произведены в Киргизии. (это так, к слову...)

Может что-то типа энциклопедии собирать надо... Опять же, как это все модерировать... Кто-то может накидать туда необъективной информации, а народ возьмет это на вооружение...
Вот если бы исследовательские лаборатории, спонсируемые Интерсистемс, проводили такие исследования и выдавали периодические отчеты о своей деятельности. Думается что пользы от таких финансовых затрат было бы больше чем от различных рекламных акций, которые тоже стоят не малых денег... Хотя, не мне об этом судить, наверное...
9 июн 17, 10:07    [20552100]     Ответить | Цитировать Сообщить модератору
 Re: Утилита ^BLKCOL и другие  [new]
DAiMor
Member

Откуда: Volzhsky -> Moscow -> CZ, Brno
Сообщений: 2428
AlexKB
DAiMor,
Да, я знаю что $increment выполняет неявную блокировку и я использую эту функцию в данном случае, но использование Lock будет еще расточительнее, мне нужно отыгрывать микросекунды...
А вот $Sequence мне совсем не подойдет в данном случае, мне не нужны уникальные индексы, мне нужны инкрементно-декрементные индексы со строгим шагом в единицу, а также нужны следящие счетчики, сколько в данный момент процессов выполняет именно такую работу и можно ли разрешить еще одному процессу выполнять аналогичную работу, а если нет, то пусть он как можно скорее покинет систему и не мешает другим...
Если я правильно понял то у вас что-то типа
$i(^Global("JobName"))
Если так, то почему бы не поменять на
$i(^GlobalJobName)
9 июн 17, 10:19    [20552136]     Ответить | Цитировать Сообщить модератору
 Re: Утилита ^BLKCOL и другие  [new]
DAiMor
Member

Откуда: Volzhsky -> Moscow -> CZ, Brno
Сообщений: 2428
AlexKB
Может что-то типа энциклопедии собирать надо... Опять же, как это все модерировать..

Сейчас есть такая возможность делать это например на github. Все изменения делаются каждым в своем форке, любые дополнения в общую энциклопедию, через пулл реквесты, так они будут подтверждаться. Есть поддержка ревью, если что-то не так. Вот пример сгенерированной документации с репозитория на github
9 июн 17, 10:28    [20552163]     Ответить | Цитировать Сообщить модератору
 Re: Утилита ^BLKCOL и другие  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 731
DAiMor
Если я правильно понял то у вас что-то типа
$i(^Global("JobName"))
Если так, то почему бы не поменять на
$i(^GlobalJobName)


Что-то в этом направлении придется думать... Но это будет работа с коллекцией глобалов, заранее не определенных, состав глобалов будет динамичным, а это опять накладные расходы... Еще может подумаю в сторону семафоров и событий... Самое интересное, что ошибок то не возникает, просто случайно заметил, что такие участки иногда выполняются дольше, чем ожидалось, а это приводит к не совсем оптимальной балансировке... При этом, множество процессов одновременно работают с интенсивным использованием команд блокировки и инкрементов, но коллизий доступа к блокам у них не наблюдается... Поэтом я и решил, что у меня слишком уж высока динамика создания, чтения, удаления узлов и ветвей глобалов различными конкурирующими процессами в двух глобалах арбитража.

И еще мне не хватает информации - что конкретно мне говорят результаты работы утилиты ^BLKCOL и как воспользоваться такими результатами.

А по поводу Гитхаб - слишком уж там все заумно, скажем академично...
Хороший мануал нужно читать как и хорошую книгу, многократно перечитывая и каждый раз находя что-то новое. (Ильфа и Петрова, например, или картины Шишкина не устаю пересматривать десятки раз и всегда что-то новое нахожу.)
9 июн 17, 10:45    [20552221]     Ответить | Цитировать Сообщить модератору
 Re: Утилита ^BLKCOL и другие  [new]
Alexey Maslov
Member

Откуда: СПб
Сообщений: 1433
DAiMor
Если так, то почему бы не поменять на $i(^GlobalJobName)

Сложно советовать, не зная специфики: а вдруг процессов несколько сотен или тысяч? Распухание глобального каталога может аукнуться, т.к. в Каше он не является B*деревом.

Алексей, не факт, что внутренние коллизии, фиксируемые BLKCOL, являются причиной тормозов. Накладные расходы на них наверняка меньше, чем на LOCK. Да и не ясно пока, с чем ты борешься, кроме малопонятной выдачи BLKCOL? Соглашусь с Дмитрием, надо mgstat смотреть, может быть проблема например с диском (если демон записи подолгу сидит в фазах 5 и 8, значит диск перегружен работой).
9 июн 17, 15:50    [20553567]     Ответить | Цитировать Сообщить модератору
Все форумы / Caché, Ensemble, DeepSee, MiniM, IRIS, GT.M Ответить