Задания с интенсивным использованием памяти плохо масштабируются в многоядерных облачных экземплярах (ec2, gce,ackspace)?

Кто-нибудь еще замечал ужасную производительность при масштабировании для использования всех ядер в облачном экземпляре с заданиями, требующими большого объема памяти (в моем случае 2,5 ГБ)?

Когда я выполняю задания локально на своем четырехъядерном чипе Xeon, разница между использованием 1 ядра и всех 4 ядер составляет примерно 25% замедления для всех ядер. Этого следовало ожидать, насколько я понимаю; падение тактовой частоты по мере исчерпания ядер является частью конструкции многоядерного чипа.

Но когда я запускаю задания на многоядерном виртуальном экземпляре, я вижу замедление времени обработки примерно в 2-4 раза между использованием 1 ядра и всех ядер. Я видел это на инстансах GCE, EC2 и Rackspace. И я протестировал множество разных типов инстансов, в основном самые быстрые из предлагаемых.

Было ли такое поведение замечено другими с заданиями примерно такого же размера в использовании памяти?

Работа, которую я выполняю, написана на фортране. Я их не писал, и на самом деле я не специалист по Фортрану, поэтому мои знания о них ограничены. Я знаю, что у них низкие потребности в вводе-выводе. Они кажутся загруженными ЦП, когда я смотрю top во время их работы. Они работают без необходимости общаться друг с другом, т. е. до неприличия параллельно. Каждый из них занимает около 2,5 ГБ памяти.

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

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


person Jose Cortez    schedule 09.06.2013    source источник
comment
Гиперпоточность иногда может повлиять на ваши результаты. Чтобы максимизировать использование ЦП, вы, как правило, не получаете полные процессорные ядра ни в одном случае, кроме самых больших. Это может привести к потере производительности из-за накладных расходов на планирование.   -  person datasage    schedule 09.06.2013
comment
Когда я проверяю верхнюю часть, похоже, что гиперпоточность не используется. Например, на экземпляре EC2 cc2.8xlarge я запускаю 16 процессов (по одному на ядро), и каждый процесс говорит, что использует 100% своего ядра, но общее использование ЦП составляет 50%. Вы говорите, что под прикрытием виртуализации может использоваться гиперпоточность?   -  person Jose Cortez    schedule 10.06.2013
comment
Это могло быть, и это вызвало проблемы в некоторых случаях. На форумах ec2 было несколько тем по этой проблеме.   -  person datasage    schedule 10.06.2013
comment
Если вы посмотрите на базовое физическое оборудование экземпляра cc2.8xlarge, вы увидите, что он имеет 2 процессора с 4 ядрами каждый. Чтобы получить 16 ядер, он должен использовать гиперпоточность, что может вызвать проблемы для некоторых приложений.   -  person datasage    schedule 11.06.2013
comment
Он имеет 2 x Intel Xeon E5-2670, который является 8-ядерным чипом. Так что, предположительно, всего 16 ядер.   -  person Jose Cortez    schedule 11.06.2013
comment
Похоже, вы правы, я где-то видел противоречивую информацию.   -  person datasage    schedule 11.06.2013
comment
Вы уверены, что top на виртуальной машине скажет, есть ли гиперпоточность на металле?   -  person jeremyjjbrown    schedule 21.02.2014


Ответы (1)


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

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

  1. Запуск одной копии однопоточной программы на вашем ноутбуке занимает X минут.

  2. Запустив 4 копии однопоточной программы на вашем ноутбуке, выполнение каждой копии занимает X * 1,25 минуты.

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

  4. При запуске N копий однопоточной программы в N-ядерном виртуальном облаке выполнение каждой копии занимает X * 2-4 минуты.

Если это так, похоже, вы либо сталкиваетесь с конфликтом ядра, либо с конфликтом, например. ввод/вывод памяти. Было бы интересно посмотреть, могут ли различные параметры компилятора fortran помочь оптимизировать шаблоны доступа к памяти; например, включение встроенных функций загрузки/сохранения SSE2 или других оптимизаций. Вы также можете сравнить результаты с компиляторами gcc и fortran от Intel.

person E. Anderson    schedule 29.07.2014