Перейти к содержимому
Калькуляторы

Мини роутер Мини компьютер для маршрутизатора с билингом

Никогда не слышал, что бы дырявая память подделывала счета на оплату. :) Софт вылетает - да. Тазик виснет - да. Обычно после трех-пяти таких случаев память тестируется, и, если надо, меняется. Но деньги "подделать"... Не, даже представить не могу.

Тогда скорее всего у вас проблема с понимаем того как работает в обще память и приложения.

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

В общем

http://habrahabr.ru/company/yandex/blog/250753/

http://habrahabr.ru/company/smart_soft/blog/185226/

Поделиться сообщением


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

Что будет если сбой в памяти попадет не в код/критически важные данные, а в тот самый счетчик трафика/тариф/прочее?

 

Что будет где? В моих программах? Это обнаружится в течении минуты, и будет зафиксированно в логах. При следующем распределении памяти, рано или поздно, туда ляжет адресация или код, и программа вылетит - очередной звоночек. После повторения такого несколько раз, память уйдет на тест. Но!!! За, почти, 20 лет работы с биллинговыми и платежными системами, повторюсь, ни разу не слышал, что бы такой сбой приводил к искажению данных. Может у вас такие случаи были - поделитесь. :)

 

Тогда скорее всего у вас проблема с понимаем того как работает в обще память и приложения.

 

Проще намекнуть на проблемы со слухом, ибо я ни разу не слышал... И дальше по тексту. :)

Поделиться сообщением


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

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

 

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

Поделиться сообщением


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

Это обнаружится в течении минуты, и будет зафиксированно в логах.

У вас на каждую переменную вешается контрольная сумма? :)

 

Но!!! За, почти, 20 лет работы с биллинговыми и платежными системами, повторюсь, ни разу не слышал, что бы такой сбой приводил к искажению данных. Может у вас такие случаи были - поделитесь. :)

Были. Крутился форум + бд на тазике без ЕСС. Спустя некоторое время у некоторых юзеров счетчик постов начал показывать сказочные значения (типа нескольких тысяч, или миллионов).

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

 

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

Да-да, теоретики забывают, что существует вымывание кеша (в т.ч. и юзерспейсом)...

 

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

Ок, есть страшные ужасные баги, которые могут привестик порче данных - потому мы ни один из известных нам багов (а отсуствие ЕСС таковым тоже является) устранять не будем, все равно данные можно потерять. Гениальная логика :) Особенно учитывая тот факт, что ЕСС сейчас есть даже на самых дешманских материнках, а разница в цене памяти - копейки...

Поделиться сообщением


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

Ага, с более критичными проблемами разбираться не будем, но совешенно маловажную будем обсасывать на всех форумах и проповедовать ECC :D

 

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

Изменено пользователем ttttt

Поделиться сообщением


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

У вас на каждую переменную вешается контрольная сумма? :)

 

Нет. У меня просто ключевые показатели хранятся в трех разных местах, и каждую минуту сравниваются для контроля синхронизации. Это касается как начислений, так и платежей.

 

Ок, есть страшные ужасные баги, которые могут привестик порче данных

 

Есть один популярный биллинг, который много лет тупо убивал данные. Вот просто убивал, и все. При получении сигнала, при выходе, при перезагрузке сервера. Что только автор ни делал (точнее, он делал все, что угодно, только никак не мог понять сути собственной ошибки), и рассказывал, как хорошо будет работать это на журнале, или как можно избежать этого, перейдя на другую базу данных. Но биллинг так и продолжал бить данные, сам, своими ручками. Много лет. Так-что не все так красиво и хорошо в исправлениях багов. :)

Поделиться сообщением


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

Ага, с более критичными проблемами разбираться не будем, но совешенно маловажную будем обсасывать на всех форумах и проповедовать ECC :D

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

 

Нет. У меня просто ключевые показатели хранятся в трех разных местах, и каждую минуту сравниваются для контроля синхронизации. Это касается как начислений, так и платежей.

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

 

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

И такой поделкой кто-то пользовался, еще и платил за нее? :)

Поделиться сообщением


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

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

Поделиться сообщением


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

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

Нужно наплевать, пока не будут решены общие, более важные и более вероятные проблемы. И тут будет бонус - они же решают и проблему с ECC. Зачем заниматься ерундой?

 

Это мне уже напоминает недавнюю тему на локале, где супер админы фантазировали про минутные простои и решили, что надо начинать с рейда и обязательно "железного", чтобы построить высокую доступность, а потом поставить второй сервер рядом и туда мигрировать виртуалку, если что :D Бревно в глазу не заметили. То что ни один ДЦ не сможет обеспечить такую доступность - это не страшно, это потом решим!

Начинать, конечно же, нужно с отказоустойчивости между ДЦ, а потом остальное, если еще нужно будет.

 

От общего к частному - не забывайте!

Изменено пользователем ttttt

Поделиться сообщением


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

лишь бы не замечать очевидное и гнуть свою линию.

Расскажи свою версию очевидного.

 

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

 

У нитро форум запортился, потому что он говно использовал, а не СУБД. Но он об этом тактично забыл напомнить, конечно же.

Изменено пользователем ttttt

Поделиться сообщением


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

Ребята, вы на весь форум пытаетесь доказать что ECC нафиг не нужно? Самим не смешно? Даже палка раз в жизни стреляет.

Поделиться сообщением


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

Хочу поддержать товарищей которые говорят что ECC в данной ситуации не нужно. Вы вообще о чем? 300 Мбит, 2 организации. Какие ошибки в деньгах при такой нагрузке?

 

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

 

Занимаюсь разработкой биллинговых систем 12 лет уже.

 

По теме: видел железки с i7 на борту типа такого: http://ru.aliexpress.com/item/Mini-xp-pc-cloud-mini-pc-mini-pc-desktop-500g-hdd-Intel-core-i7-2600S-2/1518106717.html?recommendVersion=1

 

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

Изменено пользователем Dark_Angel

Поделиться сообщением


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

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

Да-да, пока не будут найдены все гипотетически существующие баги :)

 

И тут будет бонус - они же решают и проблему с ECC.

Каким таким волшебным образом? Данные перестают храниться в памяти? :)

 

Это мне уже напоминает недавнюю тему на локале, где супер админы фантазировали про минутные простои и решили, что надо начинать с рейда и обязательно "железного", чтобы построить высокую доступность, а потом поставить второй сервер рядом и туда мигрировать виртуалку, если что :D Бревно в глазу не заметили. То что ни один ДЦ не сможет обеспечить такую доступность - это не страшно, это потом решим!

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

 

 

Хочу поддержать товарищей которые говорят что ECC в данной ситуации не нужно. Вы вообще о чем? 300 Мбит, 2 организации. Какие ошибки в деньгах при такой нагрузке?

Деньги считаться будут чужие, не свои. И когда у партнера возникнет вопрос "а с какого хрена мне в 3 раза больше насчитало" - он с большой вероятностью пошлет такого "провайдера" куда подальше.

 

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

20-30% новой памяти в тестах так себя ведет. Из тех, что прошли через мои руки.

Поделиться сообщением


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

ну подумаешь пару суток простоя будет пока новый не поставят да пока бекап не развернут...

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

 

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

 

 

Какие механизмы? Только если разработчики предусмотрели их и смогли нормально реализовать. СУБД только пользуется памятью? ну ну...

Поделиться сообщением


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

И тут будет бонус - они же решают и проблему с ECC.

Каким таким волшебным образом? Данные перестают храниться в памяти? :)

Додумаетесь - узнаете.

 

Это мне уже напоминает недавнюю тему на локале, где супер админы фантазировали про минутные простои и решили, что надо начинать с рейда и обязательно "железного", чтобы построить высокую доступность, а потом поставить второй сервер рядом и туда мигрировать виртуалку, если что :D Бревно в глазу не заметили. То что ни один ДЦ не сможет обеспечить такую доступность - это не страшно, это потом решим!

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

Ясно все с вами. Если ДЦ уже бывают с минутными простоями за год, то говорить нам больше не о чем.

 

Ребята, вы на весь форум пытаетесь доказать что ECC нафиг не нужно? Самим не смешно? Даже палка раз в жизни стреляет.

Читай внимательно или проходи мимо. На этой задаче оно не нужно, а не вообще не нужно.

Поделиться сообщением


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

Нет. У меня просто ключевые показатели хранятся в трех разных местах, и каждую минуту сравниваются для контроля синхронизации. Это касается как начислений, так и платежей.

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

 

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

 

И такой поделкой кто-то пользовался, еще и платил за нее? :)

 

Самое удивительное, что да, пользовались, и пользуются. :)

 

Ну и по топику - совсем не понимаю смысла спора про память? Какова цель этого спора? Кто кого в чем хочет убедить? :)

Изменено пользователем vop

Поделиться сообщением


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

Деньги считаться будут чужие, не свои. И когда у партнера возникнет вопрос "а с какого хрена мне в 3 раза больше насчитало" - он с большой вероятностью пошлет такого "провайдера" куда подальше.

 

 

Я с вами не согласен. Это из серии "давайте построим бункер и поставим сервер туда, а то вдруг война". Это оправдывает себя в 0.001% случаев, и кто-то даже так и делает, но их задачи весьма специфичны.

 

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

 

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

 

Ну и ситуация в которой клиент получив счет на минус триллиард такой "ой, наверное меня хотят обмануть на триллиард" и свалит к другому провайдеру и вовсе комична.

 

Короче, из моего опыта ECC нужен в очень специфических ситуациях, куда задача поднятая ТС ни при каких условиях не попадает. Даже если там будут считаться миллионы для этих двух клиентов. Затраты на покупку оборудования с ЕСС не окупятся никогда.

 

Желающим обсудить полезность ЕСС и обменяться реальным опытом, или проверить свои теории предлагаю создать отдельную для этого тему. Я с удовольствием подискутирую и поделюсь своим опытом, т.к. тема весьма не однозначна на первый взгляд.

Изменено пользователем Dark_Angel

Поделиться сообщением


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

Затраты на покупку оборудования с ЕСС не окупятся никогда.

Вы меня конечно извините, но о каких конкретно затратах? разница между desktop сборкой и серверной 100-200$. Учитывайте тот факт что процессор i7 тот же, дороже чем xeon 1225-1245 к примеру, за счет графического ядра.

 

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

Поделиться сообщением


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

Это из серии "давайте построим бункер и поставим сервер туда, а то вдруг война". Это оправдывает себя в 0.001% случаев, и кто-то даже так и делает, но их задачи весьма специфичны.

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

 

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

Поделиться сообщением


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

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

 

Вы меня по-диагонали читаете. Я где-то написал, что ЕСС бесполезна вообще всегда? Как ваш опыт с 1 тыс. серверов можно перенести на вопрос ТС?

 

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

 

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

 

Ну так я абсолютно с вами согласен, тем более в контексте данной темы.

Поделиться сообщением


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

Читай внимательно или проходи мимо. На этой задаче оно не нужно, а не вообще не нужно.

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

А по остальному: вы пристегиваетесь за рулём только после 60км/ч?

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

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

Поделиться сообщением


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

Ясно все с вами. Если ДЦ уже бывают с минутными простоями за год, то говорить нам больше не о чем.

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

 

А хостинг, который недоступен более пары часов - это уже не хостинг, а пионерия.

 

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

Маловероятно что сбой в ячейке счетчика произойдет? Или в ячейке тарифа?

 

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

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

 

Короче, из моего опыта ECC нужен в очень специфических ситуациях, куда задача поднятая ТС ни при каких условиях не попадает. Даже если там будут считаться миллионы для этих двух клиентов. Затраты на покупку оборудования с ЕСС не окупятся никогда.

Повторяюсь: любой десктоп на АМ3/АМ3+ с матерью от асуса держит ЕСС. Даже с семпроном и офисной мамкой. Куда уж дешевле-то?

Поделиться сообщением


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

Ясно все с вами. Если ДЦ уже бывают с минутными простоями за год, то говорить нам больше не о чем.

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

 

А хостинг, который недоступен более пары часов - это уже не хостинг, а пионерия.

:D :D :D

А в среднем пять, а то и десять часов простоя ДЦ в год не хотите? Нет? Ну тогда ДЦ для вас в мире не найдется :)

Фантазеры ***.

Поделиться сообщением


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

А в среднем пять, а то и десять часов простоя ДЦ в год не хотите? Нет? Ну тогда ДЦ для вас в мире не найдется :)

Речь кажется шла не о суммарном простое а о разовом. Который без кластеризации при отказе какого-либо из компонентов сервера легко выливается в сутки и более, особенно если ДЦ в другом городе.

 

И да, статистика нищебродского хетцнера: http://www.webhostingstuff.com/uptime/Hetznerde.html

Поделиться сообщением


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

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

 

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

 

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

Поделиться сообщением


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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.