Добрый день!
Перенес продуктив со старого сервера WIN 2003 IA (Oracle) на Linux SLES (Oracle). Все переехало нормально, протестили небольшой группой людей. Запустили пользователей. И тут началось. После того как в продуктив набивается человек 100-120 начинаются невыносимые тормоза, в систему в этот момент трудно даже войти.
Новый сервер по железу гораздо быстрее старого, рейд тоже. Один ньюанс - новый продуктив сидит в виртуалке VMWare vSphere 5
Физически памяти 64 гига, виртуалке с продуктивом выделено 48 Гиг, потом увеличил до 52. Выделено 2 проца по 4 ядра. Других виртуалок на гипервизоре нет. Сеть через 4 порта 1 Gb (Load Balansing) Когда SAP тормозит, монитор в Линуксе показывает что на самом деле сервер практически ничего не делает. Память не забита, в сети свободно. Что за засада - не понятно совершенно!

Что можно помониторить или посмотреть еще? Дело осложняется тем, что реально это можно проверить только при активной работе кучи пользователей. Старый сервер конечно тоже не летает, но вот так чтобы совсем не шевелился боольшая редкость.

а сколько выделено инстанции SAP и БД? соотношение количества процессов SAP и пользователей?

вообще, начните анализ тормозов с st03n

При миграции 24 гига себе взял Instance RAM (половину памяти сервера)
в разделе Database Advanced Options параметр MaxDatafileSize взял значение - 2000

Те я все оставил тут по умолчанию. Диалоговых процессов сделал 20 штук, фоновых 5.
Пользователей обычно работает 120 и у каждого по 2-3 режима открыто.
В ST03N сейчас уже смотреть особо нечего, ибо вернул пока старый сервер. А этот без 100 пользователей летает само собой.
Нужна армия ботов для тестирования под нагрузкой.

MaxDatafileSize - это размер дата-файла. Вам нужны параметры sga_max_size, либо sga_target

в st03n есть история

Глянул в Оракле -

sga_max_size 12864M
sga_target 0

попробуйте утилитой niping нагрузить сеть в сторону сервера и обратно и посмотреть на нагрузку процессоров (особенно на стороне vmware)
также стоит приметить нагрузку на диски в момент работы юзеров.

несколько вопросов:
1. какая файловая система использована?
2. как настроено дисковое хранилище и как оно подцеплено?

объсню про нагрузку сети - был перед глазами интересный случай, когда мощная нагрузка на сеть прогибала производительность виртуальных вычислительных мощностей (и как следствие - реальных тоже).

на счет нагрузки - посмотрите в сторону HP LoadRunner.

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

А в vmware какие типы контроллеров стоят? Под сетку и под диски?
А SLES какой версии?
А диски какие/на чем расположены? Локальные/на выделенном сторадже?
А система/ядро SAP какой версии?
А механизм выделения памяти в параметрах системы какой задействован?
А package для SAP в sles установлен?

попробуйте sga_target установить в 20G

пакет установлен, да, во время инсталляции системы

А я для начала посоветовал бы статистику в базе собрать/обновить. Уж больно типичная ситуация

Сетевую карточку поставьте, все-таки VMXNET3. Лучше будет. И про дисковые контроллеры ничего не ответили. Я спрашивал не про диски, а про контроллер. Рекомендую поставить Paravirtual. Вкратце рекомендации вот здесь

Ага. 11 sp2.
Подмонтируйте диск с vmware Tools и установите их. С командной строки. С ключиком --clobber-kernel-modules=vmemctl,vmxnet3,pvscsi
Будете использовать текущие драйвера из vmware.

С какого образа ставили vmware? У HP есть собственный образ со всеми зашитыми драйверами для собственного оборудования. Вплоть до версии 5.1. Крайний патч для 5.1 надо будет накатить, после этого, руками.

В RZ10/RZ11 проверьте значение параметра es/implementation. Должно быть STD.
Посмотрите ноту 941735 по поводу параметров памяти для линуха.

Со свопом, кстати, как обошлись? Сколько дали?

Вообще 48 Gb памяти на 100 пользователей, и тормозит - это нонсенс 8-ми хватать должно

Статистику собирал стандартным заданием в DB13

Внял рекомендациям и поставил адаптер VMXNET и диск-контроллер Paravirtual. Все заработало сразу, не пришлось даже линукс переставлять.
VMWARE Tools я же ставил сразу после инсталляции линукса.


Ставил с официального дистриба с сайта vmware. VMWare vSphere Essentials 5, что купили то и поставил.



es/implementation стоит в STD
SWAP раздел в линуксе сделан 50 Гиг
Я не большй спец в линуксе и что то меня смущают разделы TMPFS, они сами создались.

Полностью согласен. Что-то здесь ненормально.

Вообще, разумеется, нужно было начать с анализа ST03 - посмотреть где затык. Если в базе то и плясать в сторону сбора статистики, параметров оракла, типов и параметров дисковых адаптеров и т.д. Кстати, на продуктиве мне бы в голову никогда не пришло использовать raid5/50, только 1/10.
Сюда же, кстати, было бы полезно посмотреть статистику оракловых евентов, и тяжелых запросов в ST04. И долю I/O wait в загрузке CPU. Хотя последний параметр в истории ST06, кажется, не сохраняется, тут больше надежды на какую-нибудь внешнюю систему мониторинга. В SLES по умолчанию в кроне запускается sar и пишет логи, оттуда можно взять.
У меня был случай похожий, когда система впустую летала и начинала тормозить при большом количестве пользователей (правда на порядок большем, чем у вас) - дело оказалось в недостаточной производительности дисковой подсистемы, причем больше в ее кривой конфигурации, чем в общей мощности железа. Из ST03 и оракловых евентов это достаточно явно диагностировалось.

Если затык не(только) в базе, то более актуальными становятся советы по поводу параметров инстанции - распределение памяти es/implementation, размер буферов (ST02), к примеру того же abap/buffersize, хватает ли количества диалоговых процессов, не в зависших ли блокировках дело и т.д.

Да, первоначально хотел сделать рейд 10, какого то лешего всеже 50 сделал
наверное переконфигурю на 10-ку