По этой же причине отвал был и у xbox 360, и у nvidia чипов.
Помню эти времена и все эти колхозные решения. Реболл это был высший пилотаж. Обычно же в домашних условиях кулер посильнее прикручивался, так называемой метод прижима. Мой 360 в таких условиях прожил еще несколько лет. Сначала да, думали на шарики под bga. Потом уже додумали, что на самом деле проблема в креплении кристалла к подложке. А видео выше дало еще более точный ответ - проблема в компаунде. Тогда не помню, чтобы о такой версии говорили.
Именно! Когда язык не однороден - тут значение, а тут типа тоже "значение", которое указатель, появляется много не очевидных моментов в таких структурах.
Язык то как раз предельно однороден. Все передается по значения и этот постулат нигде не нарушается. Ни у слайсов, ни у мап, ни у каналов.
Менять строки запрещено спецификацией языка. Там четко написано, immutable. Все отхождения от нее это неопределенное поведение. Строка может быть литералом, который указывает на read-only секцию в бинаре. Если попробуешь поменять, то получишь SIGBUS или SIGSEGV какой-нить. Если строка таки на хипе, то поведение уже вполне себе неопределенное. unsafe на то и unsafe, что он позволяет нарушать спеку и инварианты языка. Прямо как Rust.
Подобные ошибки с мапами могут совершать только совсем зеленые гошники. Всем известна простая истина - в Go абсолютно все передается по значению. И в случае мапы значение это адрес на структуру. Из этого вытекает все остальное. Тоже самое с каналами.
Это мелочи, но их должен знать даже джун. И это не является недостатками или преимуществами. Это просто особенности языка, которые есть у всех. Уж value/reference семантика так подавно. Это вполне себе обычная вещь, знакомая любому C/C++/C# программеру. С памятью надо уметь работать и Go выбрал путь, где программистам доступны некоторые подробности работы с памятью.
И правильно. Так и надо собесы проводить, где каждый вопрос позволяет немного уйти в сторону и реально проверить, что человек знает. Необязательно прогонять человека по всем вопросам. Можно на одном зависнуть, затронуть опыт работы, коснуться конкретного проекта и этого будет достаточно, чтобы понять уровень человека.
Мапе нужна синхронизация по одной простой причине - нигде не сказано обратного, что она потокобезопасна. На этом вопрос, в общем-то, можно закрыть. Ну а если удариться в подробности реализации здесь и сейчас, то ответ тоже очень простой может быть. Мапы умеют определять конкурентный доступ к себе и кинут панику.
Если хочется подробностей, у Go есть модель памяти. Там описано, что делать можно, а что нет. Даже если бы у мапы не было перебалансировки, все равно делать так было бы нельзя. Мапа это большая структура. Операции с ней не будут атомарны и потоки будут видеть промежуточное некорректное состояние. Даже если мы один флажок пишем только в одном потоке, все равно нужны примитивы синхронизации, хотя бы какие-то. Барьер какой-нить или что-то, что и компилятору, и процессору намекнет, как правильно себя вести.
С такой шпаргалкой ни вы, ни кто либо другой собес явно не пройдет. Стоит самостоятельно таки поискать и поучить. Практически каждый ответ или полностью некорректный, или частично. При том что вопросы очень простые.
Строки immutable типы. Для них эти проблемы неактуальны вообще.
Map это reference тип. По-значению у него передается указатель на саму структуру внутреннюю. Копии никакие не делаются.
Слайс - да, это единственный встроенный тип в Go, который имеет value семантику и копирует свое внутреннее представление. Есть мелкие особенности из-за этого (тот самый append), которые на практике проблем не доставляют. Зато профита от value семантики выше крыши. Если бы это был reference тип, то было бы в разы хуже. Неудивительно, что мейнстрим языки точно так же слайсы реализуют.
позднее включение в работу GC, настроенное по умолчанию на 1.5секунды или около того. Сколько раз отработает микросервис за это время, сколько памяти оторжут его копии?
Скорее всего нисколько. В продакшен системах дольше этих 1.5сек будут отрабатывать хелсчеки банальные. Эта особенность не стоит даже упоминания.
И вообще неплохо бы пруф. Про подобное поведение слышу в первый раз. Чисто любопытства ради знать полезно было бы, если это так. Не более.
Я специально написал про физическое ограничение, а не программное. Поэтому диод это специальная железка, которая никакой не межсетевой экран. По-другому просто такое решение никто не допустит.
У вас же в статье вообще PHP - даже перекомпилировать ничего не нужно, поменял пару строк и всё.
Во-первых, статья не моя. Во-вторых, вроде в статье речь как раз о диоде как о специальной железке, через которую пропускают пакеты. PHP код в статье - это клиент, который эти пакеты сквозь нее и посылает, и сервер, который их принимает и собирает обратно. Все как надо.
Ага. Такие вещи нужно делать с накоплением всех пакетов в памяти или во внешнем хранилище. Чтобы и дедупликацию сделать, и на порядок пакетов было пофиг. У нас редис стоял под эти цели. Что заодно позволило сделать схему отказоустойчивой и масштабируемой.
Я не оспариваю необходимость деления на пакеты и подсчёта потерь. Я говорю, что уровень OSI выбран не тот.
Почему? На уровне приложений наиболее удобно работать с транспортными протоколами. Раз у нас диод, то ничего кроме UDP не прокатит. Вот его и используем. Других нормальных вариантов просто и нет.
Диод же работает на L2 уровне. Принимает фреймы, подменяет маки, пуляет дальше.
Знаю эту штуку, работал, использовали. Для отделения секретного контура он не подходит, ибо там нет физического разделения, это всего лишь фаервол. Без диода не пропустят. Более того, даже его одного недостаточно было. Сертификат рубикона дает право его использовать внутри секретных контуров, это да.
Нет, это называет диод. Он все так же пропустит через себя пакеты только в одну сторону, потому что внутри он физически не имеет обратного канала передачи. Иначе бы сертификат не выдали.
Поэтому без всех этих танцев с бубнов с делением на пакеты, подсчетом сумм, периодическим подсчетом потерь на периоды времени, переотправкой и прочим гемором не обойтись. Мы это все делали тоже.
Прекрасно работает. Я с таким устройством лично работал. Фокус в том, что на ARP и ICMP отвечает каждая сторона этого устройства независимо, будто это две реальных сетевых железки со своим айпишником и маком
Не имеет значения, что поверх чего работает. Сертифицированное устройство однонаправленной передачи делает физически невозможным движение пакетов в обратную сторону. Принципиально. Там линий передачи просто нет в обратную сторону.
Тут я конечно больше ориентируюсь на сциллу. Там разница с касандрой реально огромная в перформансе и в том, как железка вообще утилизируется. Про редпанду тоже слышал противоречивые отзывы и, честно говоря, не совсем понимаю, зачем ее переписывать. По опыту с кафкой, она кушает мизерно число ресурсов и переваривает огромное количество трафика при этом.
Почему? Софт честно требует - ставьте меня на железо, где больше никого нет. И все будет хорошо. Сцилла в таких условиях работает прекрасно и от правильной настройки там разница производительности огромна. Здесь думаю тоже самое, раз базируется на том же seastar. Ноги растут от туда.
Уж виртуалки то вполне можно, раз сцилла позволяет. Самое главное это стабильный паттерн производительности. Если четко соблюдаются шары на проц и диски, то все должно быть ок.
Это не тот инструмент, где можно ждать гибкости. Архитектура seastar заточено под конкретные условия и не терпит отхождения. От того оно такое и быстрое.
Очень сомневаюсь, что это кто-то всерьез воспримет.
по опыту сциллы, они не предназначены для соседства с чем-то. Вокруг этого построена вся их архитектура, в этом смысл фреймворка seastar. Потоки прибиваются к ядрам, на потоки мапятся жестко шарды. IO системы настраивается соотвествующий образом. Внутренний шедулер адаптируется под замеренные реальные показатели IO, и он ожидает, что они не будут хаотично меняться из-за шумного соседа. Это плата за скорость.
Совместим то совместим, но с точки зрения оператора кластера это абсолютно другая БД. Самое минимальное, используемый в статье JBOD там вообще не поддерживается. Ставьте на RAID0 и никак иначе. И таких "мелочией" там миллион.
По этой же причине отвал был и у xbox 360, и у nvidia чипов.
Помню эти времена и все эти колхозные решения. Реболл это был высший пилотаж. Обычно же в домашних условиях кулер посильнее прикручивался, так называемой метод прижима. Мой 360 в таких условиях прожил еще несколько лет. Сначала да, думали на шарики под bga. Потом уже додумали, что на самом деле проблема в креплении кристалла к подложке. А видео выше дало еще более точный ответ - проблема в компаунде. Тогда не помню, чтобы о такой версии говорили.
Можно сказать, переизобрели Loki
Язык то как раз предельно однороден. Все передается по значения и этот постулат нигде не нарушается. Ни у слайсов, ни у мап, ни у каналов.
Менять строки запрещено спецификацией языка. Там четко написано, immutable. Все отхождения от нее это неопределенное поведение. Строка может быть литералом, который указывает на read-only секцию в бинаре. Если попробуешь поменять, то получишь SIGBUS или SIGSEGV какой-нить. Если строка таки на хипе, то поведение уже вполне себе неопределенное. unsafe на то и unsafe, что он позволяет нарушать спеку и инварианты языка. Прямо как Rust.
Подобные ошибки с мапами могут совершать только совсем зеленые гошники. Всем известна простая истина - в Go абсолютно все передается по значению. И в случае мапы значение это адрес на структуру. Из этого вытекает все остальное. Тоже самое с каналами.
Это мелочи, но их должен знать даже джун. И это не является недостатками или преимуществами. Это просто особенности языка, которые есть у всех. Уж value/reference семантика так подавно. Это вполне себе обычная вещь, знакомая любому C/C++/C# программеру. С памятью надо уметь работать и Go выбрал путь, где программистам доступны некоторые подробности работы с памятью.
И правильно. Так и надо собесы проводить, где каждый вопрос позволяет немного уйти в сторону и реально проверить, что человек знает. Необязательно прогонять человека по всем вопросам. Можно на одном зависнуть, затронуть опыт работы, коснуться конкретного проекта и этого будет достаточно, чтобы понять уровень человека.
Мапе нужна синхронизация по одной простой причине - нигде не сказано обратного, что она потокобезопасна. На этом вопрос, в общем-то, можно закрыть. Ну а если удариться в подробности реализации здесь и сейчас, то ответ тоже очень простой может быть. Мапы умеют определять конкурентный доступ к себе и кинут панику.
Если хочется подробностей, у Go есть модель памяти. Там описано, что делать можно, а что нет. Даже если бы у мапы не было перебалансировки, все равно делать так было бы нельзя. Мапа это большая структура. Операции с ней не будут атомарны и потоки будут видеть промежуточное некорректное состояние. Даже если мы один флажок пишем только в одном потоке, все равно нужны примитивы синхронизации, хотя бы какие-то. Барьер какой-нить или что-то, что и компилятору, и процессору намекнет, как правильно себя вести.
С такой шпаргалкой ни вы, ни кто либо другой собес явно не пройдет. Стоит самостоятельно таки поискать и поучить. Практически каждый ответ или полностью некорректный, или частично. При том что вопросы очень простые.
Неправильно.
Строки immutable типы. Для них эти проблемы неактуальны вообще.
Map это reference тип. По-значению у него передается указатель на саму структуру внутреннюю. Копии никакие не делаются.
Слайс - да, это единственный встроенный тип в Go, который имеет value семантику и копирует свое внутреннее представление. Есть мелкие особенности из-за этого (тот самый append), которые на практике проблем не доставляют. Зато профита от value семантики выше крыши. Если бы это был reference тип, то было бы в разы хуже. Неудивительно, что мейнстрим языки точно так же слайсы реализуют.
Скорее всего нисколько. В продакшен системах дольше этих 1.5сек будут отрабатывать хелсчеки банальные. Эта особенность не стоит даже упоминания.
И вообще неплохо бы пруф. Про подобное поведение слышу в первый раз. Чисто любопытства ради знать полезно было бы, если это так. Не более.
Я специально написал про физическое ограничение, а не программное. Поэтому диод это специальная железка, которая никакой не межсетевой экран. По-другому просто такое решение никто не допустит.
Во-первых, статья не моя. Во-вторых, вроде в статье речь как раз о диоде как о специальной железке, через которую пропускают пакеты. PHP код в статье - это клиент, который эти пакеты сквозь нее и посылает, и сервер, который их принимает и собирает обратно. Все как надо.
Ага. Такие вещи нужно делать с накоплением всех пакетов в памяти или во внешнем хранилище. Чтобы и дедупликацию сделать, и на порядок пакетов было пофиг. У нас редис стоял под эти цели. Что заодно позволило сделать схему отказоустойчивой и масштабируемой.
Почему? На уровне приложений наиболее удобно работать с транспортными протоколами. Раз у нас диод, то ничего кроме UDP не прокатит. Вот его и используем. Других нормальных вариантов просто и нет.
Диод же работает на L2 уровне. Принимает фреймы, подменяет маки, пуляет дальше.
Знаю эту штуку, работал, использовали. Для отделения секретного контура он не подходит, ибо там нет физического разделения, это всего лишь фаервол. Без диода не пропустят. Более того, даже его одного недостаточно было. Сертификат рубикона дает право его использовать внутри секретных контуров, это да.
Нет, это называет диод. Он все так же пропустит через себя пакеты только в одну сторону, потому что внутри он физически не имеет обратного канала передачи. Иначе бы сертификат не выдали.
Поэтому без всех этих танцев с бубнов с делением на пакеты, подсчетом сумм, периодическим подсчетом потерь на периоды времени, переотправкой и прочим гемором не обойтись. Мы это все делали тоже.
Прекрасно работает. Я с таким устройством лично работал. Фокус в том, что на ARP и ICMP отвечает каждая сторона этого устройства независимо, будто это две реальных сетевых железки со своим айпишником и маком
Не имеет значения, что поверх чего работает. Сертифицированное устройство однонаправленной передачи делает физически невозможным движение пакетов в обратную сторону. Принципиально. Там линий передачи просто нет в обратную сторону.
Тут я конечно больше ориентируюсь на сциллу. Там разница с касандрой реально огромная в перформансе и в том, как железка вообще утилизируется. Про редпанду тоже слышал противоречивые отзывы и, честно говоря, не совсем понимаю, зачем ее переписывать. По опыту с кафкой, она кушает мизерно число ресурсов и переваривает огромное количество трафика при этом.
Почему? Софт честно требует - ставьте меня на железо, где больше никого нет. И все будет хорошо. Сцилла в таких условиях работает прекрасно и от правильной настройки там разница производительности огромна. Здесь думаю тоже самое, раз базируется на том же seastar. Ноги растут от туда.
Уж виртуалки то вполне можно, раз сцилла позволяет. Самое главное это стабильный паттерн производительности. Если четко соблюдаются шары на проц и диски, то все должно быть ок.
Это не тот инструмент, где можно ждать гибкости. Архитектура seastar заточено под конкретные условия и не терпит отхождения. От того оно такое и быстрое.
Очень сомневаюсь, что это кто-то всерьез воспримет.
по опыту сциллы, они не предназначены для соседства с чем-то. Вокруг этого построена вся их архитектура, в этом смысл фреймворка seastar. Потоки прибиваются к ядрам, на потоки мапятся жестко шарды. IO системы настраивается соотвествующий образом. Внутренний шедулер адаптируется под замеренные реальные показатели IO, и он ожидает, что они не будут хаотично меняться из-за шумного соседа. Это плата за скорость.
Совместим то совместим, но с точки зрения оператора кластера это абсолютно другая БД. Самое минимальное, используемый в статье JBOD там вообще не поддерживается. Ставьте на RAID0 и никак иначе. И таких "мелочией" там миллион.