Помогите с выбором сервера

[NiTr0 584]

а что есть лучше ET?

Да какбы и 10GE есть, и более свежие 82580/I350 - но это не обязательно. ЕТ б/у с головой. Или даже РТ если пппое и/или 2 головы.

>По скорости оно быстрее выше упомянутого sipermicro, кушает 50Вт вместо 250, и запчасти в случае беды можно купить в любом ларьке.

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

ИМХО

1. 50 Вт потребления в такой системе с дешевым БП кажутся уж слишком оптимистичным если будет нагрузка

Элементарно. Мамка - чипсет 6Вт. Сетевуха - пару Вт. Винт - Вт 5-7 (хотя лучше роутерный дистр типа LEAF на SATA DOM флэшке). Все отсальное - проц, учитывая небольшую загрузку и тдп 45Вт - Вт пускай 25-30 (и то с большой натяжкой, ибо тдп - это суть максимально возможное потребление при 100% загрузке и видео и всех ядер, причем - завышенное в большую сторону до стандартного значения).

2. Если хорошо протестировать память и эксплуатировать сервер в нормальном режиме (темп, влажность и тд) то в ECC особой необходимости нету.

Да ну? А мужики-то и не знают

Хотя да, тута одна контора рекламировала свои сервера, основанные на десктопных процах без ецц с фирменным дистром на базе бзди. Так они с ошибками памяти боролись ежесуточным ребутом

Давно занимаюсь СУБД и с нормальной обычной памятью не вижу проблем. Просто сталкивался с спецами которые сразу при возникновении проблем клиентам советовали менять всю память на ECC тк это в книжках пишут. Лично мой сервер на серверной платформе SM но с десктопным CPU i7-920 и обычной памятью 4Gb*6=24 Gb c заполнением памяти на 70-80%% работает больше 4 лет и аптаймом около 2.5 года

Работать-то работают... А в БД случаем у вас каши не случилось?

У нас вон тоже работал тазик с парой виртуалок и некритичными БД, в БД данные таки немного побились (появились миллионы постов у юзеров форума и т.п.), ну и всякие подземные стуки типа внезапных лагов/висов выплывали.

По моим наблюдениям - эдак % 20-30, если не более (на новых плашках - ситуация хуже, глючных более), обычной не-ецц памяти глючат, с вероятностью где-то 1-2 битика в сутки (судя по мемтесту). Или даже чуть реже. Обычно - в одних и тех же ячейках. Замена памяти на ЕСС - волшебным образом устраняет проблему; и, что характерно, скорректированных ошибок ЕСС не появляется (!).

Вопрос: нахрена такой цирк, с отбором памяти и ее тестированием сутками, если можно почти за те же (!) деньги купить ецц память, если платформа ее поддерживает; а если не поддерживает - купить изначально платформу с ецц. Благо, есть их на любую сумму.

С другой стороны сейчас для новой системы конечно стоит рассматривать бюджетную ECC Reg тк она не сильно дороже обычной памяти, особенно если надо большие объемы , которые просто с обычной неподдерживаются

Какая бюджетная регистровая память??? Какие бюдетные камни ее кушают??? Реистровая память - прерогатива серверных платформ, чаще многосокетных. Нерегистровая - на интелах да, в бюджетных воркстейшн идет, в десктопе - нет; в амд - где угодно кроме АПУ ставится на ура.

А сетевуха с мамкой сколько будут потреблять?

На intel.com забанили?

Відредаговано 2013-05-05 20:53:47 NiTr0

[hapel 31]

NiTr0

А поговорить? )

[NiTr0 584]

А чего говорить. Берете TDP, вот вам в первом приближении и максимально возможное потребление. + чуток на стабилизаторы всяческие (на глаз набросить немного Вт).

 

И да, на БП не стоит сильно экономить. Т.е. - не ставить откровенный китайский шлак. Из недорогого но качественного - возьмите, к примеру, FSP PNF/PAF серии.

Відредаговано 2013-05-05 20:58:14 NiTr0

[hapel 31]

В 40 ватт уложусь для 2010, ЕТшной сетевухи, SSD и какой-нить миниАТХ на Z77? )

[NiTr0 584]

Нафига вам SSD? У вас бюджет резиновый или как?

Поставьте флэш модуль, поставьте роутерный дистр или поставьте дебиан и сделайте ему рут рид-онли (хотя я не сторонник полновесных дистров на роутерах/брасах), и будет вам счастье.

Да и накой вам Z77 там, где хватит H61...

Насчет 40Вт - не знаю, разве что совсем впритык будет. Я энергопотребление с точностью до ватта никогда не старался определить...

Кстати как вариант - немного занизьте напряжение на проце. Поможет снизить потребление (потребление - пропорционально квадрату напряжения растет).

[hapel 31]

Вопрос не в бюджете, а енергоэффективности. Люди кажуть, что NAТ на основе 2010 разрулит довольно приличное кол-во клиентских сессий. Даже если поделить все что кажут на два, все равно устраивает. Есть желание нагруженную систему уложить по потреблению в 40 Ватт из за компактных блоков питания и соотв. экономии места в стойке. Да и на ИБП можно больше такого железа навесить. Если выдержит 400..500 PPPoE сессий онлайн на 100М, то было б не плохо. Вот и задаю вопросы )

Відредаговано 2013-05-05 22:12:07 hapel

[NiTr0 584]

Думаю вполне выдержит.

А по поводу компактных БП... Ищите не компактные, а в первую очередь легко доступные в продаже, и берите с запасом по мощности. Лучше 2 юнита без извращений, чем 1 юнит, но с БП под заказ. Тем более, стойка-то 42 юнита, чего ее сильно (аж на целых 0.5-1 юнит) экономить Хотя и для 1ю корпусов есть БП вплоть до 150Вт свободно в продаже в инет-магазинах.

[hapel 31]

Ну корпус по любому будет 2У. Неохота сетевуху пускать через райзер. Но стоит лимит 40Ватт и надо уложиться. )

[NiTr0 584]

Стоит, не стоит... В 2-юнитовый корпус влазит ОБЫЧНЫЙ блок питания, с 80мм кулером. Нафига вы себе придумываете проблемы? Для последующего героического их решения? Или считаете, что 40Вт бздюлька, нагруженная на 95%, будет работать долго и счастливо в нормальном температурном режиме, и не выгорит (возможно - с прочим железом), скажем, при отказе кондера в летнюю жару?

[ttttt 195]

 

Работать-то работают... А в БД случаем у вас каши не случилось? 

У нас вон тоже работал тазик с парой виртуалок и некритичными БД, в БД данные таки немного побились (появились миллионы постов у юзеров форума и т.п.), ну и всякие подземные стуки типа внезапных лагов/висов выплывали.

А что за БД такая, что контрольные суммы не считает? По ACID обязаны, т.к. ECC особенно ничего не гарантирует, ну там если испортится 1 бит из 64 - исправит, а два уже нет и может даже не отдетектить. 

[hapel 31]

Стоит, не стоит... В 2-юнитовый корпус влазит ОБЫЧНЫЙ блок питания, с 80мм кулером. Нафига вы себе придумываете проблемы? Для последующего героического их решения? Или считаете, что 40Вт бздюлька, нагруженная на 95%, будет работать долго и счастливо в нормальном температурном режиме, и не выгорит (возможно - с прочим железом), скажем, при отказе кондера в летнюю жару?

В CSV-2mini уже стоят 2*80мм вентиляторы. И почему проблемы? Есть идея, хочу проверить возможность реализации. А Вы так говорите, как будто это что-то плохое. Поскольку железяки пока к заказу не доступны (гребаные майские праздники), развожу демагогию на форумах )

[KaYot 3 681]

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

[NiTr0 584]

А что за БД такая, что контрольные суммы не считает?

БД - мускул. И с какой радости ей считать контрольные суммы, и что делать при несовпадении КС? Считать строку негодной?

И опять же, причем тут КС? Порча может произойти на совершенно различных этапах, и КС тут никаким боком. Пример: поднялись данные из БД в кеш, валяются в памяти, побился бит, далее - мусорное значение увеличилось на единицу и сохранилось в БД. Или прилетел скл запрос, лежат данные в памяти, пока СУБД была занята дисковыми операциями - бит протух.

По ACID обязаны, т.к. ECC особенно ничего не гарантирует, ну там если испортится 1 бит из 64 - исправит, а два уже нет и может даже не отдетектить.

ЕСС таки гарантирует обнаружение и исправление одиночной ошибки, либо обнаружение двойной ошибки.

Опять же, посчитайте вероятность двойного сбоя в одной строке гигового (128М строк) модуля...

В CSV-2mini уже стоят 2*80мм вентиляторы.

Я вам о АТХ БП с 80мм кулером (коих масса, и дешевых), вы мне о кулерах...

И почему проблемы? Есть идея, хочу проверить возможность реализации. А Вы так говорите, как будто это что-то плохое. Поскольку железяки пока к заказу не доступны (гребаные майские праздники), развожу демагогию на форумах )

Использование БП с заявленой мощностью даже меньшей чем TDP процессора - конечно плохое. Ибо все зависит от конкретного экземпляра процессора, БП, мамки нагрузки и т.п... Вам будет сильно легче, если в вечерний час пик из-за всплеска нагрузки ваш недо-БП сгорит с дымом и вонью, ибо работал на пределе? И тем более - смысл от этого цирка, если в корпус ШТАТНО помещается БП на 250-300Вт??? Какое место вы экономить собираетесь-то???

[hapel 31]

NiTr0

Вы мне в том числе и о "нормальных температурных режимах" "40-ватной бздюльки" и как все "выгорит" говорили. Именно в этом контексте был мой ответ о 2*80 вентиляторах.

 

http://local.com.ua/forum/topic/47564-помогите-с-выбором-сервера/?p=430231

А тут Вы рассчитали потребление сервера почти на уровне 40Ватт. Исходя из этого и следовал мой дальнейший вопрос. Только вместо обычного ХДД на "5..6Ватт", я хотел поставить ССД диск. И еще раз повторяю - задача не в миниатюризации и экономии, а енергоэффективности всей системы на стандартных компонентах для 400..500 пппое сессий. Путь даже система выйдет дороже, чем на обычном 250Ватт БП )

[KaYot 3 681]

Да нет проблем в 50Вт вписаться, современный двухядерник на ivy bridge, мамку максимально простую и БП небольшой мощности(100-150вт ITX). Загрузка у такой системы и так выше 50% в жизни не поднимется, будет пару десятков Вт кушать в пике. Ну а то что SSD кушает меньше чем HDD - очень спорно, чего-то у меня подобные приводы в компактных корпусах нагреваются просто адски.

[hapel 31]

KaYot

Ну на НАТе диск интенсивно не используется. БД будут на другом компе. Скорей бы праздники закончились, не терпится собрать-проверить )

[NiTr0 584]

NiTr0

Вы мне в том числе и о "нормальных температурных режимах" "40-ватной бздюльки" и как все "выгорит" говорили. Именно в этом контексте был мой ответ о 2*80 вентиляторах.

Ну объясните, нафига нагружать БП на 100-150% паспортной мощности, да еще на боевом сервере, работающем в единичном экземпляре??? Что экономить таким образом собираетесь???

А тут Вы рассчитали потребление сервера почти на уровне 40Ватт. Исходя из этого и следовал мой дальнейший вопрос.

Примерно. В среднестатистическом режиме работы. А зафлудит роутер/протаращит какой демон, подрастет нагрузка на ядрах до 100% на каждом, и вылезет проц на Вт пускай 40, + мамка + сетевуха + память + прочее - и все это весело сгорит. Оно вам надо???

Повторюсь: нормальная практика выбора БП - сумма TDP всех компонентов + % 20-30 запаса хотя бы. + проверить потребление по линиям питания - проц к примеру кушает в основном от +12, т.е. по 12В БП должен выдавать мощность не меньшую чем его TDP + TDP/заявленное потребление прочих 12В потребителей (винт в частности).

Только вместо обычного ХДД на "5..6Ватт", я хотел поставить ССД диск. И еще раз повторяю - задача не в миниатюризации и экономии, а енергоэффективности всей системы на стандартных компонентах для 400..500 пппое сессий. Путь даже система выйдет дороже, чем на обычном 250Ватт БП )

С чего это вы решили, что нагруженный на 100-120% БП будет энергоэффективнее, чем нагруженный на 20-30%? О надежности помолчу.

Или вы считаете, что если на БП написано 500Вт, он потребляет все 500Вт в любом режиме???

 

Да нет проблем в 50Вт вписаться, современный двухядерник на ivy bridge, мамку максимально простую и БП небольшой мощности(100-150вт ITX). Загрузка у такой системы и так выше 50% в жизни не поднимется, будет пару десятков Вт кушать в пике. Ну а то что SSD кушает меньше чем HDD - очень спорно, чего-то у меня подобные приводы в компактных корпусах нагреваются просто адски.

Да я бы вообще не ставил одиночный SSD на ответственый сервер. Тем более - когда есть более дешевые DOM, и при этом не требуется RW раздел (при наличии прямых рук он на брасе не нужен). Ибо техноонанизмом попахивает. Хотя да, каждый др*чит как он хочет...

[sanyadnepr 305]

Да нет проблем в 50Вт вписаться, современный двухядерник на ivy bridge, мамку максимально простую и БП небольшой мощности(100-150вт ITX). Загрузка у такой системы и так выше 50% в жизни не поднимется, будет пару десятков Вт кушать в пике. Ну а то что SSD кушает меньше чем HDD - очень спорно, чего-то у меня подобные приводы в компактных корпусах нагреваются просто адски.

Вы о 10-15Ватт потерь на самом БП запамятовали

Хотя в среднем выше 50Ватт вряд ли будет. 

 

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

Вполне себе Атом 200Мбит с шейпами жует

 

 

 Supermicro X7DWE Intel® Xeon® Processor E5472 (12M Cache, 3.00 GHz, 1600 MHz FSB) (Знатный хлам (с) KaYot),

+1

[hapel 31]

Ну с чего Вы все взяли что сервер мне нужен один? Мне таких добрый десяток нужен, если не больше. Главное чтобы взлетел )

Ладно проехали. Все равно каждый остается при своем мнении, но Ваше мнение я услышал )

[sfc 17]

отпишусь в поддержку ряда пользователей, здесь высказывавшихся.

 

и, хотя примеры не по теме серверов, но по теме питания в целом. мы эксплуатируем множество разнообразной профессиональной аппаратуры связи много лет, от старой аналоговой до самой современной цифровой. особенно это было заметно на более старой аппаратуре, где заводы прилагали очень подробные технические документы. так или иначе, практически на всей аппаратуре используются блоки питания, имеющие запас в 2 - 2,5 (иногда и более) раза превышающий среднее потребление платами, модулями и т.п.

 

вывод за вами 

Відредаговано 2013-05-06 09:36:08 sfc

[KaYot 3 681]

Вывод - у вас не хватает образованных инженеров.

[ValRevan 38]

 

 

>По скорости оно быстрее выше упомянутого sipermicro, кушает 50Вт вместо 250, и запчасти в случае беды можно купить в любом ларьке.

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

ИМХО

1. 50 Вт потребления в такой системе с дешевым БП кажутся уж слишком оптимистичным если будет нагрузка

Элементарно. Мамка - чипсет 6Вт. Сетевуха - пару Вт. Винт - Вт 5-7 (хотя лучше роутерный дистр типа LEAF на SATA DOM флэшке). Все отсальное - проц, учитывая небольшую загрузку и тдп 45Вт - Вт пускай 25-30 (и то с большой натяжкой, ибо тдп - это суть максимально возможное потребление при 100% загрузке и видео и всех ядер, причем - завышенное в большую сторону до стандартного значения).

 

 

Ага и дешевый БП при потреблении 50Вт будет работать с 100% КПД

Вы теоретик, да?

 

 

2. Если хорошо протестировать память и эксплуатировать сервер в нормальном режиме (темп, влажность и тд) то в ECC особой необходимости нету.

Да ну? А мужики-то и не знают

Хотя да, тута одна контора рекламировала свои сервера, основанные на десктопных процах без ецц с фирменным дистром на базе бзди. Так они с ошибками памяти боролись ежесуточным ребутом

 

 

Может мужикам стоит вылезти из берлоги сначало?

 

 

Давно занимаюсь СУБД и с нормальной обычной памятью не вижу проблем. Просто сталкивался с спецами которые сразу при возникновении проблем клиентам советовали менять всю память на ECC тк это в книжках пишут. Лично мой сервер на серверной платформе SM но с десктопным CPU i7-920 и обычной памятью 4Gb*6=24 Gb c заполнением памяти на 70-80%% работает больше 4 лет и аптаймом около 2.5 года

Работать-то работают... А в БД случаем у вас каши не случилось?

У нас вон тоже работал тазик с парой виртуалок и некритичными БД, в БД данные таки немного побились (появились миллионы постов у юзеров форума и т.п.), ну и всякие подземные стуки типа внезапных лагов/висов выплывали.

По моим наблюдениям - эдак % 20-30, если не более (на новых плашках - ситуация хуже, глючных более), обычной не-ецц памяти глючат, с вероятностью где-то 1-2 битика в сутки (судя по мемтесту). Или даже чуть реже. Обычно - в одних и тех же ячейках. Замена памяти на ЕСС - волшебным образом устраняет проблему; и, что характерно, скорректированных ошибок ЕСС не появляется (!).

Вопрос: нахрена такой цирк, с отбором памяти и ее тестированием сутками, если можно почти за те же (!) деньги купить ецц память, если платформа ее поддерживает; а если не поддерживает - купить изначально платформу с ецц. Благо, есть их на любую сумму.

 

 

Во-первых, в СУБД Вы профан

Во-вторых, разгребая битую систему как Вы определили что каша именно из-за того что была память не ECС, а не из-за глюков софта, другого железа и тд

В-третьих, в компьютерных комплектующих Вы тоже профан, тк это только у Вас в голове 20-30%% процентов брака на планках памяти. Может в Вашу берлогу завозят неправильный мед просто?

Ну хорошо, обычная память полоное фуфло, 30% а то и больше брака как Вы пишите, но из тех же модулей делают ECC non Reg, продают ее сейчас на 20% дороже, и о чудо,

даже нет в логах сообщений о корректировках ECC, те теже микросхемы уже не глючат. Вы можете сделать $$$ продав идею вендорам, а то они списывают кучу памяти тк она суперглючная, а тут за сущие копейки такое радикальное исправление ситуации.

В-четвертых, то что ECC non Reg стала отличатся не сильно по цене от обычной на 2Gb и 4Gb модулях это произошло достаточно недавно, а что было делать раньше, а что делать если платформа уже есть но без поддержки ECC. ИМХО просто не слушать бредовиков и подбирать оптимальное решение без мантры "ECC"

 

 

С другой стороны сейчас для новой системы конечно стоит рассматривать бюджетную ECC Reg тк она не сильно дороже обычной памяти, особенно если надо большие объемы , которые просто с обычной неподдерживаются

Какая бюджетная регистровая память??? Какие бюдетные камни ее кушают??? Реистровая память - прерогатива серверных платформ, чаще многосокетных. Нерегистровая - на интелах да, в бюджетных воркстейшн идет, в десктопе - нет; в амд - где угодно кроме АПУ ставится на ура.

 

 

Во-первых, это уже смешно не знать значение слова "бюджетное" и работать в IT

Во-вторых, еще смешнее писать теоретические бредни типа такого "Нерегистровая - на интелах да, в бюджетных воркстейшн идет, в десктопе - нет;"

Берем десктопные MB Intel DH61HO, CPU Intel G860. Ставим ECC non Reg Kingston 2Gb. О чудо, работает. Ну ясно - бредовиков из берлог напомойку

Відредаговано 2013-05-06 11:47:22 ValRevan

[ttttt 195]

 

БД - мускул. И с какой радости ей считать контрольные суммы, и что делать при несовпадении КС? Считать строку негодной?

БД должна считать суммы, чтобы гарантровать согласованность, как раз чтобы не было такого, что поврежденные данные из кэша использовались для чего-то, сумма считается перез использованием. В случае несовпадения считать строку негодной и возвращать ошибку, чтобы транзакцию можно было отменить. 

По дефолту в мускуле myisam движок, который ничего вообще не гаратирует и никаких транзакций не поддерживает. Он и годится только для каких-нибудь форумов, где не так страшно битые данные

 

 

И опять же, причем тут КС? Порча может произойти на совершенно различных этапах, и КС тут никаким боком. Пример: поднялись данные из БД в кеш, валяются в памяти, побился бит, далее - мусорное значение увеличилось на единицу и сохранилось в БД. Или прилетел скл запрос, лежат данные в памяти, пока СУБД была занята дисковыми операциями - бит протух.

Когда данные поднимаются с диска - они поднимаются блоками, т.е. вместе с контрольной суммой и ложатся в кэш вместе с ней. Перед любым использованием контрольная сумма проверяется. Если данные хоть в памяти, хоть на диске будут запорчены - проверка контрольной суммы не пройдет и транзакцию можно будет отменить.

 

 

ЕСС таки гарантирует обнаружение и исправление одиночной ошибки, либо обнаружение двойной ошибки.

Опять же, посчитайте вероятность двойного сбоя в одной строке гигового (128М строк) модуля...

Лучше посчитайте вероятность сбоя в 24 гиговом модуле с ECC за год работы, а потом посчитайте если таких машин 10 или 100. Окажется, что гарантии ЕСС не такие уж и высокие, даже у одного большого тазика за долгую работу данные могут попортиться.

И реально ЕСС не дает приложениям увидеть отдетектинную ошибку, так что либо исправляет один бит, либо ничего. 

[NiTr0 584]

Ага и дешевый БП при потреблении 50Вт будет работать с 100% КПД

Вы теоретик, да?

КПД будет более 70% (посмотрите эти тесты к примеру).

Может мужикам стоит вылезти из берлоги сначало?

Это вам наверное пора выбираться из криокамеры. Времена медленной сдрам с низкими частотами на толстом техпроцессе прошли.

Во-первых, в СУБД Вы профан

Не вам судить. Ваш уровень знаний вы уже показали.

Во-вторых, разгребая битую систему как Вы определили что каша именно из-за того что была память не ECС, а не из-за глюков софта, другого железа и тд

Да элементарно. Запустил мемтест на пару суток. А туда поставил идентичную плату с процом, но с есс памятью. А в домашней машине, после постоянных вылетов компилятора - просто заменил память на ЕСС, что волшебным образом устранило все проблемы.

В-третьих, в компьютерных комплектующих Вы тоже профан, тк это только у Вас в голове 20-30%% процентов брака на планках памяти. Может в Вашу берлогу завозят неправильный мед просто?

Мсье хоть один раз тестировал память перед установкой на боевой сервер? Не-не, не один проход мемтеста, а тест на несколько суток? Нет? Так и знал

Ну хорошо, обычная память полоное фуфло, 30% а то и больше брака как Вы пишите, но из тех же модулей делают ECC non Reg, продают ее сейчас на 20% дороже, и о чудо,

даже нет в логах сообщений о корректировках ECC, те теже микросхемы уже не глючат. Вы можете сделать $$$ продав идею вендорам, а то они списывают кучу памяти тк она суперглючная, а тут за сущие копейки такое радикальное исправление ситуации.

1) не из тех же "модулей". и вообще не из модулей, а микросхем. и если откроете каталог даже одного вендора, то увидите сколько "тех же" различных чипов он производит.

2) скромная статистика наглядно показала, что в десктопные плашки ставят откровенное г, в то время как в ЕСС плашки ставят все же нексолько другие чипы. То ли это заводская отбраковка, то ли чипы чуть дороже (но стабильнее), то ли еще что - неведомо. Скорее всего - потому как в ЕСС модуле дырявость будет налицо, а в десктопной - спишут на глюкавость винды.

 

К слову, посмотрите статистику гугла...

В-четвертых, то что ECC non Reg стала отличатся не сильно по цене от обычной на 2Gb и 4Gb модулях это произошло достаточно недавно, а что было делать раньше, а что делать если платформа уже есть но без поддержки ECC. ИМХО просто не слушать бредовиков и подбирать оптимальное решение без мантры "ECC"

Недавно - это насколько недавно? ЕСС ддр первая вполне себе недорого стоила, и даже более того, ее прекрасно использовали те, кто в теме. Хотя да, ддр память была и постабильнее все же. Частоты ниже, ячейки крупнее (меньше вероятность сбоя из-за естественного радиационного фона) и т.п.

Во-первых, это уже смешно не знать значение слова "бюджетное" и работать в IT

Мсье читает неважно?

Ладно, разжую: покажите мне бюджетную платформу с поддержкой регистровой ЕСС. Подсказка: бюджетные лга1155 зионы регистровую память не поддерживают.

Во-вторых, еще смешнее писать теоретические бредни типа такого "Нерегистровая - на интелах да, в бюджетных воркстейшн идет, в десктопе - нет;"

Берем десктопные MB Intel DH61HO, CPU Intel G860. Ставим ECC non Reg Kingston 2Gb. О чудо, работает. Ну ясно - бредовиков из берлог напомойку

Работает. Без ЕСС. Потому как в камнях ЕСС заблокирована. И более того, даже на плате линии к пинам ЕСС не разведены. Потому, мсье практик, вам два за ваши познания. Потому как потыкать мало - надо еще голову включить и проверить, что же у вас в результате получилось. Відредаговано 2013-05-07 08:05:55 NiTr0

[NiTr0 584]

БД должна считать суммы, чтобы гарантровать согласованность, как раз чтобы не было такого, что поврежденные данные из кэша использовались для чего-то, сумма считается перез использованием. В случае несовпадения считать строку негодной и возвращать ошибку, чтобы транзакцию можно было отменить.

Когда данные поднимаются с диска - они поднимаются блоками, т.е. вместе с контрольной суммой и ложатся в кэш вместе с ней. Перед любым использованием контрольная сумма проверяется. Если данные хоть в памяти, хоть на диске будут запорчены - проверка контрольной суммы не пройдет и транзакцию можно будет отменить.

Ладно, допустим. Поднялись данные, в них - ошибка. Что делать? Бинлога нет ввиду давности данных.

Лучше посчитайте вероятность сбоя в 24 гиговом модуле с ECC за год работы, а потом посчитайте если таких машин 10 или 100. Окажется, что гарантии ЕСС не такие уж и высокие, даже у одного большого тазика за долгую работу данные могут попортиться.

Посчитаем что даные портятся не при передаче, а при хранении.

Пускай гиговый модуль имеет вероятность сбоя 2 бита в сутки. Или - 700 бит в год. Или - вероятность сбоя в строке за год 5*10-6. Соотвественно, вероятность двойного сбоя в строке 2.5*10-11. Или примерно 0.0006 ошибок в год на 24ГБ памяти.

И реально ЕСС не дает приложениям увидеть отдетектинную ошибку, так что либо исправляет один бит, либо ничего.

Приложениям - не дает. Ядру - дает.