Применение параллельных вычислений для повышения производительности ИТ систем.   

   

 Так, согласно наблюдению, получившему впоследствии название "закон Мура", примерно до 2000–2001 года число транзисторов на кристалле удваивалось каждые два года, при этом росла и тактовая частота. Но с начала двухтысячных годов технология производства изменилась. Развитие доступных серверных процессоров пошло не путем повышения тактовой частоты, а в сторону добавления процессоров. Сейчас же увеличивается не только количество ЦПУ, но и число их ядер. Это произошло потому, что теперь при разработке кристаллов задействуются нанотехнологии и возникают уже физические ограничения, определяемые, в частности, размерами атомной решетки.

На сегодняшний день параллельные вычисления используют небольшое количество программ. Это связано, в первую очередь, с тем, что разработка приложений, использующих параллельные вычисления, сложнее, и более трудоемка,  чем при использовании традиционных последовательных вычислений.

  • Рисунок выше показывает процесс последовательной обработки информации одним процессором.

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

Давайте рассмотрим почему.  Многопоточность поддерживалась и ранее на однопроцессорных машинах. Но в единицу (квант) времени любую из задач обслуживал один и тот же процессор. Фактически, задачи становились в очередь и выполнялись последовательно. При этом скорость обработки напрямую зависела от тактовой частоты процессора. Ранее для решения задач производительности было достаточно обновить сервер с более мощным ЦПУ, тактовая частота каждый год которого удваивалась.

Сейчас дело обстоит по-другому. Каждую из задач в единицу времени может обслуживать отдельный процессор. Соответственно, общая скорость будет равняться сумме скоростей всех процессоров. (в случае если узким местом не становятся другие ресурсы, например, диск). Но это только в том случае, если задачи выполняются параллельно.  Если же, в силу логики, задачи становятся в очередь – работать будет только один процессор. В этом случае  общая скорость(производительность) будет равняться скорости только одного процессора.

  • Рисунок иллюстрирует, как выглядит процесс обработки параллельных потоков одним процессором. 1 CPU может обработать несколько параллельных потоков, выстраивая информационные пакеты в очередь.
  Существуют задачи, которые достаточно легко распараллеливаются. К сожалению, есть задачи, и их большинство, для которых задача эффективного распараллеливания не является тривиальной. Впрочем, есть задачи, которые вообще (или крайне не эффективно) не поддаются распараллеливанию.

Эффективность работы приложений


Источник: "СофтПоинт", 2011

На данном графике показана эффективность используемых серверных мощностей для определенных  задач. Мы видим, что использование параллельных вычислений значительно повышает эффективность использования серверных ресурсов, и, чем мощнее сервер, тем больше эффект. 

 Современные СУБД используют многопоточные схемы работы, и на первый взгляд кажется, что параллельность вычислений обеспечивается автоматически. Каждому пользователю соответствует свое соединение, работающее в отдельном потоке.

Пользователи могут посылать свои запросы к СУБД абсолютно параллельно.  Проблема в том, что не все запросы(под запросами подразумеваются в том числе операции на изменение) могут быть обработаны параллельно. Это обусловлено логикой и проблемами, связаными с грязным чтением. В MSSQL неэффективно настроенный блокировочный механизм не позволит всем пользователям работать максимально параллельно с системой.  Это возможно только для систем, у которых все запросы идут только на чтение.  Также отдельно стоит выделить регламентные процедуры с длительным временем выполнения.  В ряде случаев они могут быть хорошо распараллелены и, соответственно, ускорены, но для этого их нужно соответственным образом запрограммировать.  В противном случае, регламентная процедура будет выполнятся в одном потоке и использовать ограниченные серверные ресурсы, и, соответственно, будет выполнятся значительно дольше.

 

  • На рисунке показана параллельная обработка, в данном случае, двух потоков, двумя процессорами.

Приведу несколько примеров использования параллельных вычислений.

 

Самый известный пример использования - проект расшифровки генома. Данная задача хорошо распараллеливается, к тому же она позволяет применять распределенные вычисления. 

 Можно привести пример для задач моделирования. Например, задача расчета траектории взаимодействующих между собой N физических тел.  Подобные задачи  решаются, как правило, путем компьютерного моделирования.  Предполагается, что, если интервал времени разбить на небольшие кусочки, то можно итерационно рассчитывать новую координату для каждого из тел.  Чем меньше интервал времени, тем выше точность расчетов. Раньше в однопроцессорных серверах не было смысла данные задачи распаралелливать.  В цикле соответствующему множеству всех тел рассчитывалась координата каждого.

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

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

 

  • Рисунок показывает  ситуацию, когда потоков меньше чем процессоров, в таком случае кол-во обрабатывающих процессоров  ровно числу входящих потоков информации, остальные процессоры свободны.

Можно рассмотреть вариант применения распараллеливания для бизнес задач. Рассмотрим несколько регламентных задач. Одна из самых актуальных - это задача ускорения процедуры перепроведения документов с целью восстановления последовательности.  Также можно рассмотреть задачу расчета заработной платы.

 Большинство ИТ специалистов уверено, что задачу восстановления последовательности можно ускорить только путем линейного ускорения проведения документов. В случае, если наша цель -  ускорить перепроведение  документов, к примеру, в два раза, это является задачей практически невыполнимой.

Это еще раз говорит о том, что принципы построения систем с использованием параллельных вычислений большинству ИТ специалистов незнакомы. 

Данная задача в случае высокого уровня параллельности информационных потоков также хорошо распараллеливается. 

 Концептуально она решается реализацией блокировочного механизма. Координатор данного блокировочного механизма отличается от стандартного  MSSQL и от координатора управляемых блокировок в 1С 8.(почему это так, более подробно рассматривается в отдельной статье)           

 Также необходим пул сессий 1С и координатор задач, который будет выдавать каждой сессии 1С свой документ на проведение.  Как только сессия проводит документ и освобождается, координатор выдает ей новый на проведение.  Вы спросите, а как же последовательность, а точнее хронология?  За это отвечает координатор блокировок. Если документ связан с проводимыми в данный момент другими документами на уровне данных, например, номенклатура или клиент, тогда он будет ожидать своей очереди. Если же документ никак не связан, то он будет проводиться параллельно. Каждый отдельный процессор будет параллельно обрабатывать проведение своего документа, за счет чего будет ускорение.  В данном случае, если данные не сильно связаны друг с другом,  то ускорение может быть очень существенным, иногда в 10-ки раз. Разумеется, это зависит и от серверных ресурсов. На слабых серверах ускорение будет незначительным.

 Рассмотрим задачу  ускорения расчета заработной платы.  Сотрудников можно разделить на секции и рассчитывать эти секции параллельно. Затем результаты соединять в общий интегрированный расчет.  Проблема возникает, когда  зарплата одних сотрудников зависит от рассчитанной зарплаты других сотрудников. Предположим, зарплата начальника отдела зависит от прибыли отдела, на которую влияет зарплата сотрудников.  В этом случае часть подзадач распараллеливается, а часть требует последовательного вычисления. 

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

Хотелось бы пофантазировать, каким образом можно было бы применять распараллеливание, к примеру, в TSQL. Но, впрочем, все по порядку,  это тема для отдельной статьи…

 


 

Перепечатка, воспроизведение в любой форме, распространение, в том числе в переводе, любых материалов с сайта www.softpoint.ru возможны только с письменного разрешения компании "СофтПоинт". Это правило действует для всех без исключения случаев, кроме тех, когда в материале прямо указано разрешение на копирование (основание: Закон Российской Федерации "Об авторском праве и смежных правах").

Статья: Применение параллельных вычислений для повышения производительности ИТ систем.

Перейти на главную страницу компании "Софтпоинт"