SAPфорум.RU
https://www.sapboard.ru/forum/

Оптимизация использования памяти
https://www.sapboard.ru/forum/viewtopic.php?f=13&t=99788		 Страница 1 из 2
Автор:  ST [ Ср, окт 06 2021, 11:25 ]
Заголовок сообщения:  Оптимизация использования памяти
Коллеги, доброго дня!

Используем SAP BW 7.4 с огромным количеством одновременных загрузок/расчётов. Много где используются огромные таблицы с какими-то нужными дополнительными данными. Например, договора и контрагенты. Происходит следующее: запускается несколько расчётов по нескольким БЕ одновременно, и каждый из них выполняется отдельно по каждому месяцу. И везде нужны, скажем, договора. Таблица большая, и периодически её чтение из таблицы БД заканчивается дампом по нехватке памяти.
При этом сама таблица договоров внутри абапа никак не изменяется.

Хотелось бы считать её в память в каким-то одном месте, а затем использовать эти данные во всех параллельных процессах. Пробовали использовать SHMA, но без особого результата: всё равно таблицы читаются каждый раз в разные версии. Может быть, как-то не так настроили...

Подскажите, есть ли подобная возможность? Может, пример кода?
Автор:  Kengur [ Ср, окт 06 2021, 18:04 ]
Заголовок сообщения:  Re: Оптимизация использования памяти
Вариантов много. Самый простой - пакетная обработка в селекте. Изобретать что-то с распределенной памятью - как стрелять из плазмогана по воробьям.
Автор:  Удав [ Чт, окт 07 2021, 23:52 ]
Заголовок сообщения:  Re: Оптимизация использования памяти
ST написал(а):
Коллеги, доброго дня!

Используем SAP BW 7.4 с огромным количеством одновременных загрузок/расчётов. Много где используются огромные таблицы с какими-то нужными дополнительными данными. Например, договора и контрагенты. Происходит следующее: запускается несколько расчётов по нескольким БЕ одновременно, и каждый из них выполняется отдельно по каждому месяцу. И везде нужны, скажем, договора. Таблица большая, и периодически её чтение из таблицы БД заканчивается дампом по нехватке памяти.
При этом сама таблица договоров внутри абапа никак не изменяется.

Хотелось бы считать её в память в каким-то одном месте, а затем использовать эти данные во всех параллельных процессах. Пробовали использовать SHMA, но без особого результата: всё равно таблицы читаются каждый раз в разные версии. Может быть, как-то не так настроили...

Подскажите, есть ли подобная возможность? Может, пример кода?

Проблемы с памятью определяются через SAT.
У нас подобные проблемы с нехваткой памяти для процесса решались с помощью освобождения памяти временных внутренних таблиц. Кроме REFRESH нужно было делать FREE.
И да - нехватка памяти для процесса, или глобальной памяти?
Опять же - зачем для таблиц договоров и контрагентов читать все поля? :roll:
Автор:  jack_nsk [ Пн, окт 11 2021, 11:16 ]
Заголовок сообщения:  Re: Оптимизация использования памяти
подобное для большинства компаний скорее всего только после 2030 года?
Внутренние таблицы как источник в SQL запросах
Code:
Существует два сценария выполнения таких запросов:
    Для выполнения SQL запроса не требуется переноса содержимого внутренней таблицы на уровень СУБД. В таком случае обработка запроса осуществляется непосредственно на сервере приложений, по аналогии с табличным буфером.
    Для выполнения SQL запроса требуется перенести содержимое внутренней таблицы во временную таблицу на уровень СУБД. Этот сценарий поддерживается не всеми СУБД и чтобы статический анализ кода не ругался, следует использовать прагму: ##itab_db_select. При отсутствии поддержки система выдаст исключение в runtime — CX_SY_SQL_UNSUPPORTED_FEATURE.
Автор:  Parazit [ Ср, окт 13 2021, 14:34 ]
Заголовок сообщения:  Re: Оптимизация использования памяти
Не нужно читать таблицы по отдельности. Пишите сложные выборки с join и packed size. Open cursor with hold поможет сохранять данные порциями. В идеале из БД вы должны получать только необходимые данные, ничего лишнего. Если у вас много селектов с for all entries, это верный признак, что делаете что-то не так.
Разумеется, в борьбе за память потеряете в производительности - по другому и быть не должно.
Автор:  pberezin [ Пн, ноя 29 2021, 13:42 ]
Заголовок сообщения:  Re: Оптимизация использования памяти
Parazit написал:
Не нужно читать таблицы по отдельности. Пишите сложные выборки с join и packed size. Open cursor with hold поможет сохранять данные порциями. В идеале из БД вы должны получать только необходимые данные, ничего лишнего. Если у вас много селектов с for all entries, это верный признак, что делаете что-то не так.

Хм. А разве это не путь обратно в двухзвенку? Нагружая СУБД сложными джойнами (с километровыми планами выполнения) мы разве не садим общую производительность системы, ценой ускорения работы одного конкретного пользователя данного отчёта/транзакции?
Почемуто думал, что архаичная декомпозиция джойнов на отдельные операции с таблицами через сервер приложения и последующие абап-циклы "джойнов", это какраз то, чем исторически сильна сап-коробка. :?
Автор:  LKU [ Пн, ноя 29 2021, 13:48 ]
Заголовок сообщения:  Re: Оптимизация использования памяти
pberezin написал:
Хм. А разве это не путь обратно в двухзвенку? Нагружая СУБД сложными джойнами (с километровыми планами выполнения) мы разве не садим общую производительность системы, ценой ускорения работы одного конкретного пользователя данного отчёта/транзакции?
Почемуто думал, что архаичная декомпозиция джойнов на отдельные операции с таблицами через сервер приложения и последующие абап-циклы "джойнов", это какраз то, чем исторически сильна сап-коробка. :?

Ну да. Несколько десятилетий существования продуктов R/3 и ERP, SAP объяснял какие они молодцы, что при помощи абапа позволяют снять нагрузку с единой точки отказа (БД) за счет горизонтально масштабируемых серверов приложений. Потом с появлением HANA маятник качнулся и SAP стал объяснять какие они молодцы, что позволяют убрать лишний код из серверов приложений, перенести его в БД и тем самым уменьшить объем сетевого трафика.
Автор:  pberezin [ Вт, ноя 30 2021, 14:14 ]
Заголовок сообщения:  Re: Оптимизация использования памяти
LKU написал:
Потом с появлением HANA маятник качнулся и SAP стал объяснять какие они молодцы, что позволяют убрать лишний код из серверов приложений, перенести его в БД и тем самым уменьшить объем сетевого трафика.


Видимо шустрые ssd-диски подешевели, что теперь нет смысла экономить на ИО-Костах, БД на шустром железе и так прожуёт. Логично такто, но както не по саповски :)
Автор:  LAT [ Вт, ноя 30 2021, 23:12 ]
Заголовок сообщения:  Re: Оптимизация использования памяти
Только не совсем понятно, что имеется в виду под «перенести логику в БД». Если использовать возможности обновлённого SQL – то да: он стал мощнее (например, если раньше нужно было делать несколько выборок, а потом сочетать таблицы на AS, то теперь можно всё сделать одним селектом), да и HANA тянет ранее тяжёлые селекты «на ура». Если переносить всё в CDS, то особого роста производительности не заметно (обычно даже наоборот), для сдс, включённых в segw (через reference) всё равно всё приходит на AS в CL_SADL_SQL_EXECUTOR==========CM00A (с довольно странным селектом, имхо). А вот отладка и сопровождение – со слезами на глазах.
Автор:  Кодер [ Ср, дек 01 2021, 10:30 ]
Заголовок сообщения:  Re: Оптимизация использования памяти
LAT написал(а):
Если переносить всё в CDS, то особого роста производительности не заметно (обычно даже наоборот), для сдс, включённых в segw (через reference) всё равно всё приходит на AS в CL_SADL_SQL_EXECUTOR==========CM00A (с довольно странным селектом, имхо). А вот отладка и сопровождение – со слезами на глазах.


Странное утверждение. Проверил в 2ух системах (7.5 и 7.52) ни в одной нет такого класса
Автор:  LAT [ Ср, дек 01 2021, 11:53 ]
Заголовок сообщения:  Re: Оптимизация использования памяти
Нет класса CL_SADL_SQL_EXECUTOR?
Автор:  Кодер [ Чт, дек 02 2021, 10:20 ]
Заголовок сообщения:  Re: Оптимизация использования памяти
Ага
Автор:  Parazit [ Вс, дек 05 2021, 20:48 ]
Заголовок сообщения:  Re: Оптимизация использования памяти
pberezin написал:
Parazit написал:
Не нужно читать таблицы по отдельности. Пишите сложные выборки с join и packed size. Open cursor with hold поможет сохранять данные порциями. В идеале из БД вы должны получать только необходимые данные, ничего лишнего. Если у вас много селектов с for all entries, это верный признак, что делаете что-то не так.

Хм. А разве это не путь обратно в двухзвенку? Нагружая СУБД сложными джойнами (с километровыми планами выполнения) мы разве не садим общую производительность системы, ценой ускорения работы одного конкретного пользователя данного отчёта/транзакции?
Почемуто думал, что архаичная декомпозиция джойнов на отдельные операции с таблицами через сервер приложения и последующие абап-циклы "джойнов", это какраз то, чем исторически сильна сап-коробка. :?

Во-первых, самой темой задано снижение нагрузки с сервера приложений.
Во-вторых, за трёхзвенку не беспокойтесь, сервер приложений без работы не останется. Сами же знаете, что задачи обычно сложнее простой выборки и отображения простого отчёта. Иначе было бы достаточно Report Painter, а нас разогнать. :)
В-третьих, разумеется SQL-запросы должны писаться максимально грамотно - оптимизация, ключи, индексы и т.д. Но начинать надо с грамотного проектирования БД, что, к сожалению, не всегда осуществимо. Т.н. "декомпозиция джойнов" не сильная сторона, а вынужденная мера, например, для связки таблиц пула (а ля BSEG) или нестыкуемых полей связи (ошибки проектирования БД). В целом же такой подход всегда работает хуже - медленнее и больше нагружает все узлы системы (СУБД, шины данных, каналы связи, серверы приложений). Во всяком случае за свою практику исключений не встречал, и даже споры выигрывал. :)
Автор:  pberezin [ Ср, янв 19 2022, 16:08 ]
Заголовок сообщения:  Re: Оптимизация использования памяти
Parazit написал:
Т.н. "декомпозиция джойнов" не сильная сторона, а вынужденная мера, например, для связки таблиц пула (а ля BSEG) или нестыкуемых полей связи (ошибки проектирования БД). В целом же такой подход всегда работает хуже - медленнее и больше нагружает все узлы системы (СУБД, шины данных, каналы связи, серверы приложений).
Во всяком случае за свою практику исключений не встречал, и даже споры выигрывал. :)


Полагал, что эта вынужденная мера позволяла сап-коробке не одно десятилетие сознательно замедлять и нагружать работу единичного пользователя (и евоного отчёта ... ну и абапера, кто это всё декомпозирует и отлаживает :) ),
но за счёт возможности давать толктись на ноде тысячам такихже активных пользователей. Чтобы они все дружно колом не вставали на блокировках СУБД, если 50ти тяжёлые коммиты "вот ща последнюю фактуру допровожу", а у остальных 100 экземпляров годовой отчётности уже запущены "вот прям щас надо" :)

А щас получается обратно в дремучее двухзвенное прошлое.
Автор:  Kengur [ Пт, янв 28 2022, 16:15 ]
Заголовок сообщения:  Re: Оптимизация использования памяти
У транзакционной ханы очень низкая нагрузка по CPU обычно. Вот и решили догрузить ее немного...
Страница 1 из 2 Часовой пояс: UTC + 3 часа
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/