Intel Xeon E-2136 CPU Temperature

[dennisgorelik]

Earlier (2021-10-30) we also measured Intel Xeon CPU temperature.
Intel Xeon CPU reaches much higher temperatures than AMD EPYC.
Healthy Intel Xeon (Adv-2-LE) reached around +70C under stress.
Unhealthy Intel Xeon reached 97+C and started CPU throttling

Below temperature measurements are for "Healthy" Intel Xeon CPU in "Idle", "Stress Starts" and "Stress Continues" modes.

1) Idle

[centos@esovh ~]$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +30.0°C (high = +80.0°C, crit = +100.0°C)
Core 0: +27.0°C (high = +80.0°C, crit = +100.0°C)
Core 1: +28.0°C (high = +80.0°C, crit = +100.0°C)
Core 2: +28.0°C (high = +80.0°C, crit = +100.0°C)
Core 3: +27.0°C (high = +80.0°C, crit = +100.0°C)
Core 4: +30.0°C (high = +80.0°C, crit = +100.0°C)
Core 5: +27.0°C (high = +80.0°C, crit = +100.0°C)
acpitz-virtual-0
Adapter: Virtual device
temp1: +27.8°C (crit = +119.0°C)
power_meter-acpi-0
Adapter: ACPI interface
power1: 4.29 MW (interval = 1.00 s)
pch_cannonlake-virtual-0
Adapter: Virtual device
temp1: +39.0°C

2) Stress

stress --cpu 24 --timeout 20m

a) Stress Starts (measured temperature ~30 seconds after the stress start)

coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +70.0°C (high = +80.0°C, crit = +100.0°C)
Core 0: +70.0°C (high = +80.0°C, crit = +100.0°C)
Core 1: +67.0°C (high = +80.0°C, crit = +100.0°C)
Core 2: +69.0°C (high = +80.0°C, crit = +100.0°C)
Core 3: +68.0°C (high = +80.0°C, crit = +100.0°C)
Core 4: +67.0°C (high = +80.0°C, crit = +100.0°C)
Core 5: +67.0°C (high = +80.0°C, crit = +100.0°C)
acpitz-virtual-0
Adapter: Virtual device
temp1: +27.8°C (crit = +119.0°C)
power_meter-acpi-0
Adapter: ACPI interface
power1: 4.29 MW (interval = 1.00 s)
pch_cannonlake-virtual-0
Adapter: Virtual device
temp1: +39.0°C

b) Stress Continues

[centos@esovh ~]$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +66.0°C (high = +80.0°C, crit = +100.0°C)
Core 0: +66.0°C (high = +80.0°C, crit = +100.0°C)
Core 1: +65.0°C (high = +80.0°C, crit = +100.0°C)
Core 2: +66.0°C (high = +80.0°C, crit = +100.0°C)
Core 3: +64.0°C (high = +80.0°C, crit = +100.0°C)
Core 4: +64.0°C (high = +80.0°C, crit = +100.0°C)
Core 5: +63.0°C (high = +80.0°C, crit = +100.0°C)
acpitz-virtual-0
Adapter: Virtual device
temp1: +27.8°C (crit = +119.0°C)
power_meter-acpi-0
Adapter: ACPI interface
power1: 4.29 MW (interval = 1.00 s)
pch_cannonlake-virtual-0
Adapter: Virtual device
temp1: +40.0°C

Comments

[krivye_ru4ki]

А что вы с этими готовыми серверами мучаетесь? Что-то как-то уныло, проблема за проблемой. У того же Hurricane Electric можно целую стойку арендовать за $400 (дадут гигабит и 64 их айпишника, ну или можно по BGP подключиться) и вставить свои серверы со свитчами, хоть проверенное оборудование будет. Ключ тут ограничение по питанию, 120V/15A. Потребуется больше питания - придётся переходить на другой план.

Server colocation

[dennisgorelik]

> А что вы с этими готовыми серверами мучаетесь?

Так если наш собственный сервер сломается - сколько времени займет его заменить?
Это же еще больше проблем, чем с dedicated hosting.

Когда data center хостит несколько тысяч одинаковых серверов, то им и заменять сломавшиеся сервера проще, и все проблемы этих серверов операторам этого data center знакомы.

Если же наш сервер уникален (потомучто мы его сами собрали), то решать проблемы этого сервера - довольно дорого.

> Что-то как-то уныло, проблема за проблемой.

Так хочется более быстрый hardware, а его менеджить приходится немного по-другому.
Приходится учиться и решать новые проблемы.

Ну или вот vrack (private network) сейчас пытаемся сконфигурировать.
Раньше мы private network не конфигурировали.
Приходится разбираться.

[krivye_ru4ki]

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

VM cluster

[dennisgorelik]

> Но на то и облака чтобы быстро заспавнить одну или несколько нод ненадолго, пока замена едет.

Вместо dedicated сервера - создать кластер из трех VM?

А если у нас SQL Server с тремя databases общим размером 1.2+ TB -- это тоже на VM кластере хостить?

Re: VM cluster

[krivye_ru4ki]

Хмм, ну с dedicated сервером у вас те же проблемы: если базы держать на нём и он накрывается, происходит зопа)). Надо восстанавливать из бэкапа. И какая разница куда восстанавливать - на другой dedicated или AWS-ноду? Или если готовится к такой ситуации, настраивать репликацию, то не особо важно куда.
> кластер из трех VM?
Имелось в виду кластер из нескольких физических серверов с виртуалками, один умирает - остальные запускают те виртуалки, что выполнялись на сдохшем пока сдохший не приведут в чувство.

Re: VM cluster

[dennisgorelik]

> какая разница куда восстанавливать - на другой dedicated или AWS-ноду?

Dedicated server работает гораздо быстрее (в несколько раз?), чем VM.

Соответственно, VM с database нагрузкой dedicated server, вероятно, просто не справится.

> кластер из нескольких физических серверов с виртуалками

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

Re: VM cluster

[krivye_ru4ki]

> Dedicated server работает гораздо быстрее (в несколько раз?), чем VM.

А вот кстати и не факт, на день-два можно запустить что-то суровое вроде AWS c5d.metal с NVMe-дисками и это не будет дорого, так как это ненадолго, пока другой сервер не завезут.

> Ты имеешь ввиду, что на каждом физическом сервере в кластере - выполняется только одна VM?

Не, несколько, чтобы если их пришлось раскидывать, они распределились по одной на оставшихся физических хостах. Да, нужен shared storage для этого, но это может быть и бесплатно, как StarWind VSAN или Linstor.

Re: VM cluster

[dennisgorelik]

> нужен shared storage для этого

Так storage - это же самая сложная часть в распределенной системе.
Именно storage, чаще всего, является bottleneck по скорости работы.

> StarWind VSAN или Linstor

Какая у "StarWind VSAN" и "Linstor" производительность, по сравнению с локальным NVMe?
Раз в пять медленнее?

Re: VM cluster

[krivye_ru4ki]

Ну так да, а что ж вы хотели? Если не хочется восстанавливать всё из бэкапа в случае падения, данные должны быть доступны либо через репликацию на уровне приложения, либо на уровне диска, чудес нет))

SQL Server replication

[dennisgorelik]

А можно как-то примерно оценить, насколько репликация замедляет работу SQL Server?

Правильно ли предположить, что репликация примерно удваивает нагрузку от Update/Insert/Delete SQL операций?

Re: SQL Server replication

[krivye_ru4ki]

Сразу вопррос, синхронная или асинхронная?

Re: SQL Server replication

[dennisgorelik]

Вероятно, асинхронная.
Нам же только backup нужен.

Re: SQL Server replication

[krivye_ru4ki]

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

Re: SQL Server replication

[dennisgorelik]

> не так что прям транзакции удваиваются

Так я и не предполагал, что транзакции удваиваются.
Но нагрузка на сервер ведь вполне может удваиваться.
Я предполагаю, что основная транзакция закончится примерно за то же время, что и без log shipping.
Но потом log shipping скушает еще примерно столько же ресурсов SQL Server, сколько и основная транзакция.
Потому что ведь нужно те же данные еще раз записать [to send to SQL Server subscriber], верно?

Re: SQL Server replication

[krivye_ru4ki]

Не, точно нет, запись лога - это совсем малая часть ресурсов, потраченных на транзакцию. Больше всякие вычисления (что откуда достать, сам процесс доставания, что куда положить) и так далее. А тут получается что просто записываем лог не в одно место, а в два, во второе по сети. Причём во второе асинхронно, так что и новым задержкам браться неоткуда.

Re: SQL Server replication

[krivye_ru4ki]

Ну и как, вышло что-нибудь, мне аж интересно стало же.

Re: SQL Server replication

[dennisgorelik]

> вышло что-нибудь

Пока - нет.
Это же разобраться надо.
У репликации разные опции.
Нужно аккуратно выбрать.
Потом нужно это все соединить, протестировать, написать скрипт, который это все деплоит и опять протестировать.

Репликация - заманчива (continuous backup), но требует существенных усилий.