Перейти до

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


Рекомендованные сообщения

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

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

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

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

Я глянул по подсказке кайота, у интела есть аналог чипкила, 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

Відредаговано ttttt
Ссылка на сообщение
Поделиться на других сайтах
  • Відповіді 89
  • Створено
  • Остання відповідь

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Примерно такой конфигурации NASы(core q9300-9450-q9550) у нас тянут 600-800 сессий, не больше. Дальше появляются необъяснимые скачки загрузки, тормоза у клиентов и т.п. - вероятно предел системы по pp

КПД будет более 70% (посмотрите эти тесты к примеру).Это вам наверное пора выбираться из криокамеры. Времена медленной сдрам с низкими частотами на толстом техпроцессе прошли.Не вам судить. Ваш уровен

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

Posted Images

 

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

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

 

 

 

 

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 - не такой уж и высокий % брака, и то это для худшего случая.

Відредаговано NiTr0
Ссылка на сообщение
Поделиться на других сайтах

 

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

 

В данном случае наихудшая - это однобитные исправления, т.е. как и обычное интеловское 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ов).

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

Відредаговано ttttt
Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

 

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

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

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

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

 

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

Відредаговано NiTr0
Ссылка на сообщение
Поделиться на других сайтах

 

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

 

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

Ссылка на сообщение
Поделиться на других сайтах

 

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

Невозможно дублировать все. Ну разве что 3 отдельных дублирующих друг друга системы, и мажоритарное сравнение результатов на выходе (тогда единственная точка сбоя - железка, сравнивающая данные). Відредаговано NiTr0
Ссылка на сообщение
Поделиться на других сайтах

 

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

Вы не правы. На машине с десктопной памятью, которая дает в мемтесте 1-2 сбоя в сутки, gcc к примеру крашится обычно через 2-3 чса сборки проекта... Відредаговано NiTr0
Ссылка на сообщение
Поделиться на других сайтах

ИМХО

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

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

- с более старыми 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% процентах бракованных модулей памяти можете сами подсчитать

 

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

Відредаговано ValRevan
Ссылка на сообщение
Поделиться на других сайтах
  • 2 weeks later...

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

Ссылка на сообщение
Поделиться на других сайтах

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

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • Від Remez
      Ценник 5,500
       
      в наличии 3 шт
       
       





    • Від Server_mall
      Сервера можно пере укомплектовать, за отдельную плату. Состояние отличное. К серверам имеется еще шкаф. Звонить по номеру 0673757227 ( ТГ, вайбер)
      В наличии:  2200 уе цена сервера, готовы разговаривать 
      Тип 1 (2 шт)
      Dell R740 16*2,5
      1x5118
      1x32GB RAM
      Perc H330
      2x600GB SAS 10k Dell
      2x1,2TB SAS 10k Dell
      2x10Gb + 2x1Gb LAN
      iDRAC Express
      Quick Sync
      2 PSU 1100W
      Rails


      Тип 2 ( 1шт)
      Dell R440 4*3,5
      1x4114
      1x16GB RAM
      Perc H730P
      4x4TB SAS Dell
      2x1Gb LAN
      iDRAC Enterprise
      2 PSU 550W
      Rails



    • Від rocker_ilko
      Продам сервера Dell r430 шасі на 8 дисків 2.5 sata  2 cpu e5 2630 v3/ без памяті/без хдд/2 блока живлення/idrack enterprise  = 8000грн
       
      Dell r720 шасі на 16 дисків 2,5   2 cpu e5 2660 v2/32gb/raid 710/2 блока живлення/idrack enterprise  = 8000грн
       
      Dell r730xd шасі на 24 диска 2,5   2 cpu e5 2650 v4/без памяті/raid 730/2 блока живлення/idrack enterprise  = 17000грн
       
      В наявності є і інші моделі серверів
    • Від work-hub
      work-hub.online
      sup.workhub.online@gmail.com
      +38 050 395 7000
       
      Предоставляем услуги аренды виртуальных и физических серверов для предприятий, аудиторов с возможностью настройки Windows, программных комплексов: 1С, MeDoc, MD Declaration и других. Собственное оборудование, штат специалистов и опыт работы уже более 10 лет на рынке.
       
      Готовые серверные решения для предприятий и бухгалтеров
       
      Наши преимущества:
      • Готовые решения «под ключ» для клиентов, развертывание системы за 2 часа
      • Собственное сетевое и серверное оборудование (не арендованное)
      • Возможность оплаты на расчетный счет по договору (ФЛП 2 и 3 группы)
      • Установка и настройка Windows, 1С, MeDoc, MD Declaration и других
      • Опыт работы уже более 10 лет
      • Техническая поддержка и штат профильных специалистов
      • Бесперебойность 24/7
    • Від NETOS
      Продам б/у сервер HP ProLiant DL360p Gen8
      CPU: 2 шт Intel Xeon E5-2650 v2 2.6 GHz, 8 ядер, 16 потоків
      RAM: 128GB 16*8 DDR3-12800
      2 блока живлення
       
      В роботі був не більше місяця поки налаштовували. Почалась війна все зупинилося. 
       
      Вартість: 10000 грн.











×
×
  • Створити нове...