17.10.2023, 21:08 | #1 |
Участник
|
Да мой старый laptop в несколько раз мощнее, чем ваш production server
|
|
|
За это сообщение автора поблагодарили: gl00mie (5), fed (5), BOAL (3). |
18.10.2023, 16:06 | #2 |
Участник
|
Коллеги, а можете у себя сделать замер и поделиться ?
Я попробовал вот такой вариант на 3 разных серверах (все виртуальные) X++: create function dbo.isPrime (@n bigint) returns int as begin if @n = 1 return 0 if @n = 2 return 1 if @n = 3 return 1 if @n % 2 = 0 return 0 declare @sq int set @sq = sqrt(@n)+1 -- check odds up to sqrt declare @dv int = 1 while @dv < @sq begin set @dv=@dv+2 if @n % @dv = 0 return 0 end return 1 end GO declare @dt datetime set @dt=getdate() select dbo.isPrime(1000000000000037) select datediff(ms,@dt,getdate()) as ms GO Поспрашивал друзей. У одного от 7 до 14 секунд но в основном 8 У другого - 9 секунд. Как-то тоскливо стало. У кого еще медленно выполняется ? |
|
|
За это сообщение автора поблагодарили: sukhanchik (6). |
18.10.2023, 16:20 | #3 |
Участник
|
|
|
|
За это сообщение автора поблагодарили: Logger (3). |
18.10.2023, 16:51 | #4 |
Участник
|
10, 10, 11, 12, 17, 25
|
|
|
За это сообщение автора поблагодарили: Logger (3). |
18.10.2023, 17:12 | #5 |
Moderator
|
|
|
|
За это сообщение автора поблагодарили: Logger (3). |
18.10.2023, 19:42 | #6 |
Участник
|
|
|
18.10.2023, 20:24 | #7 |
Administrator
|
10 секунд на одном сервере (невиртуализирован).
5,5 секунд на другом сервере (невиртуализирован) Хм... есть над чем призадуматься... У знакомых на разработческом сервере 9,5 секунд (невиртуализирован). На проде - не знаю - коллега не имеет доступа к нему. Но продовский сервер тоже невиртуализирован
__________________
Возможно сделать все. Вопрос времени Последний раз редактировалось sukhanchik; 18.10.2023 в 20:52. |
|
|
За это сообщение автора поблагодарили: Logger (3). |
18.10.2023, 20:46 | #8 |
Участник
|
|
|
18.10.2023, 20:48 | #9 |
Administrator
|
SQL Server? Я конечно не админ всех серверов, но конкретно для AX - MS в явном виде не рекомендует виртуализировать БД SQL Server. Т.е. если АОСы еще могут быть виртуализированы - то БД должна лежать на "железном" сервере. Так что тут... старались не нарушать рекомендации MS
__________________
Возможно сделать все. Вопрос времени |
|
18.10.2023, 21:07 | #10 |
Участник
|
Цитата:
Правила для того и придуманы чтобы их нарушали У нас вот виртуализированы. |
|
19.10.2023, 04:13 | #11 |
Administrator
|
Цитата:
А вот когда размеры БД становятся уже настолько большими, что отсутствие индекса по какому-то полю начинает критически влиять на скорость поиска по этому полю - то тут уже крайне желательно уйти от виртуализации дисков и позволить SQL Server-у работать напрямую с дисками, а не через виртуализацию.
__________________
Возможно сделать все. Вопрос времени |
|
20.10.2023, 10:26 | #12 |
Участник
|
Нету. Причем тот, что показал 60+ это праймери сервер прода, т.е самый мощный SQL сервер из тех, что тестировал. и он как-то спокойно выдерживает нагрузку 20к-30к+ запросов в секунду (т.е нагрузка цп при этом может не подниматься выше 50%)
|
|
20.10.2023, 23:47 | #13 |
Участник
|
В моём случае на одинаковых, казалось бы, тестовых виртуальных серверах БД
На "железном" рабочем сервере
Последний раз редактировалось gl00mie; 20.10.2023 в 23:50. |
|
|
За это сообщение автора поблагодарили: Logger (3). |
21.10.2023, 14:01 | #14 |
Участник
|
Xeon(R) E5620 2.40 GHz в среднем 10,5 сек.
Xeon(R) Gold 6248 2.50 GHz в среднем 5,5 сек. Xeon(R) E7-4850 2.10 GHzв среднем 9,5 сек. Все - отдельная железяка. Запускал по 5 раз на каждом. |
|
|
За это сообщение автора поблагодарили: Logger (3). |
21.10.2023, 14:02 | #15 |
Участник
|
Что-то совпадают с sukhanchik.
А не на одних ли и тех же железках мы это проверяли? |
|
22.10.2023, 01:42 | #16 |
Administrator
|
Цитата:
Просто у меня есть полноценный доступ только к E7-4850 - который 9,5-10 секунд
__________________
Возможно сделать все. Вопрос времени |
|
13.12.2023, 19:54 | #17 |
Участник
|
1. Оказывается наши админы уже знали про эту статью и пробовали экспериментировать с настройкой. Выяснились жуткие вещи. В общем, ужос-ужос-ужос.
Похоже, что в соответствие с документацией Цитата:
«You can disable virtualization of the TSC by adding the setting monitor_control.virtual_rdtsc = FALSE to the virtual machine’s .vmx configuration file. This feature is no longer recommended for use. When you disable virtualization of the TSC, reading the TSC from within the virtual machine returns the physical machine’s TSC value, and writing the TSC from within the virtual machine has no effect. Migrating the virtual machine to another host, resuming it from suspended state, or reverting to a snapshot causes the TSC to jump discontinuously. Some guest operating systems fail to boot, or exhibit other timekeeping problems, when TSC virtualization is disabled. In the past, this feature has sometimes been recommended to improve performance of applications that read the TSC frequently, but performance of the virtual TSC has been improved substantially in current products. The feature has also been recommended for use when performing measurements that require a precise source of real time in the virtual machine. But for this purpose, the pseudoperformance counters discussed in the next section are a better choice.»
Цитата:
monitor_control.virtual_rdtsc = FALSE
На одном сервере стало криво выдаваться uptime - 69023 дней Потом оказалось, что служба SQL Agent падала без каких то внятных ошибок по логам серверов. Помогал только перезапуск сервера полностью. Потом оказалось, что время на серверах ведет себя не корректно. Следующие запуски заданий (SQL джобы) переносились далеко вперед. И завершилось это когда сервер «вылетел» из домена. Произошла рассинхронизация с временем в домене. Отключили дополнительную настройку для ВМ, вернули сервер в домен. И аптайм начал предоставлять актуальную информацию. 2. Быстрый сервер, оказался не таким уж и быстрым. Выяснилось, что для "быстрого" виртуального сервера спустя примерно 1 день, работа скрипта по расчету простых чисел замедлялась с 8 секунд до 28 секунд. После рестарта службы Sql все ускорялось, но лишь временно. На другой день снова медленно работало. Для медленного сервера после рестарта все ускорялось, но снова замедлялось до 40 секунд уже на 2-м - 3-м запуске скрипта. 3. Если на быстром сервере из SSMS запустить 4 скрипта одновременно, то в паре окошек он будет работать быстро с незначительным замедлением, а в другой паре окошек медленно. Хотя ядер было 20 штук. В общем, наблюдаются какие-то странные эффекты. Похоже есть узкое горлышко, мешающее полноценному параллелизму в работе скрипта. (случайности тут нет, делал много измерений) 4. Попробовал скомпировать C# пример из статьи. Позапускал его на разных серверах. Зависимость только от частоты CPU. пример (файл VmWareTest.cs) : X++: // [url]https://habr.com/ru/articles/496612/[/url] // [url=https://axforum.info/forums/showthread.php?p=439789#post439789]Да мой старый laptop в несколько раз мощнее, чем ваш production server[/url] // Эта программа демонстрировала еще более яркое замедление — // на «быстрых» машинах она показывает 16-18 миллионов циклов в секунду, // тогда как на медленных — полтора миллиона, а то и 700 тысяч. // То есть разница составляет 10-20 раз (!!!) // для компиляции Visual Studio ставить не надо. // просто запустить // C:\Windows\Microsoft.NET\Framework64\v4.0.30319>csc.exe VmWareTest.cs using System; using System.Runtime.InteropServices; using System.Diagnostics; class Program { [DllImport("kernel32.dll")] static extern void GetSystemTimePreciseAsFileTime(out FILE_TIME lpSystemTimeAsFileTime); [StructLayout(LayoutKind.Sequential)] struct FILE_TIME { public int ftTimeLow; public int ftTimeHigh; } static void Main(string[] args) { FILE_TIME fileTime; //+fix for (int i = 0; i < 16; i++) { int counter = 0; var stopwatch = Stopwatch.StartNew(); while (stopwatch.ElapsedMilliseconds < 1000) { GetSystemTimePreciseAsFileTime(out fileTime); //+fix // GetSystemTimePreciseAsFileTime(out var fileTime); //-fix counter++; } if (i > 0) { Console.WriteLine("{0}", counter); } } } } В общем, похоже, что выводы в статье были сделаны поспешно. Будьте осторожны. |
|
|
За это сообщение автора поблагодарили: Товарищ ♂uatr (4). |
Теги |
performance, sql server, vmware |
|
|