Комментарии 60
Это вопрос личной гигиены (с)
а можно как то сравнение сделать этих серверов? запустить одну и ту же задачу и сравнить производительность. а то все описали, включая цену, а вот сравнить производительность итоговую забыли.
и еще вопрос скорее личный. за мои 20+ лет сидения за компьютером у меня никогда небыло проблем с памятью. ну за исключением единственного случая за это время когда сгорела планка и была заменена на новую. вопрос в том - зачем ECC если за всю мою жизнь я ни разу не ловил ошибки памяти? зачем переплата за то, что я никогда не видел? я понимаю что маркетинг и "надежность", и может тот факт что 30 лет назад память была такая плохая что ECC спасало, но на сегодня реально ли это надо в современной памяти? вы хотите сказать обычная память без четности прямо брызжет ошибками, но я почему то их не вижу??
Может Вы их не видите потому, что эти ошибки исправляет процессор, тратя на это своё время? А в случае с ECC REG памятью, этим занимается контролер.
хорошо, пусть исправляет. сколько он на это тратит ресурсов? можно тесты тогда во сколько раз ECC память увеличивает производительность процессора? на одной конфигурации просто сменить память на иную и прогнать тест. чую что разницы не будет или она будет так мала, что будет теряться на долями процента... если же разные конфигурации и процессоры - то тест не имеет смысла так как вы не сможете меня убедить что разница именно в памяти а не остальном железе установленом в компе. чистый тест - один комп и два комплекта памяти, такое делал кто то?
Вы чисто ради интереса почитайте журналы BMC (в линукс можно что-то вроде ipmiutil sel). Там логируются ошибки и такие, которых вы не видите. Память, блоки питания, открытие корпуса, и т. п. А ещё железо умеет сообщать об этих проблемах ОС в реальном времени и при этом сигнализирует NMI, линукс обязательно покажет в dmesg. Как со всем этим обстоит дело в винде, не имею понятия, но всегда ещё можно посмотреть через отдельный сетевой интерфейс BMC — хоть через IPMI, хоть через веб-интерфейс.
Чтобы вам представлять, что будет, если память битая и без ECC — вот пример: https://serverfault.com/questions/1092388/debian-server-showing-read-only-file-system-repeatedly
И тут парню повезло, память оказалась "заметно" битая. А теперь представьте, что проблема проявляется редко, но случается (именно так с этим дело обстоит в реальности). Никаких сообщений об ошибках не будет, пока не испортится что-нибудь важное и нужное оперативно. А тогда выяснится, что и в бекапы уже попали битые структуры, и вообще теперь расхлёбывать дорого.
Пользуясь случаем, напомню: RAID не спасает, если его не мониторить и не скрубить и оперативно не обслуживать. То же самое касается и ECC, и резервируемых блоков питания, и вообще всех средств обеспечения устойчивости к отказам.
можно тесты тогда во сколько раз ECC память увеличивает производительность процессора?
Вообще не увеличивает. Разница в пределах погрешности, если в остальном параметры одинаковые.
ECC — это не про скорость, а про надёжность.
Я сам тоже не особый любитель пихать ЕСС в любую дырку, хоть в комментах о любом домашнем сервере появляются любители этого дела. Но если компьютер работает месяцами без перезагрузок и постоянно гоняет большие объёмы данных через память, то ЕСС ему не помешает.
Сижу за кампутаром меньше 20 лет. Видел ошибку памяти в отладчике. На самом деле штука неприятная -- сбивает с толку и тратит время.
Ранее мы проводили бенчмарки процессоров из конфигураций, упомянутых в статье:
Intel Core i5-10600
https://browser.geekbench.com/v5/cpu/2850772
Intel Xeon E-2236
https://browser.geekbench.com/v5/cpu/2874643
то что я вижу - в multicore тесте победил более дешевый процессор получается?
Да, но не во всех тестах/задачах, если подробнее смотреть.
А здесь:
https://www.cpubenchmark.net/compare/Intel-Xeon-E-2236-vs-Intel-i5-10600/3607vs3750
небольшой отрыв у Е-2236
К вопросу об объективности бенчмарков
А можете пояснить давно интересующий меня вопрос, возможно дурацкий:
Почему при выборе серверов на всех площадках, в рекламе, в конфигураторе, иногда даже в статьях, причем технического плана, используются обозначения железа уровня " 2 ядра 3.5Ггц"?
Это ведь обозначения уровня мвидео, "2 ядра, 2 гига, игровая видеокарта", вот прям под копирку, укажут частоту ядра( иногда даже без модели проца, а ведь 3.5Ггц какого нибудь 2600k или его серверного иналога и 12700k - это АБСОЛЮТНО разные 3.5ггц, так же как и 3.5 ггц вашего 10600к и того же райзена 5600X - тоже), дальше про оперативку опять же 0 инфы, "2 гига", ни частот, ни задержек, ничего, и про диск - энтерпрайз решение, вся инфа, или m2 Nvme, а что, куда, какие скорости, ладно хоть у видеокарты модель указана.
Такого рода предложения же для относительно подкованного клиента, разве нет? Почему же тогда конфигуратор/реклама уступают конфигураторам на каком нибудь сайте по сбору игровых ПК, причем сайту для самых ламеров?
То есть я перешел в ваш конфигуратор, у вас хотя бы модели процессоров указаны, уже хоть что то. Но дальше - операвтивная память - все что указано это то что она не ECC, а частота, задержки, ведь для многих CPU задач это важно, ОЧЕНЬ, один и тот же процесор в определенных задачах может быть почти вдвое более производительным с памятью 2400 и 3600.
Тоже и по поводу дисков.
Особенно часто это видно где идет заказ тупо ядер, а не проца целиком, ни инфы про что именно это за ядра, то есть про IPC, ни инфы сколько там кеша на него приходится, ничего. А ведь все это важно.
Можно и дальше много чего писать, но думаю вы поняли вопрос.
один и тот же процесор в определенных задачах может быть почти вдвое более производительным с памятью 2400 и 3600
А что за задачи такие? Где «вдвое» производительность растёт. Я видел на игрушках некоторый прирост, но там десяток-другой процентов.
Несколько причин, почему так сложилось:
1) В таком формате приходит абсолютное большинство запросов от клиентов: кол-во ядер, частота и поколение процессора, объём RAM и дисков, дополнительные устройства (gpu, контроллеры, сетевые карты). Подробные характеристики комплектующих запрашивают крайне редко.
2) Сложно поддерживать абсолютно одинаковые комплектующие на складе, они могут отличаться.
Например, выбираем память, публично прописываем в характеристиках частоту 2400, в какой-то момент закупаем чуть более производительные 3600 (в пределах того же размера) - придётся заводить новую позицию в конфигураторе кастомов или новую фиксированную конфигурацию. Не удобно ни нам, ни клиенту.
Личный пример из практики про отсутствие ECC на сервере.
https://habr.com/en/post/430824/comments/#comment_19408712
Вообще типичная ошибка выжившего и рассуждения вида: 20 лет не пристегиваюсь ремнями и ничего...
В 2009 Гугл и университет Торонто провели исследование (DRAM Errors in the Wild: A Large-Scale Field Study), в котором выяснилось, что DRAM ошибки возникают гораздо чаще, чем было принято считать.
Вкратце:
Our first observation is that memory errors are not rare events. About a third of all machines in the fleet experience at least one memory error per year (see column CE Incid. %) and the average number of correctable errors per year is over 22,000. These numbers vary across platforms, with some platforms (e.g. Platform A and B) seeing nearly 50% of their machines affected by correctable errors, while in others only 12–27% are affected. The median number of errors per year for those machines that experience at least one error ranges from 25 to 611. Interestingly, for those platforms with a lower percentage of machines affected by correctable errors, the average number of correctable errors per machine per year is the same or even higher than for the other platforms.
Around 20% of DIMMs in Platform A and B are affected by correctable errors per year, compared to less than 4% of DIMMs in Platform C and D. Only 0.05–0.08% of the DIMMs in Platform A and Platform E see an uncorrectable error per year, compared to nearly 0.3% of the DIMMs in Platform C and Platform D. The mean number of correctable errors per DIMM are more comparable, ranging from 3351–4530 correctable errors per year.
About a third of machines and over 8% of DIMMs in our fleet saw at least one correctable error per year. Our per-DIMM rates of correctable errors translate to an average of 25,000–75,000 FIT (failures in time per billion hours of operation) per Mbit and a median FIT range of 778 – 25,000 per Mbit (median for DIMMs with errors)
С тех пор всё стало только хуже. Исследования проводились на DDR2 с размером плашек 1,2 и 4гб. Сейчас обьёмы плашек (и общий обьём памяти) выросли в 2-8 раз от тех "серверных" чисел. А размеры компонентов в памяти сильно уменьшились, сделав ячейки более уязвимыми, в т.ч. появились атаки класса Rowhummer.
Надо понимать, что ошибка может "прилететь" в любой бит. Это может быть неиспользуемая в данный момент память, какие-нибудь данные (например изменится один символ в длинном текстовом сообщении или один пиксель в громадной текстуре немного изменит цвет). Это может быть код, который срабатывает раз в месяц или вообще никогда. И т.д. А также это могут быть важные данные. Особенно критично, если сжатые.
у меня в небольшом ЦОДе, 1-2 ошибки по памяти проскакивают каждый месяц.
И вообще, как то немного нехорошо сравнивать домашний комп с нагруженным сервером.
за мои 20+ лет сидения за компьютером у меня никогда небыло проблем с памятью. ну за исключением единственного случая за это время когда сгорела планка и была заменена на новую. вопрос в том — зачем ECC если за всю мою жизнь я ни разу не ловил ошибки памяти?
я правильно понимаю, вы пользуетесь памятью без ECC? почему вы тогда решили, что ошибок памяти не было?
может тот факт что 30 лет назад память была такая плохая что ECC спасало, но на сегодня реально ли это надо в современной памяти?
скорее наоборот, флип бита — вероятностное событие, объёмы памяти за 30 лет лет выросли порядка на 4, если не больше.
вы хотите сказать обычная память без четности прямо брызжет ошибками, но я почему то их не вижу??
есть и такое мнение.
я всё-таки придерживаюсь мнения, что исправная память не должна выдавать ошибок, если единичную ошибку ещё можно объяснить условными космическими лучами, то серии ошибок говорят о проблемах с модулем памяти или других аппаратных проблемах.
и тут как раз и проявляется основное преимущество ECC (на мой взгляд): память с ECC позволяет оперативно обнаруживать сбои железа и, соответственно, вовремя его заменять.
сравниваем с памятью без ECC: «ой, что-то программа вылетела, и синий экран в прошлом месяце был. не поставить ли мне память тестироваться на сутки? блин, нет, компьютер нужен» (я уж не говорю про серверное применение).
P. S. возвращаясь к космическим лучам, нашёл статью sun о космических лучах и сбоях памяти
https://docs.oracle.com/cd/E19095-01/sf4810.srvr/816-5053-10/816-5053-10.pdf
Generally speaking, cosmic ray soft errors occur in DRAM memory at a rate of ~10
to 100 FIT/MB (1 FIT = 1 device fail in 1 billion hours). So a system with 10 GB of
memory should show an ECC event every 1,000 to 10,000 hours, and a system with
100 GB would show an event every 100 to 1,000 hours.
помнится, тогда многие насмехались над sun, мол не могут делать надёжную технику и ссылаются на неведомые космические лучи. но на самом деле, конечно, проектировать технику в sun умели, просто честно описали проблему, с которой столкнулись.
правда, AFAIK с тех пор производители памяти начали учитывать влияние космических лучей при проектировании микросхем памяти, так что цифры в той статье можно считать устаревшими.
с другой стороны, более современные исследования гугла и фейсбука показывают, что достаточно большая доля серверов в процессе работы логгирует ошибки памяти
ссылки были, например, в этом обсуждении:
https://habr.com/ru/post/581222/#comment_23548010
100 GB would show an event every 100 to 1,000 hours.
На брендовых серверах в модулях памяти имеются счётчики ошибок ECC, помнится, когда я смотрел эти счётчики на машинах с 384 ГБ ОЗУ, там были нули при аптайме в годы.
Когда модуль глючит, ошибки он вполне нормально показывает)
Ну у меня свой опыт, так что извините
это всё-таки шоу, а не «рассказывает собственный опыт», технических деталей я не услышал. парень просто в жанре стендап рассказал, что в bios бывает опция «cloaking», которая отключает генерацию прерывания по скорректированной ошибке ecc.
я не слышал, чтобы в каких-то материнских платах/серверах эта опция была неотключаемой; более того, во встречавшихся мне серверах она по умолчанию отключена.
может быть манера говорить, конечно, но я его слова воспринимаю больше как трёп «по мотивам».
да, в процессорах intel генерация прерываний на скорректированные ошибки ecc может быть отключена. но я не встречал ни одного сервера, в котором эта генерация была бы отключена без возможности включить. и не слышал до сих пор про такое. и не представляю, чтобы кто-то так обрубал базовый функционал сервера.
в общем, пока не увижу пруф — не поверю
На брендовых серверах в модулях памяти имеются счётчики ошибок ECC,
счётчик ошибок ecc не в самой памяти (память об алгоритме расчёта ecc ничего не знает), а в контроллере памяти (сегодня в процессоре).
так что наличие этих счётчиков никак от брендовости сервера не зависит.
более того, и на десктопных системах с поддержкой ecc (на ryzen'ах, например) ошибки отлично считываются с помощью тех же инструментов (под linux это edac-util), отличие серверов лишь в том, что там эти ошибки дополнительно отображаются в ipmi (соответственно, наличие ошибок можно контролировать независимо от OS).
а машинах с 384 ГБ ОЗУ, там были нули при аптайме в годы
так я же про это написал в следующем абзаце:
правда, AFAIK с тех пор производители памяти начали учитывать влияние космических лучей при проектировании микросхем памяти, так что цифры в той статье можно считать устаревшими
и приложил ссылку на обсуждение, в котором упоминались (и цитировались) более свежие исследования.
так что наличие этих счётчиков никак от брендовости сервера не зависит.
Скажите, вы когда-нибудь видели сервер с RAID5 для ОЗУ?)
У меня опыт скорее обратный, "сервера" из десктопного железа ~1-2 раза в год показывали kernel panic в линуксе. Серверные машины с ECC такого себе не позволяли.
Риск словить ошибку в ОЗУ пропорционален объёму этого самого ОЗУ и времени работы. Сомневаюсь, что в Вашем компьютере сотни гигабайт оперативки, и что он работал в режиме 24х7.
Цена ошибки ОЗУ в сервере как правило несоизмеримо выше, чем в ПК.
Год назад у меня на работе был случай, когда внезапно вышедшая со строя планка памяти без ECC похоронила операционную систему ПК, сгенерировав ошибки в системных файлах. Это худший сценарий, и такое, к сожалению, случается: ведь запись данных на диск происходит через ОЗУ. Если бы это был сервер, то могла бы пострадать база данных. И не факт, что повреждение заметили бы сразу. Представьте себе необъяснимым образом изменившиеся данные в каком-то поле какой-то таблицы, замеченные кучу времени спустя. Представили? Тепер вы знаете ещё один худший кошмар админа.
Уже давно есть в продаже десктопные процессоры от AMD, поддерживающие память с ECC. В прошлом году покупали такой для резерва на случай выхода со строя сервера.
https://habr.com/ru/post/401681/
"Причиной назвали космическое излучение. Что характерно, ошибку обнаружили только благодаря тому, что кандидат получил больше голосов, чем было возможно. Иначе бы сбой остался незамеченным."
Есть у нас на обслуживании одна не совсем свежая железка, но количество битой памяти с неё уже не считаем. Там килограммы. При общем количестве модулей около 800 штук минимум по одному в неделю вылетает. Да, повторюсь, железка несвежая, и разок её перегрели, но не будь есс ошибок бы не замечали с непредсказуемым результатом.
Могу заблуждаться, но по моим прикидкам, ваша бизнес модель на десктопном железе имеет более высокую стоимость владения, чем если бы взяли сервера высокой плотности размещения на Xeon серии E-22xx.
Соглашусь только что дешевые GPU на домашних карточках в не конкуренции с Энтерпрайз железом, но тут подумать стоит, может дешевле внешни карты прокидывать, да и подготовка сервера к рате по типу "Plag and Play".
Статистика выхода из строя дисков снова в пользу серверного сегмента: десктопные SSD- и HDD-диски выходят из строя чаще.
Тут, похоже, как повезёт.
Десктопные диски, все живы-здоровы:
1x Samsung SSD 850 Pro - 50к часов наработки, записано 117 ТБ.
2x Seagate ST2000NM0033-9ZM175 2 TB - 56к часов наработки.
2x WDC WD6002FZWX-00GBGB0 6 TB - 11к часов наработки.
Серверные диски, дохлые:
2x Dell MZWKI800HMHP-000D3 (Samsung SM1715 800 GB, 5 DWPD)
Три года пролежали в заводской упаковке, потом воткнул их в домашний комп, сколхозил хороший обдув. Первый диск проработал три месяца. Второй - два года, записей было примерно на 11 ТБ, чтений примерно на 40 ТБ. По смарту вроде всё хорошо, но при чтении начала проседать скорость (десятки МБ/сек на последовательном чтении), дальше диск начал вываливаться из системы.
Отсутствует KVM-консоль
это поправимо, есть много "многодырковых" ip kvm которые можно прикрутить у билингу через вменяемое ip, ну или как отдельную услугу предлагать какой нибудь pikvm
ну BMC — это не только и не столько KVM, как ещё внешняя по отношению к компьютеру регистрация событий питания, памяти, и т. п., возможность удалённо "нажать на кнопку" питания или сброса, доступ к последовательному порту и т. п.
pikvm многое из этого умеет, но он сам потянет не меньше, чем на 10кр, и требует отдельного сетевого порта
Доступен заказ IP-KVM на 3 часа через тикет
Единственное неудобство — при заказе не видно Chipcore серверов, если они все заняты, даже со снятой галочкой «В наличии».
Hetzner очень часто использовали десктопное железо у себя. Сейчас не знаю, лет 7 с ними не работаю. За 5 лет активной работы с ними, порядка 50 серверов, проблемы в 99% случаев были только с дисками. И только один или два раза что то было с БП и чем то еще
Но даже тогда, на десктопе память, вроде, была с ECC. И все равно это не защитило от Kernel Panic, а mem test ничего не показывал. Доказать им было ничего нельзя, ответ был стандартный - у нас все работает )) В итоге просто купили новый сервер, а от этого отказались через время
Сейчас не знаю, лет 7 с ними не работаю
зайти на сайт и посмотреть предлагаемые конфигурации — несколько минут же.
если в двух словах, то в основном конфигурации с ecc (xeon, ryzen, epyc), но есть и без ecc (десктопный intel и чуть-чуть ryzen). ssd больше серверные, но есть и десктопные.
брендовые сервера тоже есть (dell).
Раньше, когда Chipcore был отдельным сайтом и сервисом, арендовал сервера с 4 HDD или 2 SSD и 2 HDD. Было очень удобно. Давно уже не вижу таких конфигураций. С чем это связано? Подобные сервера появятся когда-нибудь?
Вы можете собрать такой сервер произвольной конфигурации:
https://selectel.ru/services/dedicated/chipcore/?utm_source=habr.com&utm_medium=referral&utm_campaign=Brand_Article_150222_Chipcore
И через 2-5 дней получить к нему доступ.
А подобные готовые серверы есть в "старшем" сегменте:
https://selectel.ru/services/dedicated/config/?uuid=00352d30-b2a8-526f-a263-112adcadf121
https://selectel.ru/services/dedicated/config/?uuid=00852a2e-2690-5999-ad73-e4c507b639bd
напоминает какие-то сказки напёрсточников
Главное отличие — коррекция ошибок ECC. В конфигурации Chipcore с i5-10600 она отсутствует, в сервере с E-2236 установлены планки памяти ECC, которая определяет и исправляет случайно возникшие ошибки битов памяти.
насколько я помню рязанька поддерживает ecc память так что возможно вы поставили просто не на того вендора cpu, это reg память недоступна для десктопных процов полностью.
→ Нет приватной сети из-за отсутствия портов и сетевой инфраструктуры в Chipcore. Приватная сеть актуальна при аренде нескольких серверов в дата-центре, позволяет экономить интернет-трафик и обеспечивает изолированное скоростное соединение между серверами. Так что если для вас критически важно наличие такой сети, Chipcore вам не подойдет.
это же можно легко решить нарезав внутри той же сетёвки которая является аплинком пару vlan'ов, даже можно легко добавить это как автоматическую услугу в билинг, при покупке на комке для нужных портов создаётся vlan, а пользователю приходит письмо какой vlan юзать для серой сети.
я сильно сомневаюсь что я самый умный и додумался до этого первым, хотелось бы увидеть ответ конторы почему это не рассматривалось?
Плоскости интернет и локальной сети у нас разделены физически и мы стараемся их не пересекать - это обеспечивает стабильность работы и удобство обслуживания.
Технически подать транком несколько vlan на порт коммутатора можно, но мы это не делаем для конечных устройств в целях общей стабильности работы сети.
Десктопное железо в серверах: преимущества, особенности работы и сравнение с enterprise