Текущее время: Вт, дек 07 2021, 12:43

Часовой пояс: UTC + 3 часа


Правила форума


ВНИМАНИЕ!

Вопросы по SAP Query и Quick View - сюда



Начать новую тему Ответить на тему  [ Сообщений: 13 ] 
Автор Сообщение
 Заголовок сообщения: Оптимизация использования памяти
СообщениеДобавлено: Ср, окт 06 2021, 11:25 
Младший специалист
Младший специалист
Аватара пользователя

Зарегистрирован:
Чт, сен 01 2005, 15:54
Сообщения: 95
Коллеги, доброго дня!

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

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

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


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация использования памяти
СообщениеДобавлено: Ср, окт 06 2021, 18:04 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, дек 20 2007, 18:21
Сообщения: 1547
Вариантов много. Самый простой - пакетная обработка в селекте. Изобретать что-то с распределенной памятью - как стрелять из плазмогана по воробьям.

_________________
я твой сап эфай внедрял
BAdI-позитив


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация использования памяти
СообщениеДобавлено: Чт, окт 07 2021, 23:52 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, окт 06 2005, 16:44
Сообщения: 3030
Откуда: Москва
ST написал(а):
Коллеги, доброго дня!

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

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

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

Проблемы с памятью определяются через SAT.
У нас подобные проблемы с нехваткой памяти для процесса решались с помощью освобождения памяти временных внутренних таблиц. Кроме REFRESH нужно было делать FREE.
И да - нехватка памяти для процесса, или глобальной памяти?
Опять же - зачем для таблиц договоров и контрагентов читать все поля? :roll:

_________________
С уважением,
Удав.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация использования памяти
СообщениеДобавлено: Пн, окт 11 2021, 11:16 
Директор
Директор

Зарегистрирован:
Вт, ноя 09 2010, 19:59
Сообщения: 789
Откуда: Novosibirsk
Пол: Мужской
подобное для большинства компаний скорее всего только после 2030 года?
Внутренние таблицы как источник в SQL запросах
Code:
Существует два сценария выполнения таких запросов:
    Для выполнения SQL запроса не требуется переноса содержимого внутренней таблицы на уровень СУБД. В таком случае обработка запроса осуществляется непосредственно на сервере приложений, по аналогии с табличным буфером.
    Для выполнения SQL запроса требуется перенести содержимое внутренней таблицы во временную таблицу на уровень СУБД. Этот сценарий поддерживается не всеми СУБД и чтобы статический анализ кода не ругался, следует использовать прагму: ##itab_db_select. При отсутствии поддержки система выдаст исключение в runtime — CX_SY_SQL_UNSUPPORTED_FEATURE.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация использования памяти
СообщениеДобавлено: Ср, окт 13 2021, 14:34 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, авг 19 2004, 17:37
Сообщения: 1958
Откуда: Москва
Пол: Мужской
Не нужно читать таблицы по отдельности. Пишите сложные выборки с join и packed size. Open cursor with hold поможет сохранять данные порциями. В идеале из БД вы должны получать только необходимые данные, ничего лишнего. Если у вас много селектов с for all entries, это верный признак, что делаете что-то не так.
Разумеется, в борьбе за память потеряете в производительности - по другому и быть не должно.

_________________
"For all entries" не в SAP-ах, "for all entries" в головах! :)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация использования памяти
СообщениеДобавлено: Пн, ноя 29 2021, 13:42 
Старший специалист
Старший специалист

Зарегистрирован:
Чт, мар 29 2007, 11:51
Сообщения: 328
Откуда: Yugorsk.RU
Пол: Мужской
Parazit написал:
Не нужно читать таблицы по отдельности. Пишите сложные выборки с join и packed size. Open cursor with hold поможет сохранять данные порциями. В идеале из БД вы должны получать только необходимые данные, ничего лишнего. Если у вас много селектов с for all entries, это верный признак, что делаете что-то не так.

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


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация использования памяти
СообщениеДобавлено: Пн, ноя 29 2021, 13:48 
Гуру-модератор
Гуру-модератор
Аватара пользователя

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

Ну да. Несколько десятилетий существования продуктов R/3 и ERP, SAP объяснял какие они молодцы, что при помощи абапа позволяют снять нагрузку с единой точки отказа (БД) за счет горизонтально масштабируемых серверов приложений. Потом с появлением HANA маятник качнулся и SAP стал объяснять какие они молодцы, что позволяют убрать лишний код из серверов приложений, перенести его в БД и тем самым уменьшить объем сетевого трафика.

_________________
Удача - результат нашего желания (© А. Нортон)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация использования памяти
СообщениеДобавлено: Вт, ноя 30 2021, 14:14 
Старший специалист
Старший специалист

Зарегистрирован:
Чт, мар 29 2007, 11:51
Сообщения: 328
Откуда: Yugorsk.RU
Пол: Мужской
LKU написал:
Потом с появлением HANA маятник качнулся и SAP стал объяснять какие они молодцы, что позволяют убрать лишний код из серверов приложений, перенести его в БД и тем самым уменьшить объем сетевого трафика.


Видимо шустрые ssd-диски подешевели, что теперь нет смысла экономить на ИО-Костах, БД на шустром железе и так прожуёт. Логично такто, но както не по саповски :)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация использования памяти
СообщениеДобавлено: Вт, ноя 30 2021, 23:12 
Старший специалист
Старший специалист

Зарегистрирован:
Чт, май 12 2011, 16:06
Сообщения: 339
Только не совсем понятно, что имеется в виду под «перенести логику в БД». Если использовать возможности обновлённого SQL – то да: он стал мощнее (например, если раньше нужно было делать несколько выборок, а потом сочетать таблицы на AS, то теперь можно всё сделать одним селектом), да и HANA тянет ранее тяжёлые селекты «на ура». Если переносить всё в CDS, то особого роста производительности не заметно (обычно даже наоборот), для сдс, включённых в segw (через reference) всё равно всё приходит на AS в CL_SADL_SQL_EXECUTOR==========CM00A (с довольно странным селектом, имхо). А вот отладка и сопровождение – со слезами на глазах.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация использования памяти
СообщениеДобавлено: Ср, дек 01 2021, 10:30 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Пн, мар 28 2005, 15:38
Сообщения: 1212
LAT написал(а):
Если переносить всё в CDS, то особого роста производительности не заметно (обычно даже наоборот), для сдс, включённых в segw (через reference) всё равно всё приходит на AS в CL_SADL_SQL_EXECUTOR==========CM00A (с довольно странным селектом, имхо). А вот отладка и сопровождение – со слезами на глазах.


Странное утверждение. Проверил в 2ух системах (7.5 и 7.52) ни в одной нет такого класса

_________________
Там, где я рос, единственным развлечением было запоминать число «π».(С) Н. Стивенсон


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация использования памяти
СообщениеДобавлено: Ср, дек 01 2021, 11:53 
Старший специалист
Старший специалист

Зарегистрирован:
Чт, май 12 2011, 16:06
Сообщения: 339
Нет класса CL_SADL_SQL_EXECUTOR?


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация использования памяти
СообщениеДобавлено: Чт, дек 02 2021, 10:20 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Пн, мар 28 2005, 15:38
Сообщения: 1212
Ага

_________________
Там, где я рос, единственным развлечением было запоминать число «π».(С) Н. Стивенсон


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация использования памяти
СообщениеДобавлено: Вс, дек 05 2021, 20:48 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, авг 19 2004, 17:37
Сообщения: 1958
Откуда: Москва
Пол: Мужской
pberezin написал:
Parazit написал:
Не нужно читать таблицы по отдельности. Пишите сложные выборки с join и packed size. Open cursor with hold поможет сохранять данные порциями. В идеале из БД вы должны получать только необходимые данные, ничего лишнего. Если у вас много селектов с for all entries, это верный признак, что делаете что-то не так.

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

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

_________________
"For all entries" не в SAP-ах, "for all entries" в головах! :)


Принять этот ответ
Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 13 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: Yandex [Bot]


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB