SMT4

Предыдущий пост здесь.  Приобретая систему с 256 ядрами заказчик конечно же захотел использовать SMT в Power 7 на полную катушку, те включить режим SMT4 и получить в общей сложности 1000 процессоров в одной LPAR.  Однако Best Practice на сегодняшний день - это использование в таких конфигурациях SMT2. Этому есть несколько объяснений, в том числе и то, что Oracle Dev не имеет доступа к таким машинам, а значит не имеет возможности нормально протестировать код.  Ну а раз нет возможности протестировать, то и найти возможные проблемы с масштабируемостью (как в Oracle, так в AIX) тоже удается только по факту их возникновения.  Ничего личного, это просто текущее положение вещей. Вот и мы, для  временного обхода одной из проблем в AIX,  решили попробовать перейти в режим SMT OFF.

Конечно возник вопрос а как это скажется на производительности ? Процессоров то станет меньше.  На основе просмотра статистики, стало ясно, что можно выключить  SMT без ущерба для производительности в данном конкретном случае. Детали вы найдете в моей презентации, но если коротко - в системе не находилось одновременно более 256 работающих процессов. А если процессов меньше, чем ядер, AIX умеет распознавать эту ситуацию, и помещает каждый процесс на отдельное ядро, те фактически автоматически переводит систему в наиболее оптимальный  режим SMT. Но а если вы  точно знаете что происходит, то лучше сделать это самому. Магия SMT настолько велика, что пришлось даже немного поспорить с заказчиком  (и в конечном счете выиграть-), что переключение не приведет к ухудшению производительности приложения в целом. 

Было принято  решение делать это "на ходу", чтобы избежать простоя системы. У меня не было опыта,  как отработают 256 ядер переключаясь из одного режима в другой, но к удивлению, после примерно 10 минут повышенной активности sys все успокоилось.

Несмотря на то, что изменение конфигурации SMT возможно на ходу с помощью команды smtctl в больших системах рекомендуют этого не делать, а поменяв конфигурацию перегрузить систему. Я не знаю объяснения последнему факту, но верю инженерам IBM, и рекомендую следовать этой практике,  особенно  для случая когда в одну  LPAR выделены сотни (!)  ядер.

Другая опасность состояла в том, как переживет Oracle потерю половины процессоров (Oracle видит каждый thread как отдельный процессор). Но тут тоже все обошлось.   В Oracle на самом деле достаточно много внутренних структур и распределение памяти  на старте системы зависит от кол-во процессоров:
- working data set per buffer pool
- число latches защищающих library cache
- число redo copy latches
- число public redo treads
- число database writers и некоторые другие параметры,  которые можно выставить и самому

И хотя все эти структуры создаются на старте экземпляра, и не меняются после изменения кол-во процессоров "на лету", может так оказаться, что само изменение числа процессоров приведет не к оптимальной работе БД. Теоретически.

В 11.2 появился скрытый параметр _disable_cpu_check который похоже предназначен для таких ситуации. Вы ставите нужный вам cpu_count, и  _disable_cpu_check = TRUE (FALSE по умолчанию), и больше не будете зависеть от кол-ва процессоров (еще сам это не проверил)  

Ну и напоследок небольшой анекдот:

Я привык пользоваться командой vmstat для мониторинга кол-ва активных процессов ожидающих процессора (колонка r). Тут интересная деталь. Я всегда считал,  что там фиксируется кол-во процессов, именно  ожидающих процессора. И это так для  Linux
"The number of processes waiting for run time".  Однако для AIX оказалось, что: "Runnable threads consist of the threads that are ready but still waiting to run, and the threads that are already running"

Вместо заключения: хорошо ли SMT4,   или SMT2, или лучше вообще выключить зависит от задачи. Надеюсь я вас этим не удивил. В большинстве систем можно включить SMT4 и AIX сам сделает как надо. И только в очень больших системах лучше сначала подумать и собрать несложную статистику.  На картинке, интересный скриншот, сравнение с помощью rperf Power5/Power6 с SMT4 Power 7. Очень важно, что это capacity сравнение, не сравнение по скорости. Наверно более подробно, в следующей серии -)

PS Над проектом работала большая команда, поэтому все обнаруженные улучшения/настройки являются коллективным трудом.