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

[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 Мб, памяти приходится накидывать десятками Гб. Доработка напильником, до какой-то степени помагает, но опять таки, действует "средняя температура по больнице". Т.е. все через код, то настройки кэширования одинаковые для всех серверов. И память все равно пожирается ненужными кэшами.
В принципе, согласен что оффтоп.