Я не уверен, что serverfault — подходящее место для этого вопроса, но мне интересно, какой выбор вы бы сделали, если бы вам пришлось выбирать новый тип ЦП для вашего веб-приложения Java:
а) процессор с 32 ядрами и тактовой частотой 2,5 ГГц
или
б) процессор с 8 ядрами, но тактовой частотой 3,8 ГГц
Учитывая тот факт, что каждый входящий HTTP-запрос веб-приложения обслуживается свободным потоком Java, может иметь смысл выбрать a), поскольку вы можете обрабатывать в четыре раза больше HTTP-запросов одновременно. Однако, с другой стороны, CPU b) может завершить обработку одного HTTP-запроса гораздо быстрее...
Что вы думаете?
Заметки на полях:
- это должна быть физическая машина, виртуальные машины или облачные решения в этом случае не подходят
- Оперативная память не важна, в конечном итоге на сервере будет 512 ГБ оперативной памяти.
- Кэширование: веб-приложение Java имеет обширную структуру кэширования, поэтому выбор действительно зависит от процессоров.
решение1
вкратце;Реальный ответ, вероятно, "больше оперативной памяти", но поскольку вы задали свой вопрос, ответ, конечно, зависит. С другой стороны, 32 ядра @2.5Ghz почти наверняка победят 8 ядер @3.8Ghz - это в 4 раза больше ядер против в 1.5 раза более высокой тактовой частоты. Не очень честная борьба.
Следует учитывать несколько факторов: время отклика транзакции, количество одновременных пользователей и архитектуру приложения.
Время отклика транзакции Если ваше Java-приложение отвечает на большинство запросов в течение нескольких миллисекунд, то, вероятно, лучше иметь больше ядер для обработки большего количества одновременных запросов. Но если ваше приложение в основном обрабатывает более длительные, более сложные транзакции, оно может выиграть от более быстрых ядер. (или нет - см. ниже)
Одновременные пользователи и запросы Если ваше Java-приложение получает большое количество одновременных запросов, то больше ядер, вероятно, поможет. Если у вас не так много одновременных запросов, то вы можете просто платить за кучу дополнительных простаивающих ядер.
Архитектура приложения Те длительные запросы, о которых я упоминал, не получат особой выгоды от более быстрых ядер, если сервер приложений тратит большую часть времени транзакции на ожидание ответов от веб-сервисов, баз данных, Kafaka/MQ и т. д. Я видел множество приложений с транзакциями длительностью 20–30 секунд, которые тратили лишь небольшую часть времени ответа на обработку в самом приложении, а остальное время — на ожидание ответов от баз данных и веб-сервисов.
Вам также нужно убедиться, что различные части вашего приложения хорошо сочетаются друг с другом. Не будет большой пользы, если 32 или 64 потока, каждый из которых обрабатывает запрос, будут стоять в очереди в ожидании одного из 10 подключений в пуле JDBC, то есть свинья в проблеме Python. Немного планирования и проектирования сейчас избавит вас от многих проблем с производительностью в будущем.
И последнее - какие процессоры вы вообще можете сравнивать? Самый дешевый 32-ядерный 2,5 ГГц процессор, который я смог найти, стоит как минимум в 3 или 4 раза дороже, чем любой 8-ядерный 3,8 ГГц процессор.
решение2
Если ваш веб-сервер Java настроен соответствующим образом, вам следует выбрать больше ядер.
Все еще есть зависимости, такие как семафоры, параллельные доступы, которые все еще будут иметь некоторые потоки ожидания, независимо от количества ядер или скорости. Но лучше, когда это управляется ЦП (ядрами), чем ОС (многопоточностью).
И в любом случае, 32 ядра @2,5 ГГц будут обрабатывать больше потоков и лучше, чем 8 ядер @3,8 ГГц.
Кроме того, тепло, выделяемое процессором, зависит от частоты (помимо прочего), и это нелинейно. Это означает, что 3,8 ГГц будет генерировать больше тепла, чем 3,8/2,5 x (должно быть подтверждено на основе точных типов/брендов ваших процессоров... многие сайты предлагают подробную информацию).
решение3
Вы сообщаете нам, что выполнение запроса занимает около 100–200 мс, и что в основном это время обработки (хотя сложно отделить фактическую работу ЦП от реального доступа к памяти), очень мало операций ввода-вывода, ожидания баз данных и т. д.
Вам придется измерить, сколько времени на самом деле займет выполнение задачи на каждом из двух процессоров, но предположим, что на более медленном процессоре (с 32 ядрами) это займет 150 мс, а на более быстром (всего с 8 ядрами) — 100 мс.
Тогда первый процессор сможет обрабатывать до 32/0,15 = 213 запросов в секунду.
Второй ЦП сможет обрабатывать до 8/0,1 = 80 запросов в секунду.
Итак, главный вопрос: сколько запросов в секунду вы ожидаете? Если вы далеки от десятков запросов в секунду, то вам не нужен первый процессор, а второй даст вам более быстрое время выполнения каждого запроса. Если вам нужно более 100 запросов в секунду, то первый имеет смысл (или, возможно, даже более разумно иметь более одного сервера).
Обратите внимание, что это очень приблизительные оценки. Единственный способ узнать наверняка — протестировать каждый из серверов с реальной нагрузкой. Как указано выше, быстрые ЦП или ЦП с большим количеством ядер могут быстро начать испытывать нехватку доступа к памяти. Размер различных кэшей ЦП здесь очень важен, как и «рабочий набор» каждого запроса. И это с учетом действительно ограниченной ЦП работы, без системных вызовов, общих ресурсов, ввода-вывода...
решение4
Предварительное замечание
Я хотел бы поддержать@ВозможноПолезноВозможноНе'sопределенно полезный ответ.
tldr; Реальный ответ, вероятно, «больше оперативной памяти»
Особенно этот момент.
Предостережение
Не то чтобы я был администратором в чистом виде.
Скорее, специалистом по программной инженерии.
Нет альтернативы измерению
Что мы знаем
Итак, машина
- собираюсь запустить (Enterprise?) Java-based backend-приложение своего рода
- публично (во всяком случае, в рамках некоторого значительного контекста) предоставить HTTP API для обработки клиентских запросов
- предположительно с некоторой формой прикрепленной базы данных
- в противном случае описывается как не очень привязанный к вводу-выводу
- не зависит от доступности, задержки или пропускной способности сторонних сервисов
Не такая уж и неопределенная картина, которую рисует ОП. Но в то же время далеко не достаточно данных, чтобы дать ответотносительно индивидуальной ситуации ОП.
Конечно, 32 ядра на 2/3 тактовой частоты - этовероятныйдля производительности лучше, чем 1/4 ядер при сравнительно небольшом преимуществе в скорости. Конечно, выделяемое тепло не масштабируется хорошо при тактовых частотах выше порога 4 ГГц. И конечно, если бы мне пришлось слепо класть яйца в одну корзину, я бы выбрал 32 ядра в любой день недели.
Чего мы не знаем
Но все равно слишком много.
Однако,за пределами этих простых истин я бы очень скептически отнесся к гипотетической попытке более конкретного и объективного ответа. Иффэто возможно (и у вас есть веские причины оставаться убежденным в том, что количество операций в единицу времени — это обоснованная проблема), возьмите в руки оборудование, на котором вы собираетесь запустить систему,измеряйте и тестируйте его, от начала до конца.
Анобоснованное решениевключает в себя соответствующиеидостоверные данные.
ОП написал: Оперативная память не важна
В подавляющем большинстве случаев памятьявляетсяузкое место.
Конечно, ОПв первую очередь спрашивает оЯдра ЦП и тактовая частотаи таким образом память оказывается на грани того, чтобы быть не по теме.
Я так не думаю. Мне кажется, что вопрос скорее основан на ложной предпосылке. Не поймите меня неправильно, @OP, ваш вопрос по теме, хорошо сформулирован, и ваше беспокойство, очевидно, реально. Я просто не уверен, что ответ на вопрос, какой процессор будет работать «лучше» в вашем варианте использования, вообще имеет значение (для вас).
Почему память важна (для ЦП)
Основная память - этомучительно медленно.
Исторически сложилось так, что по сравнению с жестким диском мы склонны считать RAM «быстрым типом хранилища». В контексте этого сравнения это по-прежнему верно. Однако в течение последних десятилетий скорость процессоров постоянно росла значительно более быстрыми темпами, чем производительность DRAM. Это развитие со временем привело к тому, что обычно называют«Процессор-Память-Разрыв».
Разрыв между скоростями процессора и памяти (источник: Карлос Карвалью, Департамент информатики, Университет Минью)
Извлечение строки кэшаиз основной памяти в регистр ЦП занимает примерно ~100 тактоввремени. В течение этого времени ваша операционная система будет сообщать об одном из двух аппаратных потоков в одном из 4 (?) ядер вашей архитектуры x86 какзанятый.
Что касаетсядоступностьэтого потока оборудования, ваша ОС не лжет, оназанят ожиданием. Однако сам процессор, не обращая внимания на ползучую к нему строку кэша,де-факто простаивает.
Никаких инструкций/операций/расчетов за это время не выполнялось.
+----------+---------------+---------------------------------------------------------------------------------------------------+
| Type of | size of | Latency due to fetching a cache line |
| mem / op | cache +--------+--------+------------+--------------------------------------------------------------------+
| | (register) | clock | real | normalized | now I feel it |
| | | cycles | time | | |
+----------+---------------+--------+--------+------------+--------------------------------------------------------------------+
| tick | 16KB | 1 | 0.25ns | 1s | Dinner is already served. Sit down, enjoy. |
| | *the* 64 Bits | | | | |
+----------+---------------+--------+--------+------------+--------------------------------------------------------------------+
| L1 | 64KB | 4 | 1ns | 4s | Preparations are done, food's cooking. |
| | | | | | Want a cold one to bridge the gap? |
+----------+---------------+--------+--------+------------+--------------------------------------------------------------------+
| L2 | 2048KB | 11 | ~3ns | 12s | Would you be so kind as to help me dice the broccoli? |
| | | | | | If you want a beer, you will have to go to the corner store. |
+----------+---------------+--------+--------+------------+--------------------------------------------------------------------+
| L3 | 8192KB | 39 | ~10ns | 40s | The car is in the shop, you'll have to get groceries by bike. |
| | | | | | Also, food ain't gonna cook itself, buddy. |
+----------+---------------+--------+--------+------------+--------------------------------------------------------------------+
| DRAM | ~20GB | 107 | ~30ns | 2min | First year of college. First day of the holiday weekend. |
| | | | | | Snow storm. The roommate's are with their families. |
| | | | | | You have a piece of toast, two cigarettes and 3 days ahead of you. |
+----------+---------------+--------+--------+------------+--------------------------------------------------------------------+
Показатели задержки
Core-i7-9XXчипов серии (источник: Скотт Мейерс, 2010)
Нижняя граница Если надлежащее измерение невозможно, вместо того, чтобы обсуждать ядра и тактовую частоту,самая безопасная инвестиция для избыточного аппаратного бюджета — это размер кэша процессора.
Итак, если память регулярно простаивает отдельные аппаратные потоки, то, наверное, решением будет увеличение количества ядер ~cow bell~?
Теоретически, если бы программное обеспечение было готово, многопоточность/гиперпоточностьмогбыть быстрым
Предположим, вы просматриваете налоговые декларации (например) за последние несколько лет, скажем, за 8 лет данных в общей сложности. Вы храните 12 ежемесячных значений (столбцов) в год (строку).
Теперь байт может содержать 256 отдельных значений (поскольку его 8 отдельных двоичных цифр могут принимать по 2 состояния каждое, что приводит к 8^2 = 256перестановкам различных состояний. Независимо от валюты, 256 кажется немного низким значением, чтобы иметь возможность представлять верхнюю границу цифр заработной платы. Далее, ради аргумента, давайте предположим, что наименьший номинал («центы») не имеет значения (все зарабатывают целые числа основного номинала). Наконец, предположим, что работодатель знает о разнице в заработной плате между высшим руководством и постоянными сотрудниками и, следовательно, держит этих избранных в совершенно другой системе учета.
Итак, в этом упрощенном сценарии предположим, что удвоенный объем памяти, т. е. 2 байта (или «полуслова»), при использовании в unsignedформе, т. е. представляющей диапазон от [0, 2^16 = 65536), достаточен для выражения всех значений ежемесячной заработной платы сотрудника.
Итак, в выбранном вами языке / RDBS / ОС вы теперь держите матрицу (некую двумерную структуру данных, «список списков») со значениями одинакового размера данных (2 байта / 16 бит).
В, скажем, C++ это будет . Я предполагаю , std::vector<std::vector<uint16_t>>что вы бы использовали vectorof в Java также.vectorshort
Теперь, вотпризовой вопрос:
Допустим, вы хотите скорректировать значения за эти 8 лет с учетом инфляции (или какой-либо другой произвольной причины для записи в адресное пространство). Мы рассматриваем равномерное распределение 16-битных значений. Вам нужно будет посетить каждое значение в матрице один раз, прочитать его, изменить, а затем записать его в адресное пространство.
Имеет ли значение, как именно вы обрабатываете данные?
Ответ:да, очень даже. Если вы сначала перебираете строки (внутреннюю структуру данных), вы получите почти идеальную масштабируемость в среде параллельного выполнения. Здесь дополнительный поток и, следовательно, половина данных в одном, а другая половина в другом будут выполнять вашу работу в два раза быстрее. 4 потока? Прирост производительности в 4 раза.
Однако, если вы решили сначала заняться столбцами, два потока будут выполнять вашу задачузначительно медленнее. Вам понадобится около 10 параллельных потоков выполнения только для того, чтобы смягчить (!) негативный эффект, который только что имел выбор основного направления обхода. И пока ваш код работал в одном потоке выполнения, вы не могли измерить разницу.
+------+------+------+------+------+------+------+
| Year | Jan | Feb | Mar | Apr | ... | Dec |
+------+------+------+------+------+------+------+
| 2019 | 8500 | 9000 | 9000 | 9000 | 9000 | 9000 | <--- contiguous in memory
+------+------+------+------+------+------+------+
| 2018 | 8500 | 8500 | 8500 | 8500 | 8500 | 8500 | <--- 12 * 16Bit (2Byte)
+------+------+------+------+------+------+------+
| 2017 | 8500 | 8500 | 8500 | 8500 | 8500 | 8500 | <--- 3 * (4 * 16Bit = 64Bit (8Byte)
+------+------+------+------+------+------+------+
| ... | 8500 | 7500 | 7500 | 7500 | 7500 | 7500 | <--- 3 cache lines
+------+------+------+------+------+------+------+
| 2011 | 7500 | 7200 | 7200 | 7200 | 7200 | 7200 | <--- 3 lines, likely from the same
+------+------+------+------+------+------+------+ virtual memory page, described by
the same page block.
Автор поста написал: а) ЦП с 32 ядрами и тактовой частотой 2,5 ГГц
или
б) ЦП с 8 ядрами, но тактовой частотой 3,8 ГГц
При прочих равных условиях:
-->Примите во внимание размер кэша, объем памяти, возможности аппаратного обеспечения по предварительной выборке и работающее программное обеспечение, которое может фактически использовать параллелизм, — все это важнее тактовой частоты.
--> Даже без использования сторонних распределенных систем,убедитесь, что вы действительно не ограничены вводом-выводом в производственных условиях.Если вам необходимо иметь собственное оборудование и вы не можете позволить AWS / GCloud / Azure / Heroku / Whatever-XaaS-IsHipNow справиться с этой проблемой, потратьте деньги на SSD, на которых вы размещаете свою базу данных. Пока вы это делаетенетЕсли вы хотите, чтобы база данных работала на той же физической машине, что и ваше приложение, убедитесь, что сетевое расстояние (здесь также измерьте задержку) максимально короткое.
--> Выбор известной, проверенной, первоклассной библиотеки HTTP-сервера "Enterprise-level", которая, без тени сомнения, создана для параллелизма, сам по себе недостаточен. Убедитесь, что все сторонние библиотеки, которые вы запускаете в своих маршрутах, являются таковыми. Убедитесь, что ваш внутренний код также является таковым.
Виртуальные машины или облачные решения в данном случае не подходят.
Это я понимаю.
Существуют различные веские причины.
должно бытьафизическая машина [...]
[...] ЦП с 32 ядрами и тактовой частотой 2,5 ГГц
Но это не так уж много.
Ни AWS, ни Azure не изобрели распределенные системы, микрокластеризацию или балансировку нагрузки. Более болезненно настраивать на голом железе и без ресурсов в стиле MegaCorp, но выможетзапустите распределенную сетку кластеров K8 прямо в своей гостиной. А также инструменты для повторяющихся проверок работоспособности и автоматического предоставления ресурсов при пиковой нагрузке существуют для проектов с самостоятельным размещением.
ОП написал: Оперативная память не важна
Вот ~гипотетический~ воспроизводимый сценарий: включите zram в качестве вашего swapspace, потому что RAM дешева и не важна и все такое. Теперь запустите постоянную, интенсивно использующую память задачу, которая не приводит к частой подкачке. Когда вы достигнете точки серьезной инверсии LRU, ваш вентилятор станет шумным, а ядра вашего процессора нагреются - потому что он занят управлением памятью (перемещением мусора в и из swap).
ОП написал: Оперативная память не важна
На случай, если я недостаточно ясно выразился: я думаю, вам следует пересмотреть свое мнение.
Короче говоря?
32 ядра.
Подробнееявляетсялучше.