Какой сервер лучше?

Да нет никакой "специфической нагрузки" на память!!!!

Минимальный уровень ошибок, который наблюдает гугль,

происходит не при записи-чтении, а от природной радиации в основном.

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

А вот когда ошибка _уже возникла_ - к чему она приведет зависит от специфики использования сервера.

Пруфлинк!!!!!!

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

И надеюсь меня поддержат.

Капец ересть. Хвостинг, неужели не осознаете, что если к памяти не обращаться, то ошибки и заметить нельзя и чем чаще обращаться, тем выше вероятность заметить ошибку?

А причем тут mysql? Я где-то что-то о mysql говорил? Я догадываюсь, что он умеет, но доказывать не собираюсь. Те что я знаю точно умеют - LevelDB.

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

Все-таки даже в mysql в innodb есть чексуммы из коробки, по крайней мере вот здесь сказано:

http://www.scriptiny.com/2013/03/what-to-do-after-facing-corruption-in-mysql-innodb-tables/

zzzit, немного оффтопа. Чем был обоснован выбор именно levelDB, а не redis'a или другого nosql решения? Есть один проджект на примере - сейчас подбираю его реализацию.

Альтертнативы LevelDB только TokyoCabinet, BerkeleyDB, а все те nosql решения не встраиваются, плюс размер редис ограничен доступной памятью. Добавлять записи в LevelDB можно в разы быстрее, чем в B-Tree базы, как TokyoCabinet и BerkeleyDB, потому и выбран. Еще там теперь есть блум фильтр и обращаться к случайным данным тоже можно очень быстро, чуть ли не 1 сик по диску.

У вас есть цыпленок, точнее яйцо. Оно лежит в инкубаторе.

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

Сильно буде отличаться вероятность?

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

Пример с цыпленком - это речь о событии, которое рано или поздно случится.

И о наблюдении за этим событием.

Как я писал выше - из статистики гугля вытекает что на десктопном оборудовании

ловится порядка одной ошибки памяти в год.

Если вы вообще никогда на заглянете после события в инкубатор - значит сервер АБСОЛЮТНО полностью простаивает.

suspend to ram типа.

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

Если после ошибки данные из ячейки прочитались - вы обнаружили что у вас есть цыпленок.

===========

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

Более того - тем выше вероятность ее породить.

Я утверждаю что вероятность породить ошибку повышается только при низковольтной памяти и шуме по цепи питания (конструктивный недочет MB).

При этом есть минимальная вероятность, которую порождает не электричество а радиация, и с ним бороться может ТОЛЬКО ECC.

И низкая активность работы с памятью только оттягивает момент.... либо обнаружения ошибки, либо затирания ее новыми данными. Вероятность _возникновения_ радиационных ошибок уменьшить НЕВОЗМОЖНО!.

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

Грубо говоря как с динозавром: 50/50 - либо в ячейку после ошибки что то запишут, и ошибку сотрут, либо из нее что-то с ошибкой прочитают.

А случится это через 100мкс или через 3 дня - это вопрос второй. Внятно?

---------- Добавлено 31.03.2013 в 23:33 ----------

Я вообще-то в ах.е от этой новости.

Тут выше приводили аргумент что память без ECC быстрее работает.

Ну, чтобы реально быстрее, так скорее нет, там какие то доли процента КМК.

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

Вопрос - а если выпилить этот кусок кода и таки положиться на ECC и ChipKill, что будет быстрее - ксеон, или i7, на котором эти проверки будет пересчитывать процессор?

Это как раз еще большой вопрос.

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

А если много маленьких процессов, то как раз наличие 4 физических ядер поможет распараллелить их.

Я считаю что Xeon получше все же вариант. Только нужно помнить, что начиная с X3440 - процессор имеет HT - то есть у него будет 8 потоков. Лучше взять X3440