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

[ttttt 195]

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

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

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

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

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

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

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

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

 

 

Нет, я на глаз прикинул, не надо придираться. Нужно сначала посчитать вероятность, что все одновременно целые 0.8**4 и оставшаяся будет вероятность, что хоть одна битая 1 - 0.8**4 = 0,6, т.е. 60%, а не 80%. Сори, что число из головы не подошло

А для 8-ми модулей будет 1-0.8**8 = 0.83

Відредаговано 2013-05-09 23:59:18 ttttt

[NiTr0 584]

 

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

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

 

 

 

 

Quote

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

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

 

Чипкилл - для корректировки 2 и более ошибок. Так что не в тему.

 

 

 

 

Quote

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

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

 

Которые будут занесены в журнал, исходя из которого определяется битый модуль.

 

Нет, я на глаз прикинул, не надо придираться. Нужно сначала посчитать вероятность, что все одновременно целые 0.8**4 и оставшаяся будет вероятность, что хоть одна битая 1 - 0.8**4 = 0,6, т.е. 60%, а не 80%. Сори, что число из головы не подошло

А для 8-ми модулей будет 1-0.8**8 = 0.83

А теперь внимательно читаем еще раз гугловвское исследование. И убеждаемся, что эти расчеты - для наихудшей (с т.з. ошибок) патформы/памяти, для скорректированных ошибок (CE errors). И для этой же платформы кол-во модулей с нескорректированными ошибками - менее 0.1% (!).

Худшие из платформ/модулей же имеют всего 1.1% модулей, которые показывали хоть 1 неисправимую ошибку в год. Что, собссно, обнаруживается, и на ответственных серверах такие модули меняются. 1 глючной модуль из 100 - не такой уж и высокий % брака, и то это для худшего случая.

Відредаговано 2013-05-10 08:50:30 NiTr0

[ttttt 195]

 

для наихудшей (с т.з. ошибок) патформы/памяти

 

В данном случае наихудшая - это однобитные исправления, т.е. как и обычное интеловское ECC. Почитайте все исследование, не выдирайте какие попало данные, они сами по себе ничего не значат. Вот же сказано, что у не чипкил в 4-10 больше неисправимых ошибок, ни о каких 0.1% вообще и речи не идет.

 

 

 

In fact, we

found that platforms with more powerful error codes (chip-

kill versus SECDED) were able to reduce uncorrectable er-

ror rates by a factor of 4–10 over the less powerful codes.

 

У ошибок так же высокая корреляция, т.е. вероятность появления неисправимой ошибки в модуле после исправимой в тот же месяц (!) от 0.1% до 2.3%, в зависимости от чипкил это или примитивный. За год это уже каждый четвертый модуль у которого есть ошибки, особенно учтя, что ошибки либо постоянные либо нет. (Кстати у гугла нет данных по модулям с больше одной неисправимой ошибкой, они такие модули при первой такой ошибке и заменяют)

 

 

 

 

probability of an uncorrectable error is significantly larger in a

month with correctable errors compared to a month with-

out correctable errors. The increase in the probability of an

uncorrectable error ranges from a factor of 27X (for Plat-

form A ) to more than 400X (for Platform D )

 

In 70-80% of the cases an

uncorrectable error is preceded by a correctable error in the

same month or the previous month

 

 

 

 

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

 

 

 

Error rates are strongly correlated with

utilization.

 

 

 

 

С чего вы решили, что она вам не нужна? 

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

Потому что она либо отправляется, как ответ на запрос, либо ложится во временную таблицу (например для JOINов).

Принципиально нет ничего невозможного, но БД, как и ОС требуют настройки, чтобы чего-то гарантировать. 

Відредаговано 2013-05-10 13:17:32 ttttt

[NiTr0 584]

В данном случае наихудшая - это однобитные исправления, т.е. как и обычное интеловское ECC. Почитайте все исследование, не выдирайте какие попало данные, они сами по себе ничего не значат. Вот же сказано, что у не чипкил в 4-10 больше неисправимых ошибок, ни о каких 0.1% вообще и речи не идет.

Ну посмотрите на платформы C и D. Худшие - 5.7% модулей с корректируемыми ошибками (D) и 0.43% модулей с некорректируемыми ошибками (С). Итого - в худшем случае из 200 модулей 12 будут показывать корректируемые ошибки, а 1 - будет показывать нескорректированные. Много? Я бы не сказал.

Остальные платформы с chipkill не лучше смотрятся.

 

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

 

Не очевидно. Это было бы очевидным, если бы данные портились в процессе записи/считывания, а не хранения.

Потому что она либо отправляется, как ответ на запрос, либо ложится во временную таблицу (например для JOINов).

Принципиально нет ничего невозможного, но БД, как и ОС требуют настройки, чтобы чего-то гарантировать.

БД, 4 ядра, 20 конкурирующих запросов на одовременный апдейт большого кол-ва строк (ну пускай 100000 строк). Т.е. - считывается блок из кеша, проверяется КС, изменяется значение, записывается блок в память, вычисляется КС. Какова вероятность того, что между 2 и 5 операцией ядро передаст управление одному из 16 ожидающих потоков, который вытеснит данные работавшего процесса в дырявую память?

 

И это - не касаясь операций над данными в собссно коде проекта, до передачи их скл двиглу

Відредаговано 2013-05-10 19:29:08 NiTr0

[ttttt 195]

 

БД, 4 ядра, 20 конкурирующих запросов на одовременный апдейт большого кол-ва строк (ну пускай 100000 строк). Т.е. - считывается блок из кеша, проверяется КС, изменяется значение, записывается блок в память, вычисляется КС. Какова вероятность того, что между 2 и 5 операцией ядро передаст управление одному из 16 ожидающих потоков, который вытеснит данные работавшего процесса в дырявую память? 

 

И это - не касаясь операций над данными в собссно коде проекта, до передачи их скл двиглу 

А вот и не вытеснит Все транзакции всегда глобально экслюзивные и ждут, пока не выполнится предыдущая, т.е. выполняются последовательно, так ACID требует. 

[NiTr0 584]

А вот и не вытеснит Все транзакции всегда глобально экслюзивные и ждут, пока не выполнится предыдущая, т.е. выполняются последовательно, так ACID требует.

Транзакции затрагивающие одну таблицу, или одну БД, или все БД н хосте?

[ttttt 195]

 

нескорректированные. Много? Я бы не сказал.

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

[ttttt 195]

 

Транзакции затрагивающие одну таблицу, или одну БД, или все БД н хосте?

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

[NiTr0 584]

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

Уверены, что даже после недельного прогона мемтеста вы избежите ошибок (корректируемых/некорректируемых)? И ничего, что свежий мемтест уже generic тест, в угоду упрощению разработки, и не определяет скорректированные ошибки (ибо в дебри платформы не лезет - насколько я понял из описания)?

 

Ессно, ЕСС - не панацея от всего и везде. Но с ней вероятность порчи данных гораздо ниже, чем без нее.

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

Невозможно дублировать все. Ну разве что 3 отдельных дублирующих друг друга системы, и мажоритарное сравнение результатов на выходе (тогда единственная точка сбоя - железка, сравнивающая данные). Відредаговано 2013-05-10 20:29:55 NiTr0

[ttttt 195]

 

Уверены, что даже после недельного прогона мемтеста вы избежите ошибок (корректируемых/некорректируемых)?

Хз, подозреваю, что хватит и часов 10 теста, надо посчитать. Мемтест же грузит память так, как никакая реальная система, может час мемтеста, как сутки какой-то приличной настоящей нагрузки.

[NiTr0 584]

Хз, подозреваю, что хватит и часов 10 теста, надо посчитать. Мемтест же грузит память так, как никакая реальная система, может час мемтеста, как сутки какой-то приличной настоящей нагрузки.

Вы не правы. На машине с десктопной памятью, которая дает в мемтесте 1-2 сбоя в сутки, gcc к примеру крашится обычно через 2-3 чса сборки проекта... Відредаговано 2013-05-11 05:58:42 NiTr0

[ValRevan 38]

ИМХО

Проблема суперглючной памяти высосанна из пальца

У меня в работе сервера с большими объемами памяти

- с более старыми FB-DIMM 32Gb

- c новой DDR3 ECC Reg 96Gb

Под нагрузкой 3-7 лет, а по логам вообще нет ошибок ECC

Также проходит через меня обычная память и входное тестирование показывает мизерные кол-ва бракованной памяти

И если было бы действительно 30% битых модулей, то в инете уже была бы волна по этому поводу, как например с HDD Seagate 7200.11

А ее нет, и даже намека на нее нету

Так что моя гипотеза - просто очень невезучий человек у которого память битая 30% на кол-ве

 

А теперь слайды

Последние тесты

1) Обычная память 6 шт 4Gb - 124 часа прохождения тестов

2) ECC Reg 12 шт 8 Gb - 45 часов

Вероятность такого при 30% процентах бракованных модулей памяти можете сами подсчитать

 

В реальности соверменная компьютерная память при нормальных условиях эксплуатации один из самых стабильных компонентов, с малый кол-во брака

Відредаговано 2013-05-12 18:19:21 ValRevan

[hapel 31]

Интересно.. как это все поможет ТСу..

[BARVIT 113]

Это точно причем тут сервер И так никак не определюсь, чего мне хватит все таки для биллинга + сайтик небольшой. Биллинг MikBill, в продаже вроде и сервера есть - но что именно нужно не знаю, понял что лучше с памятью ECC а что по процессору(ам).

[KaYot 3 711]

Для биллинга требований по железу никаких особо и нет, ставьте эту супермикру из первого поста. Я бы сказал что под биллинг наличие возможности удаленного управления(IPMI и компания) важнее чем все остальные плюшки вместе взятые.