ax7: Пробовал ли кто-нибудь сжимать каталог с исходными текстами на виртуалке? Ускоряется ли разработка?

[DSPIC]

В моем случае, есть мощнейший физический сервер (WIN2012R2), на которм в Hyper-V крутится D365. Больше на сервере ничего нет, только Hyper-V и только одна единсвенная D365. 4-канальная 65 GB RAM + PCI-E SSD, Xeon E5-1650v4, 3.6GHz

Из-под виртуалки перформанс-монитор выглядит "слегка" недозагруженным.


Я бы не сказал, что она летает. Конечно, не сравнить с лаптопом, но тормознутость продолжает выбешивать. Я сделал вывод, что узкое место - архитектура, а не железо, иначе - что тут еще наростить, я не знаю.
Из спортивного интереса, я бы еще попробовал отсадить SQL на отдельный физический сервер, мне кажется, это одно из реальных узких мест. (альтернативно, вынести SQL DB на отдельные физические диски, как в AZURE)

Ну и самое, на мой взгяд, узкое место - это собственно, сама виртуалка. Если бы была возможность прямой инсталяции, было бы веселее.

[mazzy]

о, приятно ошибаться.
спасибо.

щас.

[mazzy]

Цитата:

Сообщение от DSPIC

Из-под виртуалки перформанс-монитор выглядит "слегка" недозагруженным.

из-под виртуалки смотреть перформанс-монитор не особо полезно. там счетчики искажены. но на хосте картина такая же - процессоры недогружены, а диск перегружен и постоянно в очередях. тоже два SSD.

поэтому и возникает вопрос - можно ли не затрагивая архитектуру, уменьшить число операций с диском, за счет увеличения нагрузки на процессор.

отсюда и вопрос про сжатие на лету.

Цитата:

Сообщение от DSPIC

но тормознутость продолжает выбешивать.

...не переставая. точно.

Цитата:

Сообщение от DSPIC

Я сделал вывод, что узкое место - архитектура, а не железо

согласен.

но все-таки пытаюсь найти решение.

в предопределенных майкрософтом вирутальных машинах обязательно стоит добавить исключения в антивирус. сразу станет дышать легче.

в предопределенных майкрософтом виртуальных машинах на 16Гб стоит увеличивать память для SQL до 6Гб (по умолчанию 4.5Гб). После увеличения памяти, SQL тут же перестает постоянно выбрасывать Page Fault и успокаивается в отведенных рамках.

в предопределенных майкрософтом виртуальных машинах стоит пошаманить с IIS и application pool. У меня пока нет однозначных рекомендаций. Пробую всякое.

Ну и пытаюсь понять влияние сжатия на. Дело в том, что исходники (текстовые файлы) хорошо сжимаются. Кроме того, насколько я знаю, в одном экстенте на диске может хранится несколько сжатых файлов одновременно. Поэтому есть шанс, что при работе с исходниками число дисковых операций уменьшится сильно. А также есть надежда, что более оптимально будет использоваться кэш самих виндов. Это только предположения.

Цитата:

Сообщение от DSPIC

Из спортивного интереса, я бы еще попробовал отсадить SQL на отдельный физический сервер, мне кажется, это одно из реальных узких мест. (альтернативно, вынести SQL DB на отдельные физические диски, как в AZURE)

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

Цитата:

Сообщение от DSPIC

Ну и самое, на мой взгяд, узкое место - это собственно, сама виртуалка. Если бы была возможность прямой инсталяции, было бы веселее.

такая возможность есть. внутри мс есть фанаты и были обсуждения по этому поводу.

для клиентов это возможно хороший путь. особенно когда устаканится.
но внутри МС это тупик. потому что:
разработчик внутри МС очень часто переключается между версиями. Сегодня 7.1, Завтра 7.2, Послезавтра 7.3, потом dax6.3, 6.2, а затем обратно. очень часто для внутренних работ нужна не просто версия, а конкретный билд. Часто нужно несколько разных версий одновременно в разных виртуалках.

поэтому внутри МС виртуалки очень полезны и очень помогают.

поэтому и хотелось бы понять что можно сделать тривиальными настройками в рамках существующих виртуалок.

[mazzy]

Цитата:

Сообщение от DSPIC

в предопределенных майкрософтом вирутальных машинах обязательно стоит добавить исключения в антивирус. сразу станет дышать легче.

в предопределенных майкрософтом виртуальных машинах на 16Гб стоит увеличивать память для SQL до 6Гб (по умолчанию 4.5Гб). После увеличения памяти, SQL тут же перестает постоянно выбрасывать Page Fault и успокаивается в отведенных рамках.

в предопределенных майкрософтом виртуальных машинах стоит пошаманить с IIS и application pool. У меня пока нет однозначных рекомендаций. Пробую всякое.

И еще. Тривиальнейшая настройка, но внутри МС работает замечательно.

В залпанированных задачах Виндов есть много задач по обслуживанию виндов, которые выполняются в нерабочее для пользователя время - "ночью". Внутри МС такие задачи приходят с доменными политиками. А если используется Server 2016, то он и сам много чего обслуживающего делает "ночью".

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

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

Какое-то время я упарывался и переводил часовой пояс у всех пользователей, до которых мог дотянутся. Но потом решил, что достаточно менять только у себя.

Настройка тривиальная, а от бесявых рывков и подтормаживаний избавляет.

[EVGL]

Цитата:

Сообщение от DSPIC

В моем случае, есть мощнейший физический сервер (WIN2012R2), на которм в Hyper-V крутится D365. Больше на сервере ничего нет, только Hyper-V и только одна единсвенная D365. 4-канальная 65 GB RAM + PCI-E SSD, Xeon E5-1650v4, 3.6GHz

Орёл! То есть Арёл!

[MikeR]

Добавлю свои пять копеек, SQL надо не просто отсаживать от других компонентов D365, но и на другой диск (именно физический отдельный диск), это однозначно повысит производительность. Пока не экспериментировал с архивами, но уверен, что прирост будет не самый ощутимый, по сравнению с вынесением SQL в другую виртуалку и на другой физический жесткий диск.

[trud]

Цитата:

Сообщение от DSPIC

4-канальная 65 GB RAM + PCI-E SSD, Xeon E5-1650v4, 3.6GHz

Цитата:

Сообщение от EVGL

Орёл! То есть Арёл!

Да грамотный конфиг. а мониторы какие?
на самом деле непонятно как может быть узким местом диск с производительностью более 100тыс IOPS. на дев виртуалках в ажур с обычными дисками все работает медленно да, но если мы говорим о локальном SSD разницы то быть не должно

еще конечно заметил - мы довольно много работали на 7.0 CTP7, текущая 7.2 в части VS заметно тормознее на том же оборудовании. что будет в 7.3 и далее даже страшно представить

[mazzy]

Цитата:

Сообщение от trud

на самом деле непонятно как может быть узким местом диск с производительностью более 100тыс IOPS.

виртуалки ))

Цитата:

Сообщение от trud

на дев виртуалках в ажур с обычными дисками все работает медленно да, но если мы говорим о локальном SSD разницы то быть не должно

дык, перетаскиваем виртуалки на локальные машины. результат тоже не впечатляет.
согласен, должно летать. не летает.

ниже профиль хоста с моими текущими экспериментами.
это простаивающие виртуалки. и тривиальный таск менеджер, а не счетчики.

disk 0 - физический HDD для системы.
disk 1, disk2 - физические SSD, сейчас объединенные в программный пул.
я пытался экспериментировать с SSD в аппаратном RAID
я пытался экспериментировать с отдельными SSD и вручную расположенными VHDX/AHDX - файлами
сейчас собираю статистику для дисков, программно объединенных в один большой дисковый пул.


повторюсь - ручной конфиг возможен. но это закат солнца вручную. оправдано, если виртуалка надолго. в условиях, когда машины постоянно меняются, ручной конфиг неэффективен. поэтому пока ищу тривиальные настройки внутри виртуалки, которые могут повлиять на производительность разработки (не продакшен).

[Logger]

Цитата:

Сообщение от mazzy

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

А вы уверены что проблема точно в виртуалках?

Как это можно проверить :
1. (Вариант для неленивых) - сделать инсталляцию на обычном серваке (невиртуальном). попробовать там.

или

2. Развернуть на той же виртуалке 2009-й аксапту. Посмотреть на ее скорость. Если все ок, то есть подозрения что корень тормозов в Ax7.