If KVM_CAP_SYNC_REGS is defined, these fields allow userspace to access certain guest registers without having to call SET/GET_*REGS. Thus we can avoid some system call overhead if userspace has to handle the exit. Userspace can query the validity of the structure by checking kvm_valid_regs for specific bits. These bits are architecture specific and usually define the validity of a groups of registers. (e.g. one bit for general purpose registers)
И другие "уменьшаторы" накладных расходов описаны на популярном ресурсе.
Печально, что от обычной нормальной базы пытаются уйти в другие абстракции - которые на более высоком уровне якобы решат проблемы лежащие ниже.
Вы ответили на удобный вопрос. Будут ли техническое описание, вроде как хабр это про технологии, а не про маркетинговый мусор. Расскажите что ваше решение - это не "Болдженос". Удачи, надеюсь мои предположения ошибочны.
Ясно что ссылки на гитхаб не будут. Но хотя бы схему взаимодействия и принцип работы можно нарисовать. А так смотрится как очередной супер проект с целью нагнать аудиторию в телеграм....
И работает и есть проблемы. Не все модели будут корректно работать если купите самый дорогой mac studio. Оставлю это https://github.com/pytorch/pytorch/issues/141287 - некоторые модели и в том числе для дообучения - будут работать через процессор, что вызывает печаль. Не стал бы на данный момент инвестировать в яблоки, если цель запускать модели и остальные вещи связанные с ML
Считаю статью неполной т.к. нет отдельного пункта про "нескучные обои". Требую на уровне законодательства ввести обязательное требование обозревать обои во всех новых дистрибутивах!
Во многих статьях под словом "домены" - чаще всего подразумевали другие языки, в рамках вашей статьи насколько понял, используется только русский язык, а домены - это наборы данных разного качества и содержимого.
Еще хотел уточнить, делали ли вы гибридную модель, где есть 2 головы - CTC (на быстрое распознавание) и RNNT (на более точное) и как такую модель используете в своих проектах?
И на вопрос, который вы обычно не отвечаете на своих докладах и выступления, ну или говорите фразу типа "бесплатного google colab для этого не хватит" - так все таки, сколько времени и на каких мощностях вы обучили модель которую выложили и с какой попытки получилось? Спасибо.
О, интересно. А можно подушнить? Пишу по факту, давно брали компанией у вас достаточно много серверов и пару штук были глючные, настолько что при после установки дистрибутива были проблемы во время работы - конечно винил только свои кривые руки, а не сервер или неисправный процессор, что также сообщала ваша техническая поддержка, потеряв пару дней, нам заменили сервер и компенсировали 2 дня для данных серверов. С тех пор приходится быть с провайдером связи очень прямолинейным - не работает железка, просто возьмите и замените, зачем мне терять время, которое мне никто не компенсирует. Надеюсь с новыми серверами в случае глюков, вы не заставляете клиентов проводить дебаг за свой счет. Спасибо.
Интересно, а админы clickhouse знают что вы вставляете в distributed table? Помню на старой работе такое не приветствовалось т.к. кластер зукипера чувствовал себя не очень при таких нагрузках?
Странно, почему так мало причин по уходу постгреса в кубернетесь на bare metal или укажите по ресурсам в кубере и какие железяки стали целевыми. Графики по latency до и после будут?
Это получается rsync в кроне. Проверяли ли состояние гонки, когда большой файл не успевает провести синхронизацию за интервал задания? Где система хранит индексы и как справится с условным миллиардом мелких файликов? Думаю что делали тесты и знаете какие есть ограничения.
Господа. Когда делал тесты и решил попробовать ваш дистрибутив SelectOS, то по неизвестной мне причине postgresql и clickhouse показал худший результат по сравнению с Debian11 и Ubuntu22. Может, если выпустили свой дистрибутив сделайте сравнение с другими - будет интересно.
Я, Алексей и пару лет компания отказалась от "Редис как сервис" в облаке cloud.ru на платформе huawei. Вопрос, починили ли ваши китайские коллеги поведение, когда гигабитный порт в редисе при использовании master-replica не совсем гигабитный, а пополам?
Что я имею ввиду - купили редис как сервис на довольно хороших ресурсах 16 cpu 64 gb ram и жили не тужили, тут раз нагрузка - резко увеличилась задержка с стороны приложений. Смотрим на процессоры, утилизируется всего 4, смотрим на память, еще половина свободна, сеть - всего половина утилизировано - около 400 мбит из 1 гбит. Писали тикет, в двери хлопали - "облако" проблем не обнаружило, проблема где то с стороны вашего приложения.....
Предположил, что возможно облако биллингует редис по полной т.е. трафик от мастера к реплике также входит в этот же гигабит. Быстро поднял редис в кубере - переключил - трафик стал 540 мбит до редис и задержки очень уменьшились - ну а редис как сервис решили похоронить и не использовать впредь.
Лень было искать ссылку. Не все так плохо, можно было описать более ёмко "Взаимосвязь жизненных циклов ПО". Удачи в развитии cozystack, фиксируем тот факт, что пока вы не будете делать форк кубера для своих задач, ждем! :-)
Согласен.
Маркетологи компании, отдайте обратно аккаунт Андрею. В дополнение можно почитать доку https://docs.kernel.org/virt/kvm/api.html
И другие "уменьшаторы" накладных расходов описаны на популярном ресурсе.
Печально, что от обычной нормальной базы пытаются уйти в другие абстракции - которые на более высоком уровне якобы решат проблемы лежащие ниже.
В статье не хватает картинок, где llm вместо alter использует drop т.к. это быстрее...
Вы ответили на удобный вопрос. Будут ли техническое описание, вроде как хабр это про технологии, а не про маркетинговый мусор. Расскажите что ваше решение - это не "Болдженос". Удачи, надеюсь мои предположения ошибочны.
Ясно что ссылки на гитхаб не будут. Но хотя бы схему взаимодействия и принцип работы можно нарисовать. А так смотрится как очередной супер проект с целью нагнать аудиторию в телеграм....
И работает и есть проблемы. Не все модели будут корректно работать если купите самый дорогой mac studio. Оставлю это https://github.com/pytorch/pytorch/issues/141287 - некоторые модели и в том числе для дообучения - будут работать через процессор, что вызывает печаль. Не стал бы на данный момент инвестировать в яблоки, если цель запускать модели и остальные вещи связанные с ML
Считаю статью неполной т.к. нет отдельного пункта про "нескучные обои". Требую на уровне законодательства ввести обязательное требование обозревать обои во всех новых дистрибутивах!
Во многих статьях под словом "домены" - чаще всего подразумевали другие языки, в рамках вашей статьи насколько понял, используется только русский язык, а домены - это наборы данных разного качества и содержимого.
Еще хотел уточнить, делали ли вы гибридную модель, где есть 2 головы - CTC (на быстрое распознавание) и RNNT (на более точное) и как такую модель используете в своих проектах?
И на вопрос, который вы обычно не отвечаете на своих докладах и выступления, ну или говорите фразу типа "бесплатного google colab для этого не хватит" - так все таки, сколько времени и на каких мощностях вы обучили модель которую выложили и с какой попытки получилось? Спасибо.
О, интересно. А можно подушнить? Пишу по факту, давно брали компанией у вас достаточно много серверов и пару штук были глючные, настолько что при после установки дистрибутива были проблемы во время работы - конечно винил только свои кривые руки, а не сервер или неисправный процессор, что также сообщала ваша техническая поддержка, потеряв пару дней, нам заменили сервер и компенсировали 2 дня для данных серверов. С тех пор приходится быть с провайдером связи очень прямолинейным - не работает железка, просто возьмите и замените, зачем мне терять время, которое мне никто не компенсирует. Надеюсь с новыми серверами в случае глюков, вы не заставляете клиентов проводить дебаг за свой счет. Спасибо.
Жизненный цикл ПО у AMD короче в 2 раза чем у NVIDIA - эта ситуация многим надоела.
В это время nvidia поддерживает свои старые карты 9-10 лет, а тут amd дала подарок и стала на карты 4х летней давности "продлила" поддержку...
Нужно больше статей про контейнеры..... Но пока лучшая https://habr.com/ru/articles/935178/
Возможно люди просто не желают читать контент сгенерированный нейросетью....
Все описано в доке https://clickhouse.com/docs/ru/guides/sre/keeper/clickhouse-keeper
Акцент на линейность чтения и записи и конечно по ресурсам кипер в отношении памяти менее прожорлив в отличие от zookeeper.
По статье - надеюсь тут говорится про тестовый стенд, а не реализацию в production.
Интересно, а админы clickhouse знают что вы вставляете в distributed table? Помню на старой работе такое не приветствовалось т.к. кластер зукипера чувствовал себя не очень при таких нагрузках?
Странно, почему так мало причин по уходу постгреса в кубернетесь на bare metal или укажите по ресурсам в кубере и какие железяки стали целевыми. Графики по latency до и после будут?
Это получается rsync в кроне. Проверяли ли состояние гонки, когда большой файл не успевает провести синхронизацию за интервал задания? Где система хранит индексы и как справится с условным миллиардом мелких файликов? Думаю что делали тесты и знаете какие есть ограничения.
Отдохните и пишите достойные технические интересные статьи. Удачи!
Господа. Когда делал тесты и решил попробовать ваш дистрибутив SelectOS, то по неизвестной мне причине postgresql и clickhouse показал худший результат по сравнению с Debian11 и Ubuntu22. Может, если выпустили свой дистрибутив сделайте сравнение с другими - будет интересно.
Я, Алексей и пару лет компания отказалась от "Редис как сервис" в облаке cloud.ru на платформе huawei. Вопрос, починили ли ваши китайские коллеги поведение, когда гигабитный порт в редисе при использовании master-replica не совсем гигабитный, а пополам?
Что я имею ввиду - купили редис как сервис на довольно хороших ресурсах 16 cpu 64 gb ram и жили не тужили, тут раз нагрузка - резко увеличилась задержка с стороны приложений. Смотрим на процессоры, утилизируется всего 4, смотрим на память, еще половина свободна, сеть - всего половина утилизировано - около 400 мбит из 1 гбит. Писали тикет, в двери хлопали - "облако" проблем не обнаружило, проблема где то с стороны вашего приложения.....
Предположил, что возможно облако биллингует редис по полной т.е. трафик от мастера к реплике также входит в этот же гигабит. Быстро поднял редис в кубере - переключил - трафик стал 540 мбит до редис и задержки очень уменьшились - ну а редис как сервис решили похоронить и не использовать впредь.
Лень было искать ссылку. Не все так плохо, можно было описать более ёмко "Взаимосвязь жизненных циклов ПО". Удачи в развитии cozystack, фиксируем тот факт, что пока вы не будете делать форк кубера для своих задач, ждем! :-)