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

[prototip 284]

А в чем по сути спор ?  Опять кто то велосипед придумать захотел аля сервер за 5 копеек ?  А холивара то холивара , скоро до нулей и единиц дойдут . Есть такая категория людей , в толпу ревностных ценителей чего либо зайдут и бросят фразу порождающую борьбу сторон , а сами в сторону отойдут и смотрят как другие друг друга за грудки тягают .  Ничего не напоминает ? 

[ValRevan 38]

>NiTr0

Прочитал очередной поток бредятины профана, думающего что мемтест только он умеет использовать

Предлагаю просто спор на $1K

 

Покупаем обычный Kingson DDR3 4Gb не ECC с ценой около средней 4-6 модулей что я обычно беру (Я укажу модель и купим в одной из фирм рандомно)

Ставим ее на сервер и запускаем тест (актуальный memtest) на 2е суток

NiTr0 говорит что брак более 30%

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

 

Если есть сбой на Memtest - NiTr0 выиграл мои $1K

Нет - я выиграл $1K у NiTr0

И по результатам отпишеся тут

 

А то просто уже устал слушать полный бред нубов

[ttttt 195]

 

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

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

 

 

Или - вероятность сбоя в строке за год 5*10-6. Соотвественно, вероятность двойного сбоя в строке 2.5*10-11.

Почему соответственно? Это теоретичски на двух несвязанных битиках одновременно, а на связанных может будет даже тот же порядок. 

UPD: Кстати, по данным гугла 0.22% модулей (и аж 1% для 4 GB DDR2) получают хоть одну неисправимую ошибку в год (т.е. 2 бита в одной строке и больше) и до 2-4% машин в год в зависимости от платформы у них же. Это очень много.

 

 

А в чем по сути спор ?

В том, что БД не полагаются на железо для гарантий, которые они дают, ECC им ничего не даст. 

Відредаговано 2013-05-07 13:21:00 ttttt

[ttttt 195]

35162.pdf

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

Близко к истине, но они такие же и для ECC памяти. По данным гугла 20% модулей виноваты в от 94% до 99.6% всех ошибок, а основная масса модулей вообще не видит ошибок.

 

 

P.S. Могу пересказать коротко исследование гугла, если кому-то на английском тяжело читать

[rootvm 1]

Скажи мне из берлоги с очень не правильным медом, а что такое ECC non Reg ?

[KaYot 3 705]

Не регистровая вестимо. В простонародье - не full buffered.

[ValRevan 38]

Скажи мне из берлоги с очень не правильным медом, а что такое ECC non Reg ?

Вот простая статья с картинками на эту тему

http://www.servethehome.com/unbuffered-registered-ecc-memory-difference-ecc-udimms-rdimms/

Не регистровая вестимо. В простонародье - не full buffered.

Если быть точным - full buffered это просто подвид памяти. Те память может быть не full buffered, но при этом buffered

full buffered уже устаревший вид памяти

Відредаговано 2013-05-08 06:46:35 ValRevan

[rootvm 1]

Ну дык не буферизированная и не регистровая память это разные вещи. ECC не может быть не регистровой.  И еще хотите что бы была быстрая БД юзайте No SQL. Как бы мускул да самый распространенный но у его задачи не те.

[ValRevan 38]

ECC не может быть не регистровой.

Заблуждение

Может

[NiTr0 584]

ValRevan, on 07 Май 2013 - 15:07, said:

>NiTr0

Прочитал очередной поток бредятины профана, думающего что мемтест только он умеет использовать

Предлагаю просто спор на $1K

 

Покупаем обычный Kingson DDR3 4Gb не ECC с ценой около средней 4-6 модулей что я обычно беру (Я укажу модель и купим в одной из фирм рандомно)

Ставим ее на сервер и запускаем тест (актуальный memtest) на 2е суток

NiTr0 говорит что брак более 30%

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

 

Если есть сбой на Memtest - NiTr0 выиграл мои $1K

Нет - я выиграл $1K у NiTr0

И по результатам отпишеся тут

 

А то просто уже устал слушать полный бред нубов

Вы купите плашки, отберете из них неглючные, и продемонстрируете что они не глючат

 

Кстати, что там с бюджетной платформой под регистровую память?

ttttt, on 07 Май 2013 - 15:30, said:

 

 

Quote

Или - вероятность сбоя в строке за год 5*10-6. Соотвественно, вероятность двойного сбоя в строке 2.5*10-11.

Почему соответственно? Это теоретичски на двух несвязанных битиках одновременно, а на связанных может будет даже тот же порядок.

UPD: Кстати, по данным гугла 0.22% модулей (и аж 1% для 4 GB DDR2) получают хоть одну неисправимую ошибку в год (т.е. 2 бита в одной строке и больше) и до 2-4% машин в год в зависимости от платформы у них же. Это очень много.

 

Ну связанные - из-за дефектов кристалла скорее всего получаются...

 

Да и опять же, СУБД не сможет обеспечить целостность данных в процессе их обработки, до записи в строку БД/после получения из строки БД. Физически не сможет.

rootvm, on 08 Май 2013 - 10:23, said:

Ну дык не буферизированная и не регистровая память это разные вещи. ECC не может быть не регистровой. И еще хотите что бы была быстрая БД юзайте No SQL. Как бы мускул да самый распространенный но у его задачи не те.

ЕСС - всего лишь еще 1 чип допаян. Регистровая - на линиях адреса стоит дополнительный регистр-защелка, увеличивающий латентность на 1 такт, но снижающий нагрузку на шину. В общем-то, никак между собой не связанные вещи, но регистровой без ЕСС нет ввиду ее бессмысленности (регистровая память идет на серверах с большими объемами памяти; там целостность даных критична), а нерегистровой с ЕСС - предостаточно, к примеру KVR16E11 Разве что sdram мне на глаза не попадалась такая, все прочие - имеются.

[ValRevan 38]

 

 

ValRevan, on 07 Май 2013 - 15:07, said:

>NiTr0

Прочитал очередной поток бредятины профана, думающего что мемтест только он умеет использовать

Предлагаю просто спор на $1K

 

Покупаем обычный Kingson DDR3 4Gb не ECC с ценой около средней 4-6 модулей что я обычно беру (Я укажу модель и купим в одной из фирм рандомно)

Ставим ее на сервер и запускаем тест (актуальный memtest) на 2е суток

NiTr0 говорит что брак более 30%

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

 

Если есть сбой на Memtest - NiTr0 выиграл мои $1K

Нет - я выиграл $1K у NiTr0

И по результатам отпишеся тут

 

А то просто уже устал слушать полный бред нубов

Вы купите плашки, отберете из них неглючные, и продемонстрируете что они не глючат

 

 

Как и ожидалось, бред нести легче чем за свои слова отвечать

Доходит до дела - тупой съезд

Кстати, что там с бюджетной платформой под регистровую память?

Вы правда не можете понять простую фразу "бюджетная ECC Reg память"?

 

 

PS.

Перестаю отвечать на Ваши посты.

Может вместо IT Вам лучше в политику со своими сказками и неумением отвечать за свои слова?

[NiTr0 584]

Как и ожидалось, бред нести легче чем за свои слова отвечать

Доходит до дела - тупой съезд

Если вам так сильно неймется расстаться с $1k - я могу выслать вам 3-4 штуки вполне себе кошерной Kingston HyperX ддр2, снятой с разных серверов из-за ее глюкавости. И в догонку - плашки попроще, гиговые с домашнего тазика.

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

Вы правда не можете понять простую фразу "бюджетная ECC Reg память"?

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

[ttttt 195]

 

СУБД не сможет обеспечить целостность данных в процессе их обработки

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

[NiTr0 584]

 

 

СУБД не сможет обеспечить целостность данных в процессе их обработки

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

А почему вы считаете, что только в блоке, вычитанном из БД, может произойти сбой? Как насчет полуенного по сети запроса? Как насчет вытеснения данных из кеша? Как насчет собственного кеша СУБД (который у мускула таки имеется) - как в нем реализован (и реализован ли) повторный контроль целостности поднятых с винта данных в процессе длительного хранения?

[rootvm 1]

Товарищи учите теорию. И о практике не забывайте.

[ttttt 195]

 

А почему вы считаете, что только в блоке

Не считаю. По сети запросы обычно шифруются, будет битый - не расшифруется. Типичная реализация кэша - LRU кэш блоков файлов, вместо чтения из файлов с диска блоки читаются из памяти вместе с CRC суммой и проверяются, а если в памяти нет, то с диска и ложатся в кэш. Проверяются блоки либо всегда, либо опционально, зависит от движка и его гарантий. Для хороших ECC (не таких, как у интела сейчас) можно же и отключить проверку, может производительнось кому-то очень важна. Вытеснение в данном случае ни на что не влияет. Есть кэши на других уровнях, типа кэш запросов, он наверное и не проверяется, если включите, то конечно никаких реальных гарантий не получите. А вообще CRC там много где еще, и в репликации, и даже для ответов по сети могут считаться, если соединения не шифруются (в том же mysql cluster). 

Все зависит от ваших задач. Иногда даже БД нельзя доверять и какой-нибудь SHA1 самому еще раз для каждой строки считать.

[NiTr0 584]

Вытеснение в данном случае ни на что не влияет.

Влияет. Данные из кеша с ЕСС вытесняются в память без ЕСС - при этом КС блока уже проверена и он считается валидным. Со всеми вытекающими...

Иногда даже БД нельзя доверять и какой-нибудь SHA1 самому еще раз для каждой строки считать.

Ну о целостности данных в процессе собссно вычислений в памяти, думаю, лучше помолчать

[ttttt 195]

 

КС блока уже проверена и он считается валидным

Не считается, блочный кэш не на том уровне, он используется, как будто кэша вообще не существует. Вот нам надо прибавить число к каким-то записям, они читаются, как-будто с диска, и прозрачно проверяются, если два раза читаются, два раза проверяються. Распаковали запись, прибавили число (все это в кэше процессора) - пишем в лог на диск с CRC для записи, блока или другим способом. Конечно, данных может много, тогда создаются временные таблицы, они ничем не отличаются от обычных, ну кроме в лог не пишутся, и точно так же при каждом обращении проверяются CRC для блоков. Т.е. теоретически может быть ситуация, когда распакованные данные успели вытесниться в память, например kill -STOP в очень удачный момент, загадить кэш процессора после этого, но это только теоретически. 

 

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

(следуя данным гугла получается 2 из 10 битых модулей будут выдавать очень много неисправимых ошибок)

Відредаговано 2013-05-09 14:10:47 ttttt

[KaYot 3 705]

Если бы интел реально пытались ошибки исправлять, то там бы было что-то не такое примитивное, а хотя бы как у chipkill. А так они даже не пытаются и как оказывается шансы неисправимой ошибки всего в десяток раз ниже, чем исправимой, зачем кому-то такая недокоррекция? [/size]

(следуя данным гугла получается 2 из 10 битых модулей будут выдавать очень много неисправимых ошибок)

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

По твоей же гуглевской ссылке вероятность появления единичной несправимой ошибки в есс модуле в течении ГОДА - доли процента, т.е. за год пролетит 1 битый бит в 1 из 500 планок.

Відредаговано 2013-05-09 14:17:53 KaYot

[ttttt 195]

 

По твоей же гуглевской ссылке вероятность появления единичной несправимой ошибки в есс модуле в течении ГОДА

0.22%, если быть точнее. Но гугл там же пишет. что очень большой разброс, у chipkill модулей получше, у более примитивных уже аж 1% неисправимых ошибок.

 

 

т.е. за год пролетит битый бит в 1 из 200 планок.

Нет, не т.е.. У 80% модулей никогда не появляются ошибки, независимо от их времени использования, температуры и т.д. А 20% модулей виноваты почти во всех ошибках. Это значит, что для машин с 4 модулями и примитивным ECC шансы уже аж под 80% наткнуться на битый модуль. И в каждой 5-й такой машине на много неисправимых ошибки, не 1-а в год, а уже аж 1-а в неделю.

Відредаговано 2013-05-09 14:29:13 ttttt

[ttttt 195]

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

[KaYot 3 705]

Хорошо, у интела на серверных платах есть замечательный режим работы ECC памяти - mirrored memory. Когда один из каналов памяти выделяется для поддержания такого себе raid-1 дублирования данных.

Вероятность одновременного сбоя нескольких бит в одних и тех же ячейках в 2 каналах нулевая. Хотя что-то я не слышал об его использовании, может проблема плохой памяти не так уж и страшна на самом деле?

[KaYot 3 705]

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

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

[ttttt 195]

 

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

В это и суть, что оказывается ошибки из-за брака, а не заряженных частиц и т.д.

 

 

 

We provide strong evidence that memory

errors are dominated by hard errors, rather than soft errors, which

previous work suspects to be the dominant error mode. We find

that temperature, known to strongly impact DIMM error rates in

lab conditions, has a surprisingly small effect on error behavior

in the field, when taking all other factors into account. Finally,

unlike commonly feared, we don’t observe any indication that

newer generations of DIMMs have worse error behavior.

 

[NiTr0 584]

Не считается, блочный кэш не на том уровне

Какой нафиг блочный кеш???

Напоминаю течение дискуссии: данные поднялись из кеша СУБД, проверились на валидность по КС, попали в кеш проца. Далее - данные вытеснились из кеша проца (к примеру, длительный запрос/много конкурирующих запросов/прочее). Далее - данные опять поднялись из оперативки в кеш для последующей обработки, с битым битом. Что и как софтом будет проверяться??? Еще раз КС? А СУБД догадывается, что данные вытеснены были из кеша, или нет? Если нет, то сколько раз и когда считать КС?

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

(следуя данным гугла получается 2 из 10 битых модулей будут выдавать очень много неисправимых ошибок)

Пытаются, пытаются. Одиночная ошибка прекрасно исправляется и журналируется... 

 

0.22%, если быть точнее. Но гугл там же пишет. что очень большой разброс, у chipkill модулей получше, у более примитивных уже аж 1% неисправимых ошибок.

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

 

Нет, не т.е.. У 80% модулей никогда не появляются ошибки, независимо от их времени использования, температуры и т.д. А 20% модулей виноваты почти во всех ошибках. Это значит, что для машин с 4 модулями и примитивным ECC шансы уже аж под 80% наткнуться на битый модуль. И в каждой 5-й такой машине на много неисправимых ошибки, не 1-а в год, а уже аж 1-а в неделю.

Учите матчасть. Если будет 8 модулей - то что, шанс будет 160%?