Поговорим о глобальных кэшах в Аксапте? Как правильно?

[Ivanhoe]

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

[Logger]

4. Таблетка для курсов валют
О сломанных шестеренках в большом моторе
Тоже кеш протухал

[mazzy]

а давайте про реестр в другой ветке?
реестр создавался - http://stopbugs.ru.
основная проблема как и с кэшами - информация очень быстро протухает. кто-то должен следить за актуальностью багов и таблеток. на общественных началах эту работу никто не готов тащить.

да... кэширование цен - это вручную используемый SysGlobalCache + кэширование на уровне таблиц EntireTable... адская смесь.

[fed]

Пожалуй отмечусь: На мой взгляд - единственная реальная проблема на внедрениях - это протухание кэша. Проблем с памятью и гипотетическим низким hit/miss ratio я не видел.
На мой взгляд, шагом вперед стала бы поддержка cache scope как некого прикладного объекта в AOD. И чтобы можно было бы где-то на уровне таблицы указывать, какие скопы надо очищать при изменении таблицы. Во всех случаях это не спасло бы, но для типичных ситуаций малость облегчило бы кодинг.

[Logger]

Цитата:

Сообщение от fed

Во всех случаях это не спасло бы, но для типичных ситуаций малость облегчило бы кодинг.

Интересно, а если предусмотреть вариант Global flush - т.е. очистка всех кешей - которые есть как в kernel так и определенных из X++ кода. - Будут от этого какие-нибудь риски или нет ?

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

Это было бы нужно прежде всего при работе 24/7 когда нужно подправить какие-то настройки или накатить код но не останавливая весь комплекс. 2009-я аксапта это позволяла. В 2012-й похоже от такого отказались, а жаль.

[Владимир Максимов]

Цитата:

Сообщение от Logger

Интересно, а если предусмотреть вариант Global flush - т.е. очистка всех кешей - которые есть как в kernel так и определенных из X++ кода. - Будут от этого какие-нибудь риски или нет ?

Конечно. Если будет обнулен кеш с результатами промежуточных расчетов в процессе этого самого расчета.

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

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

Единственный выход - не создавать глобальный кеш. Но это уже невозможно. Джина выпустили из бутылки

[mazzy]

Цитата:

Сообщение от Владимир Максимов

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

Ну, почему же? Это ж java. там счетчики ссылок есть.

если обнулить ссылку в глобальном кэше,
то сам объект не удалится, у него просто уменьшится счетчик ссылок.

те, объекты, у которых счетчик ссылок = 0, попадут в следующую итерацию сборщика мусора. там в процессе сборки мусора и будут удалены.

[Владимир Максимов]

Цитата:

Сообщение от mazzy

Ну, почему же? Это ж java. там счетчики ссылок есть.

Ссылка возникает в момент обращения. Но сама идея глобальных объектов в том и заключается, что обращение будет отложено.

Ну, например, процесс 1 сформировал глобальный объект и был завершен. А потом, спустя некоторое время, был запущено процесс 2, который как раз и обратился за данными глобального объекта.

Такое "отложенное" обращение счетчик ссылок не поймает. Просто нет ссылок на момент вычисления.

Причем не факт, что это просто кеш. Это может быть и промежуточные расчеты в какой-то сложной конфигурации классов

[macklakov]

Цитата:

Сообщение от fed

Проблем с памятью и гипотетическим низким hit/miss ratio я не видел.

У нас чуть меньше 50 AOS и 1500 пользователей через Citrix. Версия 2012 R2. Мы ловим все возможные проблемы с кэшем. Самые большие проблемы с табличным кэшированием. Таблица в лимит по памяти не умещатеся, свопится на диск. Приходится увеличивать лимит в несколько раз. И, как следствие, приходится на сервера в несколько раз больше памяти накидывать. Причем кэш сохраняется и на сервере и в клиентской сессии, т.е. апгрейдить приходится и AOS и клиентские сервера. Но это еще не все. Сервера между собой синхронизируют кэш по какому-то таинственному протоколу, из-за которого система может неожиданно начать подтормаживать и данные могут оказаться неактуальными.

[fed]

Цитата:

Сообщение от macklakov

У нас чуть меньше 50 AOS и 1500 пользователей через Citrix. Версия 2012 R2. Мы ловим все возможные проблемы с кэшем. Самые большие проблемы с табличным кэшированием. Таблица в лимит по памяти не умещатеся, свопится на диск. Приходится увеличивать лимит в несколько раз. И, как следствие, приходится на сервера в несколько раз больше памяти накидывать. Причем кэш сохраняется и на сервере и в клиентской сессии, т.е. апгрейдить приходится и AOS и клиентские сервера. Но это еще не все. Сервера между собой синхронизируют кэш по какому-то таинственному протоколу, из-за которого система может неожиданно начать подтормаживать и данные могут оказаться неактуальными.

А почему бы просто везде не заменить EntireTable Cache на FoundAndEmpty ? Не могу ни одного негативного последствия такого изменения придумать.
Я тоже время от времени на грабли с Entire Table cache с несколькими AOSами налетал, но я их там чинил тупо отрубая этот способ кэширования как таковой...
И по моему это малость оффтопик здесь. Все-таки тема про кэширование объектов, а не таблиц...

[macklakov]

Цитата:

Сообщение от fed

А почему бы просто везде не заменить EntireTable Cache на FoundAndEmpty ? Не могу ни одного негативного последствия такого изменения придумать.
Я тоже время от времени на грабли с Entire Table cache с несколькими AOSами налетал, но я их там чинил тупо отрубая этот способ кэширования как таковой...
И по моему это малость оффтопик здесь. Все-таки тема про кэширование объектов, а не таблиц...

Ну, в принципе, EntireTable кэширование для параметров может иметь смысл. Но, значительная часть из таблиц которые хотелось бы закэшировать, большие. Нужно увеличивать лимит памяти, чтобы влезли. А этим лимитом тут же пользуются таблицы, которые на этом сервере не очень-то и нужны в кэше. Т.е. для того, чтобы закэшировать целиком несколько таблиц, общим объемом в 100 Мб, памяти приходится накидывать десятками Гб. Доработка напильником, до какой-то степени помагает, но опять таки, действует "средняя температура по больнице". Т.е. все через код, то настройки кэширования одинаковые для всех серверов. И память все равно пожирается ненужными кэшами.
В принципе, согласен что оффтоп.

[dech]

Мне вот интересно, если SysGlobalCache используется в рамках сессии, а SysGlobalObjectCache - в рамках AOS-а, то как жить дальше, когда у меня имеется 2 AOS-а и мне нужно закэшировать что-то прям ваще глобальное?

[mazzy]

Цитата:

Сообщение от dech

то как жить дальше, когда у меня имеется 2 AOS-а и мне нужно закэшировать что-то прям ваще глобальное?

SysLastValue

[macklakov]

Цитата:

Сообщение от mazzy

что вы думаете о глобальном кэшировании в Аксапте?

музейный экспонат

Цитата:

Сообщение от mazzy

как правильно, на ваш взгляд кэшировать, а как неправильно?
что подлежит кэшированию, а что кэшировать ни в коем случае нельзя?

Сначала надо определиться, зачем вообще нужно кэширование?
Я могу предположить что цель это снизить количество обращений клиент-сервер. Тогда:

Цитата:

Сообщение от mazzy

что можно было бы сделать к кэшем в аксапте, чтобы упростить жизнь всех разработчиков, администраторов и пользователей? чтобы снизить вероятность ошибок, связанных с кэшированием?

Для начала, админам надо дать инструменты управления кэшем. У них должны быть инструменты собирать статистику отправляемых запросов, с точностью до AOS и с точностью до клиента. У них должны быть инструменты упраления кэшем через настройки, без необходимости менять исходники. Опять таки, в разрезе AOS. И у них дожны быть инструменты управления механизмом кэширования. Как минимум, принудительный сброс на выбранных серверах.
Почему в разрезе AOS? Потому что разные сервера обычно занимаются разными задачами. Одному нужна хорошо откэшированная ГК, а другому хорошо откэшированный склад. А не "средняя температура по больнице" как сейчас.
Еще не плохо бы эти настройки сделать экспортируемыми/импортируемыми. Тогда можно будет поднимать "событийные" настройки кэширования. К примеру, на закрытие склада или финансового периода, рассчеты сводного планирования и т.д.
Еще важный вопрос, это синхронизация кэша между серверами. Это отнюдь не тривиальная задача. И если у SQL админа есть куча инструментов по отлову блокировок и избавления от них, то в случае множественных AOS-ов, остается лишь скакать с бубном и приносить девственников в жертву, в попытке умилостивить сереверных духов.

[mazzy]

Цитата:

Сообщение от macklakov

с точностью до AOS и с точностью до клиента.

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

внешний инструмент с точностью до компа.
или не?

[macklakov]

Цитата:

Сообщение от mazzy

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

Не совсем. Идея в следующем. Часто AOS разделяют по функциям. Этот MRP считает, а этот всякие системные jobs гоняет, на этом сидят пользователи, а этот для интеграции. Делается это для того, чтобы снизить вероятность конкуренции за ресурсы. И пользователи с разными ролями обычно налегат на разные ресурсы. Поэтому хотелось бы управление кэшированием не из кода, а из настроек. Чтобы, собрав статистику, можно было перенастроить кэширование на конкретом AOS. Или для конекретного подмножества пользователей.
Почему это важно? Потому что, согласно опыту последних 6-ти лет, продуктовая команда имеет очень смутное представление о том, что нужно клиентам. И эта размытость образа происходит, опять таки, из-за средней температуры по больнице. Клиенты разные, им нужно разное. Причем хотелки имет свойство изменяться со временем. Разработчик просто не в состоянии определить как лучше будет откэшировать, т.к. он может лишь догадываться о том, какую топологию предпочтет клиент.
А вот админ, сопровождающий конкретного клиента, обычно точно знает где у него узкое место. Где и что надо откэшировать чтобы разгрузить конкретно вот этот канал и эти таблицы в базе данных.

[fed]

Цитата:

Сообщение от macklakov

Не совсем. Идея в следующем. Часто AOS разделяют по функциям. Этот MRP считает, а этот всякие системные jobs гоняет, на этом сидят пользователи, а этот для интеграции. Делается это для того, чтобы снизить вероятность конкуренции за ресурсы. И пользователи с разными ролями обычно налегат на разные ресурсы. Поэтому хотелось бы управление кэшированием не из кода, а из настроек. Чтобы, собрав статистику, можно было перенастроить кэширование на конкретом AOS. Или для конекретного подмножества пользователей.
Почему это важно? Потому что, согласно опыту последних 6-ти лет, продуктовая команда имеет очень смутное представление о том, что нужно клиентам. И эта размытость образа происходит, опять таки, из-за средней температуры по больнице. Клиенты разные, им нужно разное. Причем хотелки имет свойство изменяться со временем. Разработчик просто не в состоянии определить как лучше будет откэшировать, т.к. он может лишь догадываться о том, какую топологию предпочтет клиент.
А вот админ, сопровождающий конкретного клиента, обычно точно знает где у него узкое место. Где и что надо откэшировать чтобы разгрузить конкретно вот этот канал и эти таблицы в базе данных.

Во первых - более или менее кэширутся только настроечные и справочные таблицы. У всех более или менее крупных транзакционных таблиц (типа того же MRP), кэширование либо вообще выключено, либо установлено в NotInTTs (То есть - кэшироваться оно будет не с сервера, а только при просмотре клиентов).
Во вторых - ты не поверишь, но обычный LFU-алгоритм позволяет избавиться от табличных кэшей, которые не особо нужны на данном сервере. То есть - если у тебя нечаянно на MRPшном AOS закэшировались основные средства, то алгоритм LFU бодренько вытеснит эту информацию из памяти и заместит данными из групп покрытия например (в общем - той информацией которая часто и регулярно используется именно на данном конкретном AOS). Я просто не вижу чего тут может дать преднастройка того, какие именно таблицы кэшировать. Мелкие таблицы и так закэшируются, а крупные - скорее всего всерьез кэшировать просто нельзя, потому что они могут с множества разных AOS обновляться в рабочем режиме.

[macklakov]

Цитата:

Сообщение от fed

Во вторых - ты не поверишь, но обычный LFU-алгоритм позволяет избавиться от табличных кэшей, которые не особо нужны на данном сервере.

LFU не всегда так бодренько чистит как хотелось бы. Если MRP упирается в лимит по кэшу, то может и заклинить. Но самое главное, я очень не люблю когда мне по работе приходится полагаться на веру. А в случае с объектным кэшем приходится. Я могу лишь догадываться что там происходит. Я тупо не могу узнать, степень заполнения. Понять что система тормозит из-за хронического превышения лимита и что надо этот лимит подкрутить, весьма нетривиально бывает.

[ALES]

Цитата:

Сообщение от mazzy

что можно было бы сделать к кэшем в аксапте, чтобы упростить жизнь всех разработчиков, администраторов и пользователей? чтобы снизить вероятность ошибок, связанных с кэшированием?

автоматизировать "контроль версий\типов" для любых "сохраненных" данных

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

Освобожденные километрочасы типовых историй про "удалить кеши", рестартовать аос\сервер\вселенную и хоть как-то выявить сессии\объекты AOT "пожиратели ресурсов" хочется направить на что-то более полезное для счастливого обладателя лицензий

[mazzy]

Цитата:

Сообщение от ALES

запилить "деструктор" или как уже отмечалось выше хотя бы "анализатор" текущих "ресурсов".

деструктор, он же "сборщик мусора", имеет свою цену. и не маленькую.

анализатор - да.