Комментарии 58
Да, будет и продолжение.
А какая богатая тема - приложение вот этого вот всего железячного к возможностям конкретных гипервизора\ОС\приложения... в свое время был сильно фраппирован результатом попыток запустить LAMP стэк "bare metal", предполагаю что изменилось с того времени немногое )))
Так оно про те самые NUMA ничего не знает примерно на всех уровнях. Нарезать гипервизором и приколотить кусками со всеми накладными расходами IRL эффективней вышло.
Сильно плюсую. Одним 3D-моделирование гонять, другим файловый архив хранить\собирать да почтой заниматься, третьим - несколько сотен логфайлов писать одновременно, с гарантией да транзакционную базу на мильён записей в реалтайм обновлять . Сильно разные требования. И как понять где граница возможностей железа, а где- здравого смысла проектировщика сервера.
Как же вы правы. Вот мы используем для 1С сервера на базе 12900K и 7950X и второй показывает себя с наилучшей стороны. Нагрузить Сервер 1С и баз данных на нём 40-ка пользователями УНФ нереально. Он справляется с кучей фоновых заданий и выполнением запросов для проведения документов и отчетов.
"Десктопные процессоры - это процессоры для однопроцессорных машин, причем максимум с двумя каналами памяти"
А эти серверные?
Нишевые процессоры с очень малой аудиторией, и очень высокой стоимостью. Которые в массе ни на что не повлияли и были дропнуты.
Как я понял, если процессор один, то это за сервер не считается? Но кто сказал что сервер - это только про много ядер и не про скорость, про высокую частоту, про отсутствие вот этих всех NUMA проблем и других падений производительности?
Под каждую задачу нужен свой подходящий инструмент. А не так что только перфоратор - это профессиональный инструмент, а шуруповерт - это что-то "домашнее".
Задачи могут быть разные. Кому-то нужен грузовик перевезти максимум груза за раз (максимальное число ядер внутри 1-2U корпуса и плевать на частоту ядер и задержки памяти). А кому-то нужно максимально быстрый и не сильно дорогой подвоз каких-то легких грузов. И если таких грузов будет больше - будет добавляться большее количество шустрых "мопедов", а не переход на один общий неповоротливый грузовик. Исключительно от применения и целей зависит выбор сервера.
Смысл статьи - обзор того, что является массовым и специфичным для серверов, и где обычно неопытные проектировщики делают ошибки.
В случае с однопроцессорными серверами NUMA точно так же может быть актуальна (не все процессоры 1 socket = 1 NUMA node). Но даже в случае отсутствия проблем с NUMA остается вопрос правильного наполнения памятью по каналам и возможности упереться в общую ПСП.
Если у вас однопроцессорный ненагруженный сервер и проблем нет - ну значит все прекрасно.
Думаю все всё понимают, даже скажу более в промышленном оборудовании, не только серверами едины. Замена промышленного оборудования на бытовое это классический quick win "эффективного" менеджмента, менеджеры показывают экономию в 100500 миллионов, выполняется KPI, какое-то время схема даже работает, а после проблему разгребают годами уже другие люди. Отсюда и эти восхитительные идеи в стиле, а давайте всё заменим на raspberry pi или сделаем резервный канал через GSM модем
Ох уж эти выводы из частного в общее...
длинный бородатый анекдот
Жил в деревне мужик и было у него три
сына.
Раз утром отец возвращается со двора и
говорит:
- У нас корову украли.
Старший сын: - Раз кто-то украл, значит ***.
Средний сын:
- Раз ***, значит из Марьинки.
Младший:
- Раз из Марьинки, значит Ванька Косой.
Пошли в Марьинку, поймали Ваньку, дали в
ухо: - Верни корову!
- Нет у меня коровы!
Дали еще раз:
- Верни корову!
- Нет у меня коровы! - Тогда пошли к мировому судье.
Приводят Ваньку к судье и говорят:
- Вот он у нас корову спиздил.
- А почему вы решили, что именно он у
вас
корову украл? - Ну как!
- Раз кто-то украл, значит ***. - Раз
***, значит из Марьинки.
- Раз из Марьинки, значит Ванька Косой.
- Да... Интересная логика.
Судья подзывает секретаря, что-то говорит
ему на ухо, секретарь уходит и через
некоторое время возвращается с
закрытой коробкой. Судья:
- А скажите-ка мне, что в коробке.
Отец: - Коробка квадратная.
Старший сын:
- Раз квадратная, значит в ней что-то
круглое. Средний сын:
- Раз круглое, значит оранжевое.
Младший: - Раз оранжевое, значит апельсин.
Судья открывает коробку, достает из нее
апельсин и говорит:
- Ванька, ***, верни корову
А именно – множество слабосвязанных потоков, способных загрузить то самое превосходящее количество ядер. Причем именно слабосвязанных, посколько по мере роста связности и зависимости потоков начнется фрагментация времени продуктивной работы и накладные расходы на синхронизацию. Т.е. это процессор для массы VDI машин с 2-4 vCPU или кучи каких то контейнеров, причем реально кучи, с коэффициентом vCPU / pCore от 5 и выше
А ничего, что, наоборот, иметь кучу ядер в рамках одной системы - едино возможный вариант делать задачи с большим количеством сильно связанных потоков? Потому, что даже через самую теоретически неэффективную схему общения ядер и памяти работать все будет с куда меньшими задержками и более высокими пропускными способностями, чем если синхронизироваться через сеть с другой машиной? Тот же MS SQL Server, к примеру, отлично параллелит аналитические запросы в рамках одной машины (лично я до 160 потоков параллелил с загрузкой проца на 100%) с линеным ростом скорости, а многомашинного режима там нет вовсе (PDW не в счет).
Да зачем аналитические - любые мелкие однопоточные транзакционные запросы к оперативной БД отлично параллелятся между собой в рамках одной системы, и 4х, а то и 8 сокетные монстры с нешардированным Oracle/MSSQL/MySql/pgSql часто являются именно той единой точкой, через которую проходит все оперирование глобальной корпорации.
Можно это все и расшардировать, конечно, только это потребует кратного увеличения кода в сервисах, чтобы элиминировать всю радость распределенных транзакций и корректно обработать рейс кондишн, случающийся раз в год, но при этом имеющий возможность уничтожить репутацию корпорации за раз.
Возвращаясь к посылу автора, он примерно такой: "у меня есть система, где есть способ передачи данных между потоками со шириной в десятки гигабайт/сек, и задержкой на порядки ниже 1 мс, и это для меня настолько оскорбительно мало, что я отказываюсь использовать его из принципа и рекомендую покупать это оборудование только для задач, где этот протокол использоваться не будет". Не это ли
подход к серверам и вычислительной инфраструктуре на кухонном уровне
?
В эпоху облаков, микросервисов и кубернетесов вы вспомнили про монолиты и Bare Metal с нагруженными СУБД. Смею вас уверить, автор в курсе что это такое и давным-давно этим занимается.
Вы пропустили пойнт про сравнение производительности ВМ в 6 vCPU, например.
И тот пойнт, что 10 ядер по 4 ГГц лучше, чем 20 по 2.
Равно как и пойнт, что статья предназначена для тех, кто вообще не в курсе что такое NUMA, ПСП и многоканальная память.
Поэтому да, коллега, вы правы при разговоре о "сильносвязанных потоках" в пределах широкого (в размер сервера) монолита, но это не тема статьи.
А кто-то знает не монолитные OLTP ACID DB, которые можно эффективно "размазать по микросервисам" на нескольких физических серверах? :-)
Я знаю одну
AWS Aurora;)
Но там ноу-хау в том, что, фактически, взят движок постгреса, и в нем установлены проприетарные модули, подменяющие часть самых критичных дисковых операций хранением в оперативной памяти на 6 разных машинах в разных гео. За счёт этого есть взрывной рост перфоманса на задачах, которые слоник очень не любит.
Но, снова таки, основная сила там именно в этом хаке, подменяющем диск ну очень надежным RAMом.
Забавно, что современные SSD быстрее, чем размазывать IO по сети по гео.
:-) Можно использовать все что угодно... Хоть Oracle RAC, но блокировки блоков данных в памяти (для синхронизации их в отдельных нодах) через сетевые (или проприетарные) интерфейсы всегда будут тормозить транзакции БД...
AWS же не даром упоминает в рекламе Aurora ускорение только чтения... :-)
Лично у меня выходило до 10 раз именно на апдейтах ускорение aurora vs pg на железе. При том, что бенчмарком выступал сервер с 4мя nvme что-то типа intel p4600, терабайтом рам, и парочкой уже не помню каких xeon gold. Все кроме апдейтов плюс-минус на равных шли.
Чтение то и без Авроры отлично слейвами разгоняется до нужных скоростей.
И тот пойнт, что 10 ядер по 4 ГГц лучше, чем 20 по 2.
Да, но чаще встаёт выбор между 10 по 4 и 30 по 2.
В абсолютном большинстве случаев это искусственно навязанный выбор.
Количество ядер и частота - это функция от бизнес требований, специфических технических требований или требований регулятора. И не в последнюю очередь еще и вопрос лицензирования ПО может сыграть свою роль.
Еще в 2017 я собрал заметки и оформил в виде большой статьи как проектируется и как делается выбор CPU / RAM. https://habr.com/ru/articles/321178/
В конечном итоге можно упереться в выбор "что есть на складе у поставщика" конечно, но это объективные обстоятельства.
Все еще хуже. В компаниях побольше могут сказать: Есть вот такая конфигурация серверов, закупать под ваш проект другую никто не будет. Работайте на этих. При следующей закупке через 5 лет можно подумать и о другой конфигурации. И приходится работать. Софт тоже нормально подгоняется под доступные сервера.
А у microsoft'а как это ни забавно с этим прям хорошо. А вот postgres с бизнес-логикой - прям боль была.
серверная память - регистровая, т.е. там стоит дополнительная микросхема для повышения стабильности работы.
Ну раз это статья-ликбез, давайте не допускать фактических ошибок. Регистровая память - это всё-таки про снижение электрической нагрузки и про повышенный объём на планку памяти (который будет недоступен на обычной материнке без поддержки регистровой памяти) за счёт большого количества чипов на планке. А "стабильность работы" - это скорее про ECC, что бывает и на unbuffered-памяти. Вот только на днях подыскивал нерегистровую ECC DDR5.
Зашёл написать этот коммент:) У автора смешались в кучу конелюди.
Исправлением ошибок занимается ЕСС. А регистровая память это про объём, причём ценой задержки. Процессоры по своим электрическим ТТХ тянут только два модуля памяти на канал (ну вот так решили, что двух хватит в 99% случаев, а если закладывать больше, то надо больше мощности, токов, ширше дорожки на плате и т.д). И этот самый регистр работает "усилителем" и позволяет подключить к нему до 8 модулей, притворяющихся для процессора одним. Внутри это часто выглядит как слоёный пирог из 8 наклеенных друг на друга чиплетов внутри одной микросхемы.
Знакомый как-то в давние времена пересел с двухпроцессорного сервера на вторых пнях на десктопный процессор который и по частоте и тестам обгонял тот сервер в разы. И действительно все летало пока админ был один в терминале. Как только на новый комп в свои терминалы зашли пользователи (около десятка офис + 1с) начались случайные секундные подвисания. Раньше все было медленно но равномерно, а тут то быстро то подвисли. Так мы на собственном опыте увидели разницу между серверным и десктопным процем. Ах да, там еще и в дисках разница была, SCSI vs IDE.
Так если новый диск был гораздо медленнее старого и тормозил все, то может всё-таки не процессор виноват был?
Ну как сказать, не думаю что древние SCSI были быстрее относительно нового IDE. Вот при большом количестве одновременных запросов они их обрабатывали равномернее, в отличии от десктопного IDE. Смысл моего комментария в том, что хоть и старое но серверное железо работало комфортнее для пользователей чем новое но десктопное.
Магнитные диски уже много лет как ограничены по производительности физикой.
Что древние, что новые SATA имеющие 7200 оборотов чисто механически имеют примерно 70-75 IOPS.
Что древние SCSI, что свежие SAS 10000 порядка 120, 15000 - 150-175. И это число не меняется много лет.
Единственное, что растет - это скорость линейного чтения/записи по вполне понятной причине - более высокой плотности записи.
Мир к подобной абстрацкции console.log от электронов шел 70 лет. Сервак нынче реально для программеров просто большой мак а админы и системные инженеры - странные люди в датацентре
про E5 зионы пиши! срочно
Интересный вопрос)
когда информация передается не самим 0/1, а крутизной фронта сигнала (а фронтов два)
Фронт один, второй "фронт" — это спад. "Крутизна фронта" тут совсем неуместна. Крутизна — это характеристика фронта/спада, скорость нарастания (спада) сигнала.
Да, вы обещали "на желудях и шишках", но упрощенное изложение — не значит неправильное и именно потому, что предназначено не для "суперпрофи".
В целом статья понравилась, поставил плюсики. Ждем ещё, может быть слегка поглубже.
Ещё хотелось бы разбор ARM-процессоров, SoC и прочего. Насколько они дают реальный перформанс на серверных задачах? (Если, конечно, вообще дают)
У серверных процессоров (по крайней мере Intel) есть ещё одно преимущество - у них обычно расширенный набор инструкций (например, AVX512). Для некоторых применений (числодробилки, которые так просто не перенести на GPU) это бывает весьма полезно.
Сервер - это просто большой макбук, а СХД просто большой диск.
tl;dr: сервер и СХД медленнее Макбука, но имеют другие полезные фичи.
Почему сервер не просто «большой макбук». Часть 1