Если у вас на машине стрелочка показывает, что у вас осталась половина бака, то у вас точно осталась половина бака? На самом деле больше, так как современные машины врут и топлива еще немного есть, даже когда стрелка на нуле - забота об альтернативно одаренных водителях. А если сервер показывает 50% cpu, то сколько ресурсов у нас осталось?
Для многих ответ ясен, и это не 50%. Поэтому извините, если многие вещи будут вам очевидны. А вот для менеджеров, например, которые планируют ресурсы, это может быть открытием.
Сразу скажу, что эффект ярче проявляется на больших серверах - монстрах с 256 - 1 - 2Tb RAM и 40-48 cpu и более. На маленьком домашнем компе и питоновском скрипте в один тред вы его точно не прочувствуете. Как о примере больших серверов мы будем говорить о серверах баз данных (остальные сервера легко шардить), в частности, о MS SQL
Итак, когда сервер сильно нагружен (cpu > 50%), то многие процессы работают медленнее. Вы хотите сказать, cпасибо, кэп? Не торопитесь. Прикол не в том, что они работают медленее в секундах - это было бы понятно, ожидание диска, ожидание cpu. Прикол в том, что процессы начинают жрать больше cpu! Вот так, самым натуральным образом!
Здесь проявляются два эффекта. Первый связан с паразитным потреблением cpu. Например, часть latch waits в MS SQL являются нормальными ожиданиями (например ожидание диска, PAGEIOLATCH), часть же более 'быстрых' latches являются классческими spin locks, например, PAGELATCH. При конфликтах по страницам все больше cpu создается этими spin locks.
Чем больше spin locks, тем больше cpu, тем медленнее вставки, тем больше spin locks! Здравствуй, положительная обратная связь и metastable failure state ! Впрочем, и без PAGELATCH мы можем перегрузить scheduler, в котором есть и spin locks и вызов getTimePrecise со сменой контекста и переходом в ядро ОС, о таких эффектах я писал тут.
Впрочем, скриншот со временем выше получен от выполнения natively compiled функции, которая проверяет число на простоту. Там нет ни вызова scheduler после каждой строки (проклятия обычного кода на T-SQL), ни IO, ничего кроме, собственно, вычислений. Почему же она стала потреблять больше CPU?
Вспомним про кеши процессора разных уровней. Вспомним про то, как изменение порядка обхода двумерного массива [x,y] (по какой переменной внешний цикл) может ускорить или замедлить выполнение в разы. Собственно, MS SQL это кошмар для системы кеширования - работает сервер с терабайтом ОЗУ, и даже если горячее множество buffer pool 10% от общего объема, то есть 100Gb во много раз превышает все кеши, часть из которых еще и дробятся между многими ядрами. А если взять DWH/reporting server, который реально этот теребайт сканирует full scanом, то вообще туши свет...
Жаль что параметры memory cache misses можно измерить только специальным оборудованием с платы, но я уверен, что базы данных - самые ужасные программы с точки зрения cache misses (может кто-нибудь умеет измерять такие вещи?)
Я также уверен что cross NUMA memory channel на DB серверах перегружен - да, MS SQL сервер "NUMA aware", то есть строит политики переключения threads с учетом NUMA, но вот BUFFER POOL вещь общая и рандомная, и если нужная страница уже в памяти, то в твоей памяти или в памяти другого NUMA - это как повезет (и, кстати, с учетом скорости современных NVMe - не быстрее ли прочитать такую страницу с диска а не с соседнего NUMA? Честно, не знаю)
Но что еще? О чем мы думаем, когда видим очень много cpu cores? Да, конечно о hyperthreading. И втором конвейере, который дает некоторый прирост производительности, но это совсем не то, что "честный" второй процессор. Поэтому, на hyperthreaded серверах "вторые" 50% cpu - это чистый обман (но "в партии не дураки сидят" (c), системы естественно пытаются вначале использовать настоящие ядра).
Я провел эксперимент - программа вычисления простого числа запускалась на сервере, и потом я собрал статистику за долгое время:
Очевидна деградция производительности при высоком CPU, хотя лично я ожидал более резкого перегиба графика в районе 50%. Ну это можно исправить, chatGPT, сгенери мне набор данных где резкая деградация начинается... Ладно, ладно, поступим как ученый старой школы и запостим что есть.
В среднем деградация составляет 60%, но в моменте бывает до трех раз (и снова встречаем положительную обратную связь).
Кстати, при высоком CPU MS SQL server пугается и делает вот так:
и выключает QueryStore (переводит в read only режим). Далее могут наблюдаться проблемы с sp_whoisactive и если все совсем плохо, то даже с тривиальным select * from sysprocesses
В итоге имеем:
Комментарии (63)
Sild
29.10.2024 12:19Однажды напоровшись на схожую картину отключили гипертрединг на уровне приложения (благо плюсы позволяют), и вешали нагрузку только на физические ядра - иначе p99 начинал скакать как не в себя при нагрузке выше 70% cpu. Выбрали стабильность. Не представляю как нужно разложить обработку данных чтобы гипертрединг делал что-то полезное, когда он действительно становится нужен.
Вообще 50% это как-то маловато (но возможно и справедливо). Из того что видел - около 85% на практике это потолок, дальше непонятные спайки и перегрев
5exi
29.10.2024 12:19На мощных задач он только мешает. И если уж стали жить с HT, то надо учитывать что с 60% начинается деградация сервиса. И это всё уже описано, все эти рекомендации по отключению всех этих оптимизаций на тяжёлых серверах.
unreal_undead2
29.10.2024 12:19отключили гипертрединг на уровне приложения (благо плюсы позволяют)
Это как? Может, просто задействовали число потоков, равное числу физических ядер?
Sild
29.10.2024 12:19Отчасти: через cpu_affinity перестали прибивать потоки к гипертредным ядрам. Ну и да, по факту это ограничило количество cpu-bound потоков количеством ядер (были еще не-cpu-bound, которых по сотне на ядро лежало)
unreal_undead2
29.10.2024 12:19Нюанс в том, что при включенном гипертрединге некоторые ресурсы CPU (скажем, reorder buffer) статически делятся между логическими ядрами, так что один поток на ядре получает меньше, чем при выключенном HT.
Sild
29.10.2024 12:19Мы пробовали отключать ht через конфигурацию ядра - это не оказывало существенного влияния на производительность на наших задачах (оценка была методом "ну латенси и загрузка cpu вроде такие же". Перезагружать после этого тоже пробовали :D ). Так что в итоге оставили включенным для большей гибкости.
unreal_undead2
29.10.2024 12:19пробовали отключать ht через конфигурацию ядра
Вообще то оно в BIOS включается/выключается. Ядро линукса может скрыть дополнительные логические ядра процессора, но на разделение ресурсов это не влияет.
wataru
29.10.2024 12:19Вряд ли это и для серверов также важно, как для лаптопов, но еще один важный фактор - перегрев. Когда процессор нагружен салобо, он может разгонять ядра. Когда работают все ядра, теплоотведение не справляется и всё начинает дико троттлить. И в итоге все N ядер суммарно выполняют меньше операций, чем когда было загружено N/2 ядер.
Fahrain
29.10.2024 12:19Тут есть другой нюанс: например, на ксеонах время переключения в режим турбобуста в разы больше, чем на десктопных процессорах. Если у нас "холодный" процессор - то, значит, и нагрузки на нём, считай, нет. Т.е. в итоге на таком малонагруженном сервере с очень короткими всплесками нагрузки на процессор получится так, что он будет постоянно сидеть на базовой частоте, которая очень маленькая на ксеонах.
В общем, и греть нельзя и не греть нельзя)
GidraVydra
29.10.2024 12:19Пустите майнер во второй поток, чтобы постоянно проц прогревал)
Volodichev
29.10.2024 12:19Зеоны умеют бустить отдельные ядра. А нагружать майнером все ядра - плохая идея.
Да и не все зеоны умеют бустить проц целиком. У многих старых зеонов до максимальной частоты может добраться только одно ядро. Как на новых - не знаю.
mvv-rus
29.10.2024 12:19Я однажды у себя в ПК так отказ вентилятора на процессоре увидел - он и до того работал неслышно, а тут резко заклинил, что тоже неслышно. Мое внимание привлекло, что что-то компьютер на тех же задачах стал тормозить и жрать много процессора. Причина - тот самый пропуск тактов из-за перегрева.
konst90
29.10.2024 12:19А у меня наоборот, завывание кулера - знак того, что идёт расчёт. Компьютер затих - ага, можно идти смотреть результаты.
edo1h
29.10.2024 12:19Насколько я знаю, лимиты питания срабатывают и без перегрева
wataru
29.10.2024 12:19В лаптопах часто узкое место не лимиты по питанию, а температура. Особенно в старых макбуках. И вот когда он перегреется - тут начинается кошмар, все ядра еле крутятся и в этом состоянии оно может быть весьма долго, даже если вы попытаетесь нагрузку снизить.
poige
29.10.2024 12:19Ну вас ещё много открытий впереди, осталось как минимум почитать статью Б. Грега, где он объяснит, что то, что многие привычно видят как нагрузку на процессор, на самом деле является его простоем.
Tzimie Автор
29.10.2024 12:19Ну я писал тоже писал про ожидания памяти. Вот интересно, под виндой можно увидеть те же характеристики как автор пишет про Linux?
saboteur_kiev
29.10.2024 12:19Насколько мне кажется, под Виндой в среднем можно увидеть больше, так как винда собирает чуть больше метрик по дефолту, чем Линукс. Но и тратит на это больше cpu. Условно запустить и остановить 1000 мелких процессов - на Линукс займет меньше времени, чем на Windows.
В Линуксе без спец средств посчитать что-то на уровне что именно делал процессор в течение секунды - нереально. Слайсы выделяемые на процесс 10-15 мс, максимум что можно попробовать посчитать. Но точно ли процесс свой слайс загрузил по полной или частично - уже вообще несчитаемо. Надо ядро перекомпилировать с какими-то отладочными вещами, которые естественно сами по себе будут нагружать.
erley
29.10.2024 12:19Вот только хотел про это написать, опередили :-)
Делал презентацию нащим менеджерам на прошлой неделе, они не понимают что такое throttling cpu. В современных кубернетесах можно хорошо так загубить производительность если не понимать как проц слайсится.
ris58h
29.10.2024 12:19Делал презентацию нащим менеджерам на прошлой неделе, они не понимают что такое throttling cpu.
А зачем им это понимать? Или менеджер - это CTO?
erley
29.10.2024 12:19У нас нет СТО, у нас board of architects, только они уже меньше тех вопросами занимаются чем принято считать. С менеджерами "которым не нужно понимать" технические детали инженер у нас даже не разговаривает.
Вообще-то это тема важная, потому что одни могут соптимизировать расходы на cloud инфраструктуру, а другие сделать более оптимальныйи красивый дизайн и развеску нагрузок.
Хотя это всё тема другой большой дискуссии...
event1
29.10.2024 12:19Жаль что параметры memory cache misses можно измерить только специальным оборудованием с платы
Есть специальное приложение от известного производителя процессоров. В линуксе есть perf
vkni
29.10.2024 12:19Если у вас на машине стрелочка показывает, что у вас осталась половина бака, то у вас точно осталась половина бака? На самом деле больше,
Мой опыт показывает, что на самом деле меньше. По крайней мере, на старых машинах очень часто заправляешь машину, очень долго ездишь на первой четверти бака, а то и вообще "не тратя бензин", а потом, когда остаётся половина, бензин начинает расходоваться очень быстро.
vkni
29.10.2024 12:19Кстати, прыгая тут по ссылкам только что нашёл очень интересное эссе про метод анализа подобных систем, где производительность деградирует при высокой утилизации - https://www.brendangregg.com/usemethod.html
Из серии "они забыли больше, чем мы когда-либо знали".
voted
29.10.2024 12:19Есть ещё один кейс когда 50% не 50%.
Столкнулся недавно с подобным на Azure Managed SQL, так там ещё прикольнее вышло. Есть такая B-серия у них, в описании написано:Семейство виртуальных машин серии «B» - это один из экземпляров виртуальных машин общего назначения в Azure. В то время как традиционные виртуальные машины Azure обеспечивают фиксированную производительность ЦП, виртуальные машины серии B - единственный тип ВМ, использующий кредиты для предоставления производительности ЦП. В виртуальных машинах серии B используется модель кредитов ЦП для отслеживания количества потребляемого ЦП - виртуальная машина накапливает кредиты ЦП, когда рабочая нагрузка работает ниже базового порога производительности ЦП, и использует кредиты при работе выше базового порога производительности ЦП, пока все кредиты не будут израсходованы. Когда все кредиты ЦП израсходованы, виртуальная машина серии B возвращается к базовой производительности ЦП до тех пор, пока не накопит кредиты для повторной загрузки ЦП.
А так же уточняется что для БД небольшого размера (прям как у меня) это отличный вариант, но как водится детали не менее важны.
Скрытый текст
Оказалось что "порог производительности ЦП" это не 100% от моего купленого vCPU а 20% от его возможностей, из которых к слову около 17% кушают встроенные сервисы подсчёта этих кредитов. И когда нагрузка в среднем была мои 2% + 17% сервисы азура, то всё было более менее не плохо, а как только моей нагрузки стало 4% ядра то кредиты закончились за 2 дня и теперь задачи по крону которые выполнялись за 1 минуту каждые 5 минут стали выполняться 12 минут (запуск всё ещё каждые 5 минут). Вообщем на будущее читайте внимательно про условия тротлинга (к слову для Азура это не применимо, я специально искал где написано про эти условия и я этого не нашёл для своего арендованого сервера)
navion
29.10.2024 12:19В AWS и Azure почти все типы инстансов считают vCPU как поток в HT, а не ядро PCPU.
vanxant
29.10.2024 12:19я уверен, что базы данных - самые ужасные программы с точки зрения cache misses
Ну, нет. Всякая вычислительная математика и физика, от прочностных расчётов в солидоле до не знаю там процессов теплопереноса в двигателях и атомных реакторах (hydroflow, logos, etc). Там в конечном счёте задачи сводятся к решению гигантских СЛАУ (систем линейных уравнений), где каждая дополнительная точка "разрешения" это дополнительная переменная в СЛАУ. Собственно, рейтинги суперкомпьютеров не зря меряют тестом LINPACK, который как раз эти СЛАУ и решает.
Каждая точка зависит только от нескольких своих соседей. Хорошо реализованный алгоритм читает каждую точку из памяти один раз за проход и потом один раз за проход записывает. Т.е. кэш на этом этапе как бы вообще в холостую работает. Но это полбеды.
Дальше, огромная матрица СЛАУ режется на прямоугольные куски, каждый из которых отдаётся своему процессору. Пока процессоров относительно немного, скорость вычислений упирается в их производительность. Проблема в том, что процессоры, обрабатывающие соседние куски матрицы, должны синхронно обмениваться свежими результатами на границах кусков. И хотя на первый взгляд объём "границ" линеен против квадратичного объёма содержимого "кусков", но на самом деле он также линеен относительно количества процессоров. Поэтому, начиная с некоторого количества CPU общая производительность упирается уже в межпроцессорные передачи и те самые кэши L2/L3 и их инвалидацию.
Tzimie Автор
29.10.2024 12:19А если куски резать на узкие вертикальные полосы? Тогда у каждого обработчика только два соседа, хотя и границы длинные
vanxant
29.10.2024 12:19Из всех прямоугольников заданной площади минимальным периметром обладает квадрат.
И да, если уж резать на полосы, тогда эффективнее на горизонтальные. Тогда границы хотя бы будут лежать в ОЗУ одним непрерывным куском, который читать-писать намного быстрее, чем по одному слову памяти (16 байт) вертикальных границ.
unreal_undead2
29.10.2024 12:19Собственно, рейтинги суперкомпьютеров не зря меряют тестом LINPACK
LINPACK как раз таки достаточно эффективен в плане количества вычислений на один доступ к памяти и флопсы, которые он показывает, достаточно близки к теоретическому максимуму (что видно в данных Top500). Но реальный код да, очень часто memory bound (и LINPACK - не такая уж адекватная оценка, но лучшего не придумали).
Хорошо реализованный алгоритм читает каждую точку из памяти один раз за проход и потом один раз за проход записывает.
С точки зрения математического описания алгоритма входные точки зачитываются несколько раз для расчёта разных выходных. Чтобы минимизировать чтение из DRAM и приблизиться к идеалу "зачитать один раз", как раз таки и нужны кеши (и написанный с их учётом алгоритм).
Проблема в том, что процессоры, обрабатывающие соседние куски матрицы, должны синхронно обмениваться свежими результатами на границах кусков.
Есть ещё более медленный обмен между нодами в кластере. LINPACK'у и это не так страшно, но в реальной жизни часто затраты на обмен между узлами сравнимы с вычисленияим на узле.
0xdead926e
29.10.2024 12:19Жаль что параметры memory cache misses можно измерить только специальным оборудованием с платы
про кэшмиссы и даже всякие миспрефетчи запросто расскажет процессор, если его попросить. например, дефолтный линуксовый perf (c -e cache-misses,cache-references), или какой-нибудь vtune все покажут и расскажут.
если хочется прям совсем глубоко- то можно накостылять свое поверх intel processor trace. очень удобная штука для отладки многопоточщины.
edo1h
29.10.2024 12:19и, кстати, с учетом скорости современных NVMe - не быстрее ли прочитать такую страницу с диска а не с соседнего NUMA? Честно, не знаю
Нет, конечно же. Задержки обращения к памяти соседей ноды numa сотни наносекунд, лучшие задержки накопителей — десятки микросекунд. Разница на два порядка.
И да, где гарантии того, что накопитель не окажется на другой ноде?
Поэтому, на hyperthreaded серверах "вторые" 50% cpu - это чистый обман
А вот и нет. Как раз нагрузка с большим числом ожиданий, о которой вы пишете выше, идеальна для SMT. Пока одно виртуальное ядро ждёт данных от памяти, второе на том же железе что-то исполняет.
У IBM в процессорах давно есть не только SMT2 (то, что Intel называет hyperthreading), но и SMT4 и даже SMT8.
Слухи о том, что и в x86 появится SMT4, ходят давно, но пока не складывается. Возможно, дело в том, что и так упёрлись в потребление/тепловыделение, повышать утилизацию жрущих блоков процессора бессмысленно. А может быть для эффективного использования надо наращивать регистры/кэши, что оказалось накладно и/или технически сложно.
GidraVydra
29.10.2024 12:19Тут какбы большой вопрос откуда дровишки, и не связано ли увеличение времени с тем, что узкое место образуется где-то например по дороге к памяти. В этом случае HT наоборот как мана небесная. Кстати, линейная зависимость времени от загрузки без перегиба в районе 50% свидетельствует именно об этом. Если бы это была положительная обратная связь внутри камня, функция, была бы более быстрорастущая, чем линейная.
markshevchenko
29.10.2024 12:19Беда автора, что у него не откалибрована сложность материала. Пишет, мол, простите за очевидные вещи, а потом начинает тарабарить. Я могу из общих соображений догадаться, что такое PAGELATCH, но я не знаю, что такое NUMA и как-то смутно представляю себе BUFFER POOL. При этом я долго работал с MS SQL и как раз поэтому не очень хорошо представляю себе, что там сейчас творится на низком уровне.
Хотелось бы в общих чертах понимать, как что устроено и почему это плохо. Да, в паре мест есть ссылки на другие материалы, но это означает, что для того, чтобы понять статью, нужно прочитать ещё пару других статей приличного размера.
Тогда о какой очевидности речь?
slonopotamus
29.10.2024 12:19PAGELATCH, BUFFER POOL и прочие умные слова сюда притащены для того чтобы завалить читателя терминологией и отвлечь его от главной проблемы текста - в нём нет доказательства что дело сублинейного роста именно в тех причинах, о которых нам вещает автор.
netch80
29.10.2024 12:19Хохму с дракой за спинлоки я помню ещё в районе 2000 года. Сервер БД для хостинга поставили на MySQL на Linux, и увидели, что если в локи входят несколько одновременно клиентов, то их процессы начинают только и делать, что крутиться в ожидании освобождения, и в результате зависимость квадратичная от количества вошедших. Лечить это в коде мы тогда не могли, и мистическим образом улучшение настало от перевода на FreeBSD, где треды были сделаны на libc_r, старой и кривоватой, которая реально один системный процесс с переключением в юзерленде - и это работало лучше! Исправление наступило года через два с новыми версиями всего.
Реально такие нелинейные росты это основная проблема любой загрузки чего-то.
saboteur_kiev
А если это не базы данных, а рендеринг или другие вычисления?
Мне кажется у вас почти вся статистика о базе данных, где не столько CPU, сколько траффик. Трафик связанных как со storage так и памятью. Кроме того траффик, связанный со storage/network вообще может косвенно нагружать CPU (kernel space ибо драйвера).
Можете уточнить как именно вы меряли?
Tzimie Автор
Я связан с базами, а рендерингом чуть менее чем никак) и на базе тоже может быть CPU если на стороне сервера много бизнес логики
saboteur_kiev
Так хотелось бы понять, если это будет вычисления бизнес логики, то тоже будут именно такие 50% CPU?
Если ОС выполняет много процессов параллельно, то понятно что system usage для переключения будет занимать определенный процент, который явно больше, чем если у нас несколько процессов.
Если ОС выполняет множество операциый связанных с IO, то там большой процент завязан на работу с устройствами. В Линукс это может считаться как CPU LOAD, в Windows не подскажу, но это тоже часть CPU LOAD которую будут возлагать на драйвера, а не IDLE
Поэтому и хотелось больше технических деталей о том как проводилось тестирование, типы данных, типа тестов...
В современном мире вообще performance тестирование, если начинаешь копать, и обнарживаешь количество подуровней различной виртуализации и хардварной оптимизации, которую нужно учитывать, то можно застрелиться....
Tzimie Автор
Это был тест на живую) на prod server. Данный сервер cpu-bound а основном, много логики на функциях и они жрут cpu
mvv-rus
В Windows загрузку CPU берут со счетчиков ядра для Performance Monitor, а там есть отдельные счетчики не просто для kernel time, но и для частей ядра - interrupt time (обработка прерываний) и DPC time (это процедуры отложенного вызова, асинхронщина ядра, по большей части они тоже для ввода/вывода т.к. он в Windows целиком асинхронный). И иногда это разделение полезно: например большой interrupt time% - это явный признак неисправного устройства, которое генерит прерывания как не в себя.
И, вообще-то даже Диспетчер задач несложно заставить отображать время ядра кроме общей загрузки процессора.
BugM
Я пришел к выводу что в современном мире имеют смысл только две метрики скорости работы. Скорость работы конкретной чистой функции или алгоритма без IO. И скорость работы всей системы целиком при типичной нагрузкой. Сумма времен ответов сервера на типичной нагрузке или средний fps игры для стандартного маршрута в ней.
Все промежуточные метрики очень шумят и часто показывают погоду на Марсе вместо реальной скорости работы заметной пользователю.
killyself
Я бы еще смотрел не только на среднюю скорость, но и что то в духе "реалистично плохой вариант". Был случай когда функция в среднем работала за 2 секунды, что супер, но при более экстремальных входных данных (которые нашлись в реальной работе через месяц) начинала дико висеть работая по минуте и более (что уже оказалось недопустимо и пришлось оптимизировать в срочном порядке).
unreal_undead2
Если важно время ожидания конкретного запроса - конечно надо смотреть на всяческие персентили.
lex899
Рендер by design рассчитан на 100% загрузку cpu/gpu. Разумеется все зависит от движка и эффектов и на практике далеко не всегда работает с полной загрузкой. Если ограничить движок 1 ядром - кадр будет считаться быстрее за счёт boost, но лучше медленно считать 8 кадров разом чем быстро 1.
bezdnacom
Во-первых, 100% загрузка CPU и GPU невозможна. Во-вторых, параллельно несколько кадров никто не считает.
lex899
А какая возможна? 99.9?...
Запрещено законом? Неэффективно? Не знаю, у меня multiframe rendering включён.
bezdnacom
Если у вас CPU загружен на 100%, то GPU простаивает и наоборот
Да, синхронизация нарушится
Про всю эту тему был давно отличное видео
datacompboy
для VR очень даже надо рендерить два кадра одновременно.
bezdnacom
VR, КМК, это немного другая история потому что между двумя кадрами разница только в позиции камеры. Но как там работает рендер я если честно не знаю.
slonopotamus
Только, хех. Эта мелочь заставляет повторно отрисовывать почти всё.
lex899
Возможно вы говорили про игры а я про "рендер или другие вычисления"?
Если речь про рендер - в качестве простого примера опровергающего ваши слова могу привести
кодирование последовательности jpeg2000 - хорошо параллелится, успешно считается и на gpu и на cpu, загружает и то и то на 100%
upscale видео с применением нейронки
любая задача на чистый gpu рендер станет чуть быстрее с подключением cpu и даст 100% утилизацию
Но есть нюансы
самая частая причина не подключать cpu - заметная на глаз разница между кадрами рассчитанными на gpu и cpu;
или у вас такой проект что видеокарты считают кадр за минуту а процессор за 30 минут, в среднем вы будете ждать 15 минут с простаивающими видеокартами в конце рендера пока процессор завершит свой последний кадр, при малом количестве кадров проц выгоднее исключить. Такие же хвосты образуются когда в ферме используются карточки или узлы сильно разной производительности.
При большом разрыве производительности (например 6 карт и слабый проц) тоже считают на чистом gpu.
bezdnacom
Да, я уже после того как написал комментарий понял о чем вы, но справедливости ради из вашего комментария не было понятно о каком конкретно рендере идет речь.
lex899
Согласен, в играх все работает не совсем так. Может быть это профдеформация, но я не предположил что в обсуждении статьи про сервера уровня "256 - 1 - 2Tb RAM и 40-48 cpu" может зайти речь про игровой рендер. Даже если бы вы упомянули например Unreal Engine - я бы не догадался что речь про игры.
slonopotamus
Когда непонятно, можно спросить
etofiasko
хз трафик или щто а если дб там же где и апп лежит на одном сервере то токда нагружается всё кроме сети
anka007
Мне кажется, что на базах данных вообще самое узкое место - доступ в память. В СХД вообще процессор не главная характеристика. Жаву с ёё библиотеками тянет и ладно.