[Logger]

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) :

// [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);
			}
		}
	}
}

Вывод
В общем, похоже, что выводы в статье были сделаны поспешно.
Будьте осторожны.