На моем рабочем месте у нас есть активно используемый сервер SAS, но его рабочая нагрузка такова, что получение 1 минуты процессорного времени часто занимает 10 минут реального времени. Это происходит не только из-за узких мест ввода-вывода или сети - средняя загрузка ЦП всегда очень высока в рабочее время, и многим аналитикам приходится долго ждать выполнения своих запросов.
Я хотел бы сравнить два варианта:
Вариант 1 определенно возможен, но я подозреваю, что лицензирование будет чрезвычайно дорогостоящим. С другой стороны, вариант 2 выглядит так, как будто он включает в себя очень модное сетевое оборудование. Вариант 2:
Я думаю, что SAS должен иметь возможность работать на одном из вариантов Linux, поддерживаемых ScaleMP - существующий сервер SAS использует SunOS 5.10, который, я думаю, не поддерживается, поэтому, вероятно, нам придется перенести нашу базу данных на новую установку из sas.
Еще один фактор, который следует учитывать, заключается в том, что у нас есть очень значительная кодовая база, которая потребует довольно небольшой переработки, чтобы в полной мере использовать сетку SAS.
Я все еще пытаюсь узнать больше о существующем оборудовании, но полагаю, что оно датируется примерно 2005 годом, то есть примерно той же эпохой, что и SunOS 5.10.
Обновление: информация об оборудовании
Из вывода / usr / sbin / psrinfo -v видно, что существующий сервер имеет 32 ядра sparcv9, из которых 8 работают с частотой 1,5 ГГц, а остальные 24 - с частотой 1,8 ГГц. На основе номинальных скоростей из Википедии таблица процессоров sparc и дата ОС 2005 года, я полагаю, это UltraSPARC_IV процессоры или что-то подобное.
По данным prstat, средняя нагрузка в обеденный перерыв в офисе составляет около 32, то есть почти полная нагрузка. В часы пик это число обычно возрастает до 45, но известно, что оно достигает 110 в понедельник утром, когда пакетные задания на выходных переполняются. Итак, я бы пришел к выводу, что есть узкое место в ЦП, но это может быть не так плохо, как я думал - основная часть задержки в получении времени ЦП сервера вполне может быть связана с ожиданием ввода-вывода диска, а не ожиданием в очередь потока.
Согласно выводам
# /usr/platform/`uname -m`/sbin/prtdiag -v
, похоже, на сервере 256 ГБ оперативной памяти.
* Раскрытие информации: я с ScaleMP *
rnxrx написал, что если вы используете SunOS, то HW может быть всем, и он действительно прав. 24 ядра из тех старых времен, вероятно, в 10-50 раз медленнее, чем современный 32-ядерный сервер (с процессорами Intel Sandybridge). Однако 24-ядерная машина в те дни была очень дорогой, и вы не заметили, что используете систему «уровня мэйнфрейма», поэтому было бы очень полезно, если бы вы действительно могли предоставить информацию об аппаратном обеспечении. Если вы можете опубликовать результаты команды: 'cat / proc / cpuinfo', это будет отличным началом.
Если работа, которую вы выполняете, требует большого количества обращений к данным, ScaleMP может быть отличным решением, поскольку технически все данные могут быть помещены в общую оперативную память системы (программное обеспечение ScaleMP в основном превращает кластер в SMP с общей памятью для вас) SAS Аналитика сертифицирована для использования в Redhat Linux: http://www.redhat.com/resourcelibrary/whitepapers/red-hat-and-sas-alliance-brief а также SuSE Linux (и эти дистрибутивы Linux, в свою очередь, сертифицированы как ОС поверх vSMP Foundation от ScaleMP)
Что касается «причудливой сети», действительно - ScaleMP требует использования InfiniBand (который сегодня имеет скорость 40 или 56 Гбит / с, определенно «модно»). Однако стоимость InfiniBand ненамного выше, чем стоимость 10GE, который вам, скорее всего, придется использовать в любом случае (при построении кластера для SAS). Программное обеспечение ScaleMP выполняет все управление сетью за вас, а поскольку машины превращаются в SMP с общей памятью, вам даже не нужно ничего знать об InfiniBand для работы с системой.
Что касается использования преимуществ многих процессоров: это действительно зависит от вашего приложения. Некоторые приложения могут хорошо масштабироваться на SMP, некоторые хорошо масштабируются в распределенном кластере. Иногда, как вы заметили, может потребоваться некоторая работа, чтобы что-то масштабировать (особенно в распределенной / кластерной среде). На первый взгляд, когда вы описывали задания, пытающиеся получить время на «а» ЦП - я предполагаю, что у вас много заданий, использующих одни и те же данные, для которых ScaleMP отлично подходит.
Я был бы рад предоставить дополнительную информацию, по крайней мере, в отношении ScaleMP.