Экземпляр гаечного ключа в одном облаке работает очень плохо

Question

Мы использовали Cloud Spanner с тремя экземплярами и получили хорошую производительность

9,010 mutations
in 0.168 seconds
across 106 rows and 85 columns
or 53,630 mutations per second

Поскольку мы все еще развиваемся, мы решили только использовать один экземпляр, чтобы сэкономить затраты на разработку. К сожалению, у нас очень низкая производительность. Гораздо меньше, чем просто снижение вышеупомянутого на 66%. Мы видим

85 mutations mutation
in 1.7 seconds
across 1 row and 85 columns
or 50 mutations per second

Мы идем от 53 630 мутаций в секунду до 50 мутаций в секунду. Это снижение производительности более чем на 1/1000 вместо прогнозируемого 1/3.

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

РЕДАКТИРОВАТЬ: Просто чтобы прояснить ситуацию, мы используем пакетную вставку и когда мы "уменьшив "с 3 экземпляров до 1, мы взорвали экземпляры и начали заново с 1.

Answer 1

GCP решил, что пошло не так в этой проблеме . Копирование соответствующей части в случае, если URL уменьшается:

Сокращение количества узлов с 3 до 1 довольно радикально для Cloud Spanner (сравнимо с 300 до 100). Продукт обеспечивает высокую доступность, данные реплицируются в разных зонах. Итак, что произошло в фоновом режиме, так это то, что все данные из всех реплик должны быть реструктурированы в фоновом режиме в 1 узел. Это относительно большая операция, которая должна занять некоторое время. По завершении фоновой операции производительность должна вернуться к ожидаемому уровню.

Answer 2

(рекламный комментарий для ответа).

Я предполагаю, что статистика мониторинга экземпляра Spanner (CPU, чтение и запись QPS) была низкой на этом этапе, поэтому экземпляр не был перегружен ...

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

С другой стороны, вы можете проверить статистику мониторинга задержек RPC в стеках-драйверах для API-интерфейсов Spanner, чтобы точно определить, где находится задержка (хотя она наиболее вероятна в Commit).