Текущее время: Чт, мар 28 2024, 15:26

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


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


ВНИМАНИЕ!

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



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

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

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

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

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


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

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

_________________
я твой сап эфай внедрял
BAdI-позитив
Взять немножечко абопу, сунь туда кошачью *опу, RFC лапки, БТ старой бабки, на медленном базиснике переносить, тестовое окружение материть, снимать SAT пенку, биться головой о стенку, охапка тайм-шитов, отчет готов!


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

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

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

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

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

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

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


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

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


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

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

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


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

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

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

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


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

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


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


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

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


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

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


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

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


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

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


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

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

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


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

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

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

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

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


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

Зарегистрирован:
Чт, мар 29 2007, 11:51
Сообщения: 330
Откуда: Yugorsk.RU
Пол: Мужской
Parazit написал:
Т.н. "декомпозиция джойнов" не сильная сторона, а вынужденная мера, например, для связки таблиц пула (а ля BSEG) или нестыкуемых полей связи (ошибки проектирования БД). В целом же такой подход всегда работает хуже - медленнее и больше нагружает все узлы системы (СУБД, шины данных, каналы связи, серверы приложений).
Во всяком случае за свою практику исключений не встречал, и даже споры выигрывал. :)


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

А щас получается обратно в дремучее двухзвенное прошлое.


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

Зарегистрирован:
Чт, дек 20 2007, 18:21
Сообщения: 1613
У транзакционной ханы очень низкая нагрузка по CPU обычно. Вот и решили догрузить ее немного...

_________________
я твой сап эфай внедрял
BAdI-позитив
Взять немножечко абопу, сунь туда кошачью *опу, RFC лапки, БТ старой бабки, на медленном базиснике переносить, тестовое окружение материть, снимать SAT пенку, биться головой о стенку, охапка тайм-шитов, отчет готов!


Принять этот ответ
Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 16 ]  На страницу 1, 2  След.

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


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

Сейчас этот форум просматривают: нет зарегистрированных пользователей


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

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