12.12.2017, 20:21 | #1 |
Участник
|
ax7: Пробовал ли кто-нибудь сжимать каталог с исходными текстами на виртуалке? Ускоряется ли разработка?
AX7:
не секрет, что на виртуалках узкое место - диск, а процессор обычно остается недозагруженным. Пробовал ли кто-нибудь сжимать каталог с исходными текстами на виртуалке разработчика обычным виндовым сжатием папок? Ускоряется ли разработка? intellisence, компиляция, unit tests? Я попробовал на паре машин - положительный эффект вроде есть. Но не уверен, что это эффект именно сжатия, а не какое-нибудь случайное стечение обстоятельств. Кто-нибудь готов попробовать и поделиться результатами? было бы клево если бы вы попробовали повторить одно и то же длительное действие до сжатия и после сжатия. так, в моем текущем проекте задействовано 1104 unit test'а. полный прогон этих тестов: = до сжатия папки с исходными текстами 32 минуты = после сжатия 18 минут попробовал на двух виртуалках. |
|
|
За это сообщение автора поблагодарили: Logger (3). |
12.12.2017, 23:24 | #2 |
Боец
|
Mazzy - мастер задавать простые вопросы, ставящие в тупик. Почему сжатие папок, должно увеличить перформанс, а не наоборот? И почему, если процессор недогруженный, то узкое место - диск?
|
|
|
За это сообщение автора поблагодарили: kashperuk (1). |
13.12.2017, 00:00 | #3 |
Боец
|
В моем случае, есть мощнейший физический сервер (WIN2012R2), на которм в Hyper-V крутится D365. Больше на сервере ничего нет, только Hyper-V и только одна единсвенная D365. 4-канальная 65 GB RAM + PCI-E SSD, Xeon E5-1650v4, 3.6GHz
Из-под виртуалки перформанс-монитор выглядит "слегка" недозагруженным. Я бы не сказал, что она летает. Конечно, не сравнить с лаптопом, но тормознутость продолжает выбешивать. Я сделал вывод, что узкое место - архитектура, а не железо, иначе - что тут еще наростить, я не знаю. Из спортивного интереса, я бы еще попробовал отсадить SQL на отдельный физический сервер, мне кажется, это одно из реальных узких мест. (альтернативно, вынести SQL DB на отдельные физические диски, как в AZURE) Ну и самое, на мой взгяд, узкое место - это собственно, сама виртуалка. Если бы была возможность прямой инсталяции, было бы веселее. |
|
|
За это сообщение автора поблагодарили: EVGL (3), trud (3). |
13.12.2017, 00:18 | #4 |
Участник
|
Цитата:
Понятно, не пробовал, загрузку не смотрел. ни на хост машине, ни на гостевой машине. 2. Потому что сжатие папок теоретически может уменьшить число дисковых операций. А в виртуальных машинах именно это самая медленная операция. 3. Такого утверждения не было. ) Я наверное плохо сформулровал. Ну, и ладно. А кто-нибудь пробовал в этом направлении рыть? Сжимать папки с исходными текстами, сжимать таблицы или базы SQL... именно на разработческих виртуалках. |
|
|
За это сообщение автора поблагодарили: Logger (3). |
13.12.2017, 00:19 | #5 |
Участник
|
о, приятно ошибаться.
спасибо. щас. |
|
13.12.2017, 00:37 | #6 |
Участник
|
из-под виртуалки смотреть перформанс-монитор не особо полезно. там счетчики искажены. но на хосте картина такая же - процессоры недогружены, а диск перегружен и постоянно в очередях. тоже два SSD.
поэтому и возникает вопрос - можно ли не затрагивая архитектуру, уменьшить число операций с диском, за счет увеличения нагрузки на процессор. отсюда и вопрос про сжатие на лету. ...не переставая. точно. согласен. но все-таки пытаюсь найти решение. в предопределенных майкрософтом вирутальных машинах обязательно стоит добавить исключения в антивирус. сразу станет дышать легче. в предопределенных майкрософтом виртуальных машинах на 16Гб стоит увеличивать память для SQL до 6Гб (по умолчанию 4.5Гб). После увеличения памяти, SQL тут же перестает постоянно выбрасывать Page Fault и успокаивается в отведенных рамках. в предопределенных майкрософтом виртуальных машинах стоит пошаманить с IIS и application pool. У меня пока нет однозначных рекомендаций. Пробую всякое. Ну и пытаюсь понять влияние сжатия на. Дело в том, что исходники (текстовые файлы) хорошо сжимаются. Кроме того, насколько я знаю, в одном экстенте на диске может хранится несколько сжатых файлов одновременно. Поэтому есть шанс, что при работе с исходниками число дисковых операций уменьшится сильно. А также есть надежда, что более оптимально будет использоваться кэш самих виндов. Это только предположения. Цитата:
становится как-то очень сложно с ssrs. а в майкрософтовском окружении перестают работать системы мониторинга и всякие бэбиситтеры. возможно, их можно победить. но нужно очень сильно разобраться. подозреваю, что ядро и установку изменят раньше, чем получится разобраться с этим. Цитата:
для клиентов это возможно хороший путь. особенно когда устаканится. но внутри МС это тупик. потому что: разработчик внутри МС очень часто переключается между версиями. Сегодня 7.1, Завтра 7.2, Послезавтра 7.3, потом dax6.3, 6.2, а затем обратно. очень часто для внутренних работ нужна не просто версия, а конкретный билд. Часто нужно несколько разных версий одновременно в разных виртуалках. поэтому внутри МС виртуалки очень полезны и очень помогают. поэтому и хотелось бы понять что можно сделать тривиальными настройками в рамках существующих виртуалок. |
|
|
За это сообщение автора поблагодарили: DSPIC (5). |
13.12.2017, 00:38 | #7 |
Боец
|
Цитата:
Не пробовал. Врядли даст ощутимый эффект. |
|
13.12.2017, 01:19 | #8 |
Участник
|
Цитата:
Сообщение от DSPIC
в предопределенных майкрософтом вирутальных машинах обязательно стоит добавить исключения в антивирус. сразу станет дышать легче.
в предопределенных майкрософтом виртуальных машинах на 16Гб стоит увеличивать память для SQL до 6Гб (по умолчанию 4.5Гб). После увеличения памяти, SQL тут же перестает постоянно выбрасывать Page Fault и успокаивается в отведенных рамках. в предопределенных майкрософтом виртуальных машинах стоит пошаманить с IIS и application pool. У меня пока нет однозначных рекомендаций. Пробую всякое. В залпанированных задачах Виндов есть много задач по обслуживанию виндов, которые выполняются в нерабочее для пользователя время - "ночью". Внутри МС такие задачи приходят с доменными политиками. А если используется Server 2016, то он и сам много чего обслуживающего делает "ночью". Так вот, виртуалки поставляются с часовым поясом -8. Для этого часового пояса "ночь" наступает как раз в то время когда здесь рабочий день и нужно продуктивно работать. Рекомендация - поставьте свой часовой пояс, выйдите и зайдите. тогда многие задачи по обслуживанию виндов будут запускаться в вашу ночь и не будут вам мешать в ваш рабочий день. Какое-то время я упарывался и переводил часовой пояс у всех пользователей, до которых мог дотянутся. Но потом решил, что достаточно менять только у себя. Настройка тривиальная, а от бесявых рывков и подтормаживаний избавляет. |
|
|
За это сообщение автора поблагодарили: alex55 (1). |
13.12.2017, 02:07 | #9 |
Banned
|
|
|
13.12.2017, 07:50 | #10 |
MCT
|
Добавлю свои пять копеек, SQL надо не просто отсаживать от других компонентов D365, но и на другой диск (именно физический отдельный диск), это однозначно повысит производительность. Пока не экспериментировал с архивами, но уверен, что прирост будет не самый ощутимый, по сравнению с вынесением SQL в другую виртуалку и на другой физический жесткий диск.
__________________
Axapta book for developer |
|
13.12.2017, 08:33 | #11 |
Участник
|
А сжатие sql баз?
|
|
13.12.2017, 08:36 | #12 |
Участник
|
Еще можно помониторить работу с тмп папками. Если пишет много и часто но не слишком большой объем, то можно сделать виртуальный диск в памяти и подмонтировать как папку.
Последний раз редактировалось Logger; 13.12.2017 в 08:39. |
|
13.12.2017, 09:48 | #13 |
Участник
|
Да грамотный конфиг. а мониторы какие?
на самом деле непонятно как может быть узким местом диск с производительностью более 100тыс IOPS. на дев виртуалках в ажур с обычными дисками все работает медленно да, но если мы говорим о локальном SSD разницы то быть не должно еще конечно заметил - мы довольно много работали на 7.0 CTP7, текущая 7.2 в части VS заметно тормознее на том же оборудовании. что будет в 7.3 и далее даже страшно представить |
|
|
За это сообщение автора поблагодарили: Logger (1). |
13.12.2017, 09:56 | #14 |
Участник
|
Цитата:
вот как выглядит запрос на создание такой машины. но я сильно не уверен, что такие виртуальные машины будут размещены на физически разных серверах. я нигде не видел таких гарантий (но я не видел и договора клиентского) инсталировать вручную - можно, но сравнимо с закатом солнца вручную. один-два раза можно, потом надоедает. кроме того, даже для отдельных виртуалок диски остаются узким местом. насколько я помню из попыток сделать "правильную" среду для разработчика во времена ax2012. Цитата:
2. насколько я читал, в современных виндах виртуальный диск хуже виндового кэша. насколько я понимаю, винда в последних версиях использует под кэш всю свободную память. в былые времена пробовал и такой вариант - совсем не впечатлило. но буду рад, если поделитесь результатами экспериментов в этом направлении. |
|
|
За это сообщение автора поблагодарили: MikeR (3). |
13.12.2017, 10:09 | #15 |
Участник
|
Цитата:
Цитата:
согласен, должно летать. не летает. ниже профиль хоста с моими текущими экспериментами. это простаивающие виртуалки. и тривиальный таск менеджер, а не счетчики. disk 0 - физический HDD для системы. disk 1, disk2 - физические SSD, сейчас объединенные в программный пул. я пытался экспериментировать с SSD в аппаратном RAID я пытался экспериментировать с отдельными SSD и вручную расположенными VHDX/AHDX - файлами сейчас собираю статистику для дисков, программно объединенных в один большой дисковый пул. повторюсь - ручной конфиг возможен. но это закат солнца вручную. оправдано, если виртуалка надолго. в условиях, когда машины постоянно меняются, ручной конфиг неэффективен. поэтому пока ищу тривиальные настройки внутри виртуалки, которые могут повлиять на производительность разработки (не продакшен). |
|
13.12.2017, 10:19 | #16 |
Участник
|
Ну я это написал под впечатлением от конфигурации у DSPIC :
Цитата:
4-канальная 65 GB RAM
Цитата:
Оптимизация класса Tax Виртуальный диск делал наш админ, какими-то сторонними дровами на 2008-й винде. а потом монтировал его в виде папки на диске. Также замечу что аксаптовский аос любит писать свои времянки и прочую инфу не в корень tmp папки, а создает там подпапку и пишет все в нее. Так что места под этот виртуальный диск надо не так много (это к вопросу про то, что памяти не хватает) А у вас какие результаты были ? Что именно сделали ? Последний раз редактировалось Logger; 13.12.2017 в 10:28. |
|
13.12.2017, 10:20 | #17 |
MCT
|
Цитата:
Ну это же админский хлеб с маслом )
__________________
Axapta book for developer |
|
13.12.2017, 10:25 | #18 |
Участник
|
Цитата:
Как это можно проверить : 1. (Вариант для неленивых) - сделать инсталляцию на обычном серваке (невиртуальном). попробовать там. или 2. Развернуть на той же виртуалке 2009-й аксапту. Посмотреть на ее скорость. Если все ок, то есть подозрения что корень тормозов в Ax7. |
|
13.12.2017, 10:29 | #19 |
Участник
|
)
Цитата:
теперь IIS. по идее должно работать по-другому. но я попробую еще раз с акс7 в следующей своей итерации переустновок. я пробовал и создавать виртуальный диск внутри виртуалки (когда ей было выделено 48Гб памяти) я пробовал и пробрасывать виртуальный диск, созданный на хосте, внутрь виртуалки и использовать его как временный внутри виртуалки. результаты тогда не оправдывали затраченных усилий. Добавил: надо отметить, что и те эксперименты и эксперименты сейчас выполняются не на настоящем сервере. тогда у меня был ноутбук с 64Гб памяти на борту (спасибо GMCS) сейчас у меня отдельная выделенная десктоп машина с 32Гб памяти на борту (спасибо МС) отлично понимаю, что в таких конфигурациях не будут раскрыты все возможности. но также надеюсь, что смогу нащупать пути, которые на одном и том же оборудовании дадут максимальный возможный выигрыш. Например, добавление исключений в антивирус реально работает. Как по органолептическим ощущениям, так и по счетчикам. ну, я ж не претендую на админский - пусть с продом он и разбирается. меня ж интересует только среда разработчика. ))) Последний раз редактировалось mazzy; 13.12.2017 в 10:34. |
|
13.12.2017, 13:20 | #20 |
Участник
|
NVDIMM решит проблему производительности.
|
|
Теги |
ax7, bios, d365, performance, виртуальная машина, производительность |
|
|