tag:blogger.com,1999:blog-410416665291724878.post2112474712999605342..comments2022-12-19T13:52:22.907+04:00Comments on >рабочие заметки: Cores that don't count: "тихие" производственные дефекты процессоровRuslan Chereminhttp://www.blogger.com/profile/01023948540752159657noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-410416665291724878.post-24543807437168452332021-08-01T13:40:22.429+04:002021-08-01T13:40:22.429+04:00Действительно, повезло. В каком-то смысле это можн...Действительно, повезло. В каком-то смысле это можно считать идеей для best practice: периодически гонять регрессионные тесты на рабочих серверах.<br /><br />Ну вот авторы статьи пишут, что планируют что-то такое делать у себя, да. Но одновременно они предупреждают, что многие такие ошибки очень специфичны, проявляются только для конкретной нагрузки -- и гугл не может же предсказать все паттерны Ruslan Chereminhttps://www.blogger.com/profile/01023948540752159657noreply@blogger.comtag:blogger.com,1999:blog-410416665291724878.post-48111442706474869752021-08-01T13:13:20.283+04:002021-08-01T13:13:20.283+04:00Автоматической перепроверки у нас нет, можно счита...Автоматической перепроверки у нас нет, можно считать что 'повезло' заметить: у нас вместе с продакшен трафиком гоняется много тестов/регрессий на тех же машинах/гриде, и где-то через месяц после миграции в GCP один раз(!) сломался один (!) тест - но сломался так опасно, что было решено докопаться, в чем дело. Но в целом, чтобы такое поймать, нужны достаточно параноидальные проверки, Anonymoushttps://www.blogger.com/profile/07075070710144613079noreply@blogger.comtag:blogger.com,1999:blog-410416665291724878.post-72777190850650003032021-07-05T13:08:30.842+04:002021-07-05T13:08:30.842+04:00О, это интересно. А у вас все результаты вычислени...О, это интересно. А у вас все результаты вычислений автоматически перепроверяются, или это был удачный случай? А то я, когда про свои системы думаю, с трудом могу оценить, насколько далеко мог бы утечь неправильный результат от места, где он получился. Ruslan Chereminhttps://www.blogger.com/profile/01023948540752159657noreply@blogger.comtag:blogger.com,1999:blog-410416665291724878.post-80198137665612866322021-07-05T00:14:01.813+04:002021-07-05T00:14:01.813+04:00Спасибо за комментарии к оригинальной статье - люб...Спасибо за комментарии к оригинальной статье - любопытно был наткнуться на это в своей ленте, так как один из оригинальных кейсов для исследования был наш продакшен в GCP :) Выглядело как нестабильное FPU вычисление, только на одной из машин, и только на одном наборе данных - но для конкретных данных/машины воспроизводилось в 100% случаев. К счастью, результат вычислений был очевидно неправильнымAnonymoushttps://www.blogger.com/profile/07075070710144613079noreply@blogger.comtag:blogger.com,1999:blog-410416665291724878.post-33540373666176160752021-06-14T21:50:31.002+04:002021-06-14T21:50:31.002+04:00>я пока не видел систем которые одновременно тр...>я пока не видел систем которые одновременно требовали и гугловой масштабируемости и не-гугловой надежности <br /><br />Так авторы отмечают, что /некоторые/ дефекты CPU будут компенсироваться теми же инструментами, которые уже используются для компенсации ошибок дисков и сети и т.п. А /некоторые/ -- нет. Даже в отказоустойчивых распределенных системах с большим резервированием обычно Ruslan Chereminhttps://www.blogger.com/profile/01023948540752159657noreply@blogger.comtag:blogger.com,1999:blog-410416665291724878.post-8496644375123410902021-06-14T21:16:36.481+04:002021-06-14T21:16:36.481+04:00ошибки в софте - этот подход не раешает, поэтому ....ошибки в софте - этот подход не раешает, поэтому ... бывают еще followers, которые могут пропустить запросы на которых завалились leaders :) я бы скорей рассматривал ситуацию в разрезе - как можно существенно увеличить надежность системы без потери производительности. дальше клиент решает - готов он платить или нет nevgenievhttps://www.blogger.com/profile/12201438846539790082noreply@blogger.comtag:blogger.com,1999:blog-410416665291724878.post-5222544882943589102021-06-14T21:09:06.759+04:002021-06-14T21:09:06.759+04:00ecc/crc решают задачу лишь от части.. сбойнуть мог...ecc/crc решают задачу лишь от части.. сбойнуть могут - процессор, память, сетевая карта, свитч... ну и не так дорого как кажется. кроме того ecc память как-то вот уж СИЛЬНО медленней не-ecc. и возможно мне везло, но я пока не видел систем которые одновременно требовали и гугловой масштабируемости и не-гугловой надежности :)nevgenievhttps://www.blogger.com/profile/12201438846539790082noreply@blogger.comtag:blogger.com,1999:blog-410416665291724878.post-27969976496984882892021-06-14T21:06:39.377+04:002021-06-14T21:06:39.377+04:00...но надо еще учитывать, что 3х-кратное резервиро......но надо еще учитывать, что 3х-кратное резервирование с голосованием работает в предположении, что ошибки -- это независимые случайные события. Вообще говоря, это не так: например, софтовые ошибки будут возникать во всех 3 вычислителях одновременно. Поэтому, как я понимаю, в аэрокосмосе по общей спеке 3 команды разрабатывают 3 /разных/ программы -- чтобы ошибки у них были в разных местах. Но Ruslan Chereminhttps://www.blogger.com/profile/01023948540752159657noreply@blogger.comtag:blogger.com,1999:blog-410416665291724878.post-58654885076397421432021-06-14T20:55:53.664+04:002021-06-14T20:55:53.664+04:00Так это и есть 3х-резервирование с голосованием. С...Так это и есть 3х-резервирование с голосованием. Справляются, да (пока есть уверенность, что /логика голосования/ не содержит дефектов :) <br /><br />Вопрос в цене -- трехкратное дублирование всех вычислений не каждый себе может позволить. Авиация, космонавтика, вероятно, автомобильные автопилоты -- да, конечно. В массе же -- вряд ли.<br /><br />Ни CRC, ни даже ECC -- для сравнения -- не требуют Ruslan Chereminhttps://www.blogger.com/profile/01023948540752159657noreply@blogger.comtag:blogger.com,1999:blog-410416665291724878.post-91976286802510722482021-06-14T20:21:13.542+04:002021-06-14T20:21:13.542+04:00мне кажется, что существующие софтверные системы а...мне кажется, что существующие софтверные системы автокоррекции железных ошибок прекрасно справляются и с этой проблемой тоже. нечетное количество (3) дублирующих active servers ответ пользователю посылается после получения кворумного количества (2) одинаковых ответов. сервер приславший отличный (от других) ответ - гасится. что-то не так с этой схемой?nevgenievhttps://www.blogger.com/profile/12201438846539790082noreply@blogger.com