Доброго дня! Лет 5 назад наша система жила со стандартными параметрами по памяти EM,HEAP и система давала около 2.5 гигов на диалоговый процесс. Большие отчеты падали в дамп, и я довел эти цифры до 10 гб.
Естественно, теперь все повторяется и люди снова жалуются что не могут выгрузить отчет, например по продажам за 2 года по всем БЕ. И вот теперь я думаю: объем памяти на сервере 100 гб, если 10 таких людей запустят по отчету - система встанет. Интересен опыт других компаний, что делать в таких случаях ? Дальше потакать растущим потребностям пользователей ? Но они ведь так могут повесить систему?
Спасибо!

переходите на HANA... до этого момента просто не успеет дойти

Не успет? Раньше что-ли упадет ?

Вы уже немного знаете HANA

расстрел на месте

Только массовые расстрелы... А серьезно:
1. Ограничить лимит административно, всех абаперов и консультантов, настраивающих выборки по звездочке, а не конкретных и необходимых данных слать лесом.
2. Если лесом послать не удалось (это стандартный код и не настраивается) - поставить рядом диалоговую инстанцию без ограничений и пускать на неё только избранных "счастливцев" которым достались такие транзакции. Так вы избежите переполнения памяти для всех сразу, если что отвалится только зачумленный сервер.

у нас какоето время практиковалось:
1) выгон пользователей с тяжёлыми отчётами на отдельную ноду, где настройки памяти иные, и народу толкётся меньше;
2) на критичные по ресурсам отчёты вешали программный контроль запуска - чтобы одновременно запускалось не более N экземпляров отчёта (N+1ому пользователю вместо отчёта по F8 выдавалось сообщение со списком логинов счастливцев, которые успели ... чтобы он их через SU01D мог обзвонить, встать в очередь, "мне только спросить" и проч. )

ну ещё ессно борьба с абаперами, злоупотребляющими FOR ALL ENTRIES IN itab[] без обёртки IF itab[] IS NOT INITIAL.

А расскажите пожалуйста, подобный контроль - это Z, или есть какой-то встроенный функционал платформы ?

Контроль использования памяти - ручной. Обычно просмотр дампов. Как правило их не много. Консультанты узкие места по своим направлениям знают. Дальше нужному пользователю подсовывается саплогон с правильной логон группой либо даются полномочия на смену сервера.
Контроль использования безлимитных инстанций пока не требовался (не было случаев тотального переполнения памяти). Обычно пользователи сами с сервера на сервера не перескакивают (sm51 еще надо заслужить) и саплогон себе не правят, белые списки делать не приходилось. Если понадобится, то можно закрывать на инстанциях порты 32ХХ и 33ХХ или возможность редактирования саплогонов политиками, запрещать запуск фоновых и т.д и т.п...

Это в ЕРП у вас такие жирные отчеты? За 2 года и по всем БЕ это прямой путь в биви или другие системы аналитической отчености, но никак не в транзакционную систему

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

совсем не обязательно отчеты. у нас выгрузка в 1С каких-то материалов иногда сожрав 9гиг падает. Просто потому что кто-то в САПе поменял признак сразу у всех материалов ,а выгрузка кривая.

нужно методично доносить до руководства что это неправильно когда 1 процесс в многопользовательской системе требует более 10% ресурсов. И, что наконец, напрячь абапера Васю дешевле чем докупить в сервер еще 100гиг памяти.

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