Size: a a a

Russian Backup User Group

2021 January 25

LM

Loxmatiy Mamont in Russian Backup User Group
но в целом, опять же, звоните в сапорт, пусть глянут чего у вас там понастроено. а то тут по крупице информацию вытягивать никакого удовольствия
источник

YT

Yaroslav Talabuyev in Russian Backup User Group
до лимита 28 дело практически не доходит
источник

LM

Loxmatiy Mamont in Russian Backup User Group
тогда в чём проблема? по вашему описанию получается, что новый процессор нечем загружать
источник

YT

Yaroslav Talabuyev in Russian Backup User Group
со стороны репозитория процесс вима потребляет только один сокет и за его рамки выйти не может
источник

LM

Loxmatiy Mamont in Russian Backup User Group
»по вашему описанию получается, что новый процессор нечем загружать
источник

LM

Loxmatiy Mamont in Russian Backup User Group
может это и какая-то бажина из-за которой агент на репе не находит новый проц, но это только в сапорте скажут
источник

LM

Loxmatiy Mamont in Russian Backup User Group
или предложат пересканировать сервер и всё заведётся
источник

YT

Yaroslav Talabuyev in Russian Backup User Group
или накатить еще один инстанс vbr и подключить ему этот же репозиторий, тогда будет второй процесс вима запускаться, и он будет жить во втором сокете. Мне кажется тут вопрос аппаратный. Когда одному процессу не хватает памяти в сокете - он получает эту память по шине и она тормозит. Даже ж в рекомендация вари пишут, если вм надо больше озу, чем есть в одном сокете - давайте ей 2 сокета для оптимальной работы.
источник

YT

Yaroslav Talabuyev in Russian Backup User Group
в общем по ходу это не виму, а организации работы многосокетных систем.
источник

YT

Yaroslav Talabuyev in Russian Backup User Group
один процесс не может скушать больше ядер и рама чем есть на одном сокете
источник

AV

Alexandr Vasiliev in Russian Backup User Group
Yaroslav Talabuyev
или накатить еще один инстанс vbr и подключить ему этот же репозиторий, тогда будет второй процесс вима запускаться, и он будет жить во втором сокете. Мне кажется тут вопрос аппаратный. Когда одному процессу не хватает памяти в сокете - он получает эту память по шине и она тормозит. Даже ж в рекомендация вари пишут, если вм надо больше озу, чем есть в одном сокете - давайте ей 2 сокета для оптимальной работы.
Если репозиторий - это сервер - то его только в один ВБР получится подключить как сервер
источник

YT

Yaroslav Talabuyev in Russian Backup User Group
один гипер-в хост по такой же логике должен быть подключен к одному vbr, но на практике работает - главное чтобы версии одинаковые были
источник

YT

Yaroslav Talabuyev in Russian Backup User Group
это наверное нельзя делать с точки зрения вима и саппорта, но в какой-то переходной период мы такое проверяли - была какая-то мутная история с лицензированием и инстансами, но кейс рабочий)
источник

YT

Yaroslav Talabuyev in Russian Backup User Group
Yaroslav Talabuyev
в общем по ходу это не виму, а организации работы многосокетных систем.
на тестовой тачке 7зип спокойно потребил память за рамками своего сокета,  в ступор поставил)
источник

D

Dim-soft in Russian Backup User Group
где почитать, как сам veeam мигрировать ?
источник

LM

Loxmatiy Mamont in Russian Backup User Group
я бы спросил у гугля хау ту мигрейт вим ;)
источник

LM

Loxmatiy Mamont in Russian Backup User Group
скорее всего правильный ответ будет в первых трёх ссылках
источник

VK

Victor Konovalov in Russian Backup User Group
Dim-soft
где почитать, как сам veeam мигрировать ?
На комволт? 🤔
источник

EE

Eugene Elizarov in Russian Backup User Group
Yaroslav Talabuyev
со стороны репозитория процесс вима потребляет только один сокет и за его рамки выйти не может
а какая вообще версия ВБР?
источник

YT

Yaroslav Talabuyev in Russian Backup User Group
9.5u4
источник