Nano Hash - криптовалюты, майнинг, программирование

Мастер Redis выполняет на несколько команд больше, чем ведомый Redis.

Мы получаем очень интересный граф в нашей архитектуре Redis.

команды Redis

  • Зеленый: мастер
  • Синий: раб

Похоже, что главный Redis выполняет на 35 % больше команд, чем подчиненный Redis.

Это не всегда одинаковое расстояние.

Вот часть журнала активного сервера Redis:

[26911] 14 Feb 13:28:44 - DB 0: 2399 keys (417 volatile) in 16384 slots HT.
[26911] 14 Feb 13:28:44 - DB 1: 498 keys (498 volatile) in 1024 slots HT.
[26911] 14 Feb 13:28:44 - DB 2: 1 keys (0 volatile) in 4 slots HT.
[26911] 14 Feb 13:28:44 - 706 clients connected (1 slaves), 33794240 bytes in use

и в то же время на бальзаме:

[17748] 14 Feb 13:28:44 - DB 0: 2398 keys (417 volatile) in 16384 slots HT.
[17748] 14 Feb 13:28:44 - DB 1: 497 keys (497 volatile) in 1024 slots HT.
[17748] 14 Feb 13:28:44 - DB 2: 1 keys (0 volatile) in 4 slots HT.
[17748] 14 Feb 13:28:44 - 1 clients connected (0 slaves), 24839792 bytes in use

Таким образом, они выглядят так, как будто они синхронизированы почти 1: 1.

Мы задаемся вопросом, что может быть причиной этого разрыва. Также мы спрашиваем себя, означает ли это, что в Redis отправляются ненужные команды, которые мы можем оптимизировать.

redis master-slave
14.02.2012

  • Я думаю, что любые команды чтения не будут распространяться на ведомое устройство. Ты пишешь только на мастер, а читаешь с раба? Если вы читаете/пишете с ведущего, а не читаете с ведомого, это объясняет это. 14.02.2012
  • ох! .. хороший момент .. вы можете добавить свой комментарий в качестве ответа, чтобы люди (и я) могли повернуть его как правильный. 14.02.2012
  • Я добавил его в качестве ответа для дальнейшего использования. Пожалуйста, примите это, если это вас удовлетворило! :-) 15.02.2012

Ответы:


1

Вот возможное объяснение: total_commands_processed сообщает обо всех командах, операциях чтения, записи и командах, связанных с сервером. Только команды записи будут распространяться на ведомые устройства.

В настройке, где вы только пишете на мастер и читаете с ведомых, у вас будет более высокий total_commands_processed на ведомых (ях) (все чтения + все записи).

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

На самом деле очень маловероятно, что у ведущего и ведомого будет одинаковое количество total_commands_processed.

14.02.2012
  • Вы правы! Мы записываем/читаем всегда в/из сервер master. Если никто не скажет что-то еще, я проверю это. 15.02.2012
  • В этом случае у вас действительно будет больше total_commands_processed на master, так как (writes + reads) > writes. 15.02.2012
    • Новые материалы
    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..
    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..
    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..
    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..
    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..
    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..
    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..