Меню

Сортировать:

Новое Популярное
Загрузка Z-полей с помощью LSMW (1)

Комментарий от  

Евгений Тенищев

  |  21 октября 2020, 23:21

Было бы не плохо продемонстрировать скриншотом как это выглядит в lsmw. Особенно интересно в разделе где прописывается мэппинг.
Пока, если честно, не понятно как это реализовать в lsmw.
Сервер приложений SAP? Это очень просто! (4)

Комментарий от  

Александр Игнатенко

  |  14 октября 2020, 21:53

Олег Точенюк 14 октября 2020, 21:38

Однако классные консультанты, буферизацию сами включают :-), я как-то думал, это не задача функционального консультанта. Но вы расширили мой кругозор редкими экземплярами. Не знал про таких.

Мир далеко не идеален, есть и такие консультанты. :)
Сервер приложений SAP? Это очень просто! (4)

Комментарий от  

Олег Точенюк

  |  14 октября 2020, 21:38

Александр Игнатенко 14 октября 2020, 17:18

Олег, доброго дня.
Абсолютно согласен, абапер может уложить систему так что базиснику не снилось. Но и консультанты имеют возможности попортить жизнь.
Ни кому не сказав, включает буферизацию на Z-таблицу размером 30ГБ с документами, со словами "а мне **** сказал, что так быстрее". Результат я думаю понятен. Или другой, включил заполнение инфраструктуры на выходные, логи за пару часов забили директорию в которой был 3-х кратный запас, система встала. Для справки, она в результате была 780ГБ. Ещё вариант: включили параллельную обработку, уже не вспомню деталей, всё бы ничего, вот только одновременно этот процесс запускали 30 человек, и рабочих процессов под такую нагрузку не было предусмотренно. Объяснение такое же простое: "на DEV и QAS у меня всё работало".
Список можно продолжать. У каждого свои истории.

Однако классные консультанты, буферизацию сами включают :-), я как-то думал, это не задача функционального консультанта. Но вы расширили мой кругозор редкими экземплярами. Не знал про таких.
Сервер приложений SAP? Это очень просто! (4)

Комментарий от  

Александр Игнатенко

  |  14 октября 2020, 17:18

Олег Точенюк 14 октября 2020, 12:46

====
как производимые ими настройки и разработки могут повлиять на работоспособность системы в целом
====
Да никак, на то она и настройка, это вы ведь не про абаперов писали? Абаперы те да, положить систему могут быстро и качественно :-)

Олег, доброго дня.
Абсолютно согласен, абапер может уложить систему так что базиснику не снилось. Но и консультанты имеют возможности попортить жизнь.
Ни кому не сказав, включает буферизацию на Z-таблицу размером 30ГБ с документами, со словами "а мне **** сказал, что так быстрее". Результат я думаю понятен. Или другой, включил заполнение инфраструктуры на выходные, логи за пару часов забили директорию в которой был 3-х кратный запас, система встала. Для справки, она в результате была 780ГБ. Ещё вариант: включили параллельную обработку, уже не вспомню деталей, всё бы ничего, вот только одновременно этот процесс запускали 30 человек, и рабочих процессов под такую нагрузку не было предусмотренно. Объяснение такое же простое: "на DEV и QAS у меня всё работало".
Список можно продолжать. У каждого свои истории.
Сервер приложений SAP? Это очень просто! (4)

Комментарий от  

Олег Точенюк

  |  14 октября 2020, 12:46

====
как производимые ими настройки и разработки могут повлиять на работоспособность системы в целом
====
Да никак, на то она и настройка, это вы ведь не про абаперов писали? Абаперы те да, положить систему могут быстро и качественно :-)
Ускорение программ через параллельное программирование (11)

Комментарий от  

Олег Точенюк

  |  01 октября 2020, 09:30

Виталий Глущенко 01 октября 2020, 00:16

все ж было б неплохо указать в статье, что не стоит параллелить пока не выжали все из последовательной обработки. А то находятся последователи индуских талмудов, так напараллелят, что другие процессы стоят.
 
Пример в статье идеальный, 20 задач, 9 параллельных процессов, задача грузит только CPU, поэтому отлично подходит для параллезации. Получили шикарный прирост производительности 80/12 ~= 6,7 раз. Реальный пример, от Олега дает всего лишь 20 632 688/11 520 002 ~1,79 увеличение, при 3-х кратной парализации.
Лучше вначале разобраться, где у вас узкое место и почему оно именно настолько узкое. Иначе есть риск наткнуться на "бо-бо" в продуктивной системе, после "новаторской" оптимизации.

По поводу последующей параллельности, при таком подходе когда сначала сделали как сделали, а через год пришли к тому, что нужно параллелить, есть одна проблема, потом это сделать практически невозможно, точнее это значит полностью переписать программу, т.е. если есть мысль последующей параллелизации программы, то я бы сразу ее делал с параллельным выполнением, но ставил бы 1 процесс и на год бы забывал о проблеме :-)
Ускорение программ через параллельное программирование (11)

Комментарий от  

Виталий Глущенко

  |  01 октября 2020, 00:16

Олег Точенюк 31 августа 2020, 14:28

Чего-то у меня цифры не бьются. Например на установку статуса пусть уходит 1 секунда, и время закрытия 5 часов итого за это время при последовательном закрытии у тебя закрывается 5 * 3600 = 18 000 заказов. После распараллеливания, заказ как зарывался за 1 секунду так и будет закрываться, что его параллельно, что последовательно грузить (бапишке фиолетово она в своем процессе отработает необходимое ей время как ты ее не крути). По твоим словам, теперь это все стало отрабатывать за пару минут, ну пусть это будет 5 минут для ровности. Итого у тебя каждую минуту закрывается сколько? Правильно 3600 / 5 = 720 заказов. Короче я в своей жизни систему с 720 свободными процессами не видел еще, твоя видимо первая будет, ну это чтобы оно таки за пару, точнее 5 минут отработало. В общем если бы была реальная статистика с рабочей системы приведена, было бы чуть интереснее. В свое время когда такое делал я просто привел цифры, чтение 120 000 документов:
 
Паралельно 3 процесса: 11 520 002 милисекунд
Последовательно : 20 632 688 милисекунд
 
А ну и сейчас перформы уже не модно Василий К. придет будет говорить, что это не правильное программирование :-), на классах параллельность выглядит чуток интереснее и красивее в реализации, программа обработки выглядит типа так:
LOOP AT <по каким-то объектам которые надо обработать>.
lcl->read( ).    "Прочитали что надо обработать в процесе
lcl->process( ). "Запустили процесс обработки
lcl->wait( ).    "Ждем если нет свободных процессов, иначе идем на следующий шаг.
ENDLOOP.

все ж было б неплохо указать в статье, что не стоит параллелить пока не выжали все из последовательной обработки. А то находятся последователи индуских талмудов, так напараллелят, что другие процессы стоят.
 
Пример в статье идеальный, 20 задач, 9 параллельных процессов, задача грузит только CPU, поэтому отлично подходит для параллезации. Получили шикарный прирост производительности 80/12 ~= 6,7 раз. Реальный пример, от Олега дает всего лишь 20 632 688/11 520 002 ~1,79 увеличение, при 3-х кратной парализации.
Лучше вначале разобраться, где у вас узкое место и почему оно именно настолько узкое. Иначе есть риск наткнуться на "бо-бо" в продуктивной системе, после "новаторской" оптимизации.
Недели вебинаров SAPLAND и SAP (1)

Комментарий от  

Федор Иванов

  |  25 сентября 2020, 07:50

"Обучение ABAP. Отладчик. Основы" на сайте 29.09
в календарь пришло приглашение на 30.09
где то неточность!
Обзор функциональности кредитования (2)

Комментарий от  

Олег Точенюк

  |  03 сентября 2020, 23:07

Наталья Сурмак 03 сентября 2020, 09:49

Статья замечательная. Но хотелось бы подробнее узнать по настройке проводок.

Настройки проводок это то, за что Мари Лоран, получает деньги, поэтому спасибо ей, что она поделилась, скажем так безвозмездно, т.е. даром, о том что есть такая вот функциональность. Теперь у вас есть два варианта, разобраться самой или пригласить независимого консультанта Мари Лоран, которая сделает это за вас, конечно уже не безвозмездно, т.е. не даром :-)
Обзор функциональности кредитования (2)

Комментарий от  

Наталья Сурмак

  |  03 сентября 2020, 09:49

Статья замечательная. Но хотелось бы подробнее узнать по настройке проводок.
Ускорение программ через параллельное программирование (11)

Комментарий от  

Олег Точенюк

  |  03 сентября 2020, 08:04

Александр Носов 03 сентября 2020, 07:30

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

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

Комментарий от  

Александр Носов

  |  03 сентября 2020, 07:30

Олег Точенюк 02 сентября 2020, 12:19

Ну например так:
MAX_PBT_WPS = 24
FREE_PBT_WPS = 22 (на момент запуска)
 
Пользователей скажем так где-то 1100-1200, понятно что активных гораздо меньше. Система S/4

Даже если использовать треть диалогов для параллельных задач, можно в 8 раз ускорить некоторые процессы. Для некоторых операций это будет серьезным увеличением.
Ускорение программ через параллельное программирование (11)

Комментарий от  

Олег Точенюк

  |  02 сентября 2020, 12:19

Александр Носов 01 сентября 2020, 10:09

Да, диалогов. А у вас какие значения вернет SPBT_INITIALIZE в продуктиве?
Насчет пользователей не располагаю достоверной информацией.

Ну например так:
MAX_PBT_WPS = 24
FREE_PBT_WPS = 22 (на момент запуска)
 
Пользователей скажем так где-то 1100-1200, понятно что активных гораздо меньше. Система S/4
Ускорение программ через параллельное программирование (11)

Комментарий от  

Александр Носов

  |  01 сентября 2020, 10:09

Олег Точенюк 01 сентября 2020, 09:42

Диалогов? 100 процессов не попадалось если честно, обычно гораздо скромнее. Кстати это какое количество пользователей у вас в системе, если не секрет, что более 100 диалогов открыто?

Да, диалогов. А у вас какие значения вернет SPBT_INITIALIZE в продуктиве?
Насчет пользователей не располагаю достоверной информацией.
Ускорение программ через параллельное программирование (11)

Комментарий от  

Олег Точенюк

  |  01 сентября 2020, 09:42

Александр Носов 01 сентября 2020, 08:18

Ограничение группы серверов не более 25% от общего количества процессов. Всего более 100 процессов. Это разве много?

Диалогов? 100 процессов не попадалось если честно, обычно гораздо скромнее. Кстати это какое количество пользователей у вас в системе, если не секрет, что более 100 диалогов открыто?
Ускорение программ через параллельное программирование (11)

Комментарий от  

Александр Носов

  |  01 сентября 2020, 08:18

Олег Точенюк 01 сентября 2020, 07:47

Хорошая у вас система, с сорока свободными процессами и еще наверное плюс десятком дополнительных, на других пользователей, пока программа выполняется :-)

Ограничение группы серверов не более 25% от общего количества процессов. Всего более 100 процессов. Это разве много?
Ускорение программ через параллельное программирование (11)

Комментарий от  

Олег Точенюк

  |  01 сентября 2020, 07:47

Александр Носов 31 августа 2020, 16:47

Если 5-8 часов разделить на 30-40 свободных процессов, получится 7-16 минут.

Хорошая у вас система, с сорока свободными процессами и еще наверное плюс десятком дополнительных, на других пользователей, пока программа выполняется :-)
Ускорение программ через параллельное программирование (11)

Комментарий от  

Александр Носов

  |  31 августа 2020, 16:47

Олег Точенюк 31 августа 2020, 14:28

Чего-то у меня цифры не бьются. Например на установку статуса пусть уходит 1 секунда, и время закрытия 5 часов итого за это время при последовательном закрытии у тебя закрывается 5 * 3600 = 18 000 заказов. После распараллеливания, заказ как зарывался за 1 секунду так и будет закрываться, что его параллельно, что последовательно грузить (бапишке фиолетово она в своем процессе отработает необходимое ей время как ты ее не крути). По твоим словам, теперь это все стало отрабатывать за пару минут, ну пусть это будет 5 минут для ровности. Итого у тебя каждую минуту закрывается сколько? Правильно 3600 / 5 = 720 заказов. Короче я в своей жизни систему с 720 свободными процессами не видел еще, твоя видимо первая будет, ну это чтобы оно таки за пару, точнее 5 минут отработало. В общем если бы была реальная статистика с рабочей системы приведена, было бы чуть интереснее. В свое время когда такое делал я просто привел цифры, чтение 120 000 документов:
 
Паралельно 3 процесса: 11 520 002 милисекунд
Последовательно : 20 632 688 милисекунд
 
А ну и сейчас перформы уже не модно Василий К. придет будет говорить, что это не правильное программирование :-), на классах параллельность выглядит чуток интереснее и красивее в реализации, программа обработки выглядит типа так:
LOOP AT <по каким-то объектам которые надо обработать>.
lcl->read( ).    "Прочитали что надо обработать в процесе
lcl->process( ). "Запустили процесс обработки
lcl->wait( ).    "Ждем если нет свободных процессов, иначе идем на следующий шаг.
ENDLOOP.

Если 5-8 часов разделить на 30-40 свободных процессов, получится 7-16 минут.
Ускорение программ через параллельное программирование (11)

Комментарий от  

Олег Точенюк

  |  31 августа 2020, 14:28

Чего-то у меня цифры не бьются. Например на установку статуса пусть уходит 1 секунда, и время закрытия 5 часов итого за это время при последовательном закрытии у тебя закрывается 5 * 3600 = 18 000 заказов. После распараллеливания, заказ как зарывался за 1 секунду так и будет закрываться, что его параллельно, что последовательно грузить (бапишке фиолетово она в своем процессе отработает необходимое ей время как ты ее не крути). По твоим словам, теперь это все стало отрабатывать за пару минут, ну пусть это будет 5 минут для ровности. Итого у тебя каждую минуту закрывается сколько? Правильно 3600 / 5 = 720 заказов. Короче я в своей жизни систему с 720 свободными процессами не видел еще, твоя видимо первая будет, ну это чтобы оно таки за пару, точнее 5 минут отработало. В общем если бы была реальная статистика с рабочей системы приведена, было бы чуть интереснее. В свое время когда такое делал я просто привел цифры, чтение 120 000 документов:
 
Паралельно 3 процесса: 11 520 002 милисекунд
Последовательно : 20 632 688 милисекунд
 
А ну и сейчас перформы уже не модно Василий К. придет будет говорить, что это не правильное программирование :-), на классах параллельность выглядит чуток интереснее и красивее в реализации, программа обработки выглядит типа так:
LOOP AT <по каким-то объектам которые надо обработать>.
lcl->read( ).    "Прочитали что надо обработать в процесе
lcl->process( ). "Запустили процесс обработки
lcl->wait( ).    "Ждем если нет свободных процессов, иначе идем на следующий шаг.
ENDLOOP.
Изменение данных таблиц через отладчик или ФМ (19)

Комментарий от  

Олег Точенюк

  |  30 августа 2020, 21:22

Олег Башкатов 30 августа 2020, 19:55

а можно вопрос немного переиначу:
что делать, если такой человек уже принят? и он уже формирует архитектуру и выдает ТЗ и уверен, что он прав, и уверяет других, что так лучше?
и там уже не 2 + 2 = 5, там 2 + 2 = 'ЛучшийВмиреОтвет подбери себе сам и с музыкой'.

Ну выход то у тебя всегда есть, вроде крепостное право отменил давно уже :-) А так что ты с ним можешь сделать? Он же уже работает и вадает как я понимаю тебе ТЗ. Ну можешь делать так как считаешь нужным, некоторое время.