Да мой старый laptop в несколько раз мощнее, чем ваш production server

    Именно такие претензии я услышал от наших девелоперов. Самое интересное, что это оказалось правдой, дав начало длительному расследованию. Речь пойдет про SQL servers, которые крутятся у нас на VMware.



    Собственно, добиться того, чтобы production server безнадежно отстал от лаптопа легко. Выполните (не на tempdb и не на базе с включенной Delayed Durability) код:

    set nocount on
    create table _t (v varchar(100))
    declare @n int=300000
    while @n>0 begin 
      insert into _t select 'What a slowpoke!'
      delete from _t
      set @n=@n-1
      end
    GO
    drop table _t
    

    На моем десктопе он выполняется 5 секунд, а на production server — 28 секунд. Потому что SQL должен ожидать физического окончания записи в transaction log, а мы тут делаем очень короткие транзакции. Грубо говоря, мы загнали большой мощный грузовик в городской траффик, и наблюдаем, как его лихо обгоняют доставщики пиццы на скутерах — тут не важен throughput, важна лишь latency. А ни один network storage, сколько бы нулей ни было в его цене, не сможет выиграть по latency у локального SSD.

    (в комментах выяснилось что я соврал — у меня в обоих местах затесался delayed durability. Без delayed durability получается:
    Desktop — 39 секунд, 15K tr/sec, 0.065ms /io roundtrip
    PROD — 360 секунд, 1600 tr/sec, 0.6ms
    Я должен был обратить внимание, что уж слишком быстро)


    Однако в данном случае мы имеем дело с тривиальными нулями зэта функции Римана с тривиальным примером. В том примере, который мне принесли девелоперы, было другое. Я убедился, что они правы, и стал вычищать из примера всю их специфику, связанную с бизнес логикой. В какой-то момент я понял, что могу полностью выбросить их код, и написать свой — который демонстрирует ту же проблему — на production он выполняется в 3-4 раза медленнее:

    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

    Если у вас все хорошо, то проверка простоты числа будет выполняться 6-7-8 секунд. Так и было на ряде серверов. Но вот на некоторых проверка занимала 25-40 секунд. Что интересно, не было серверов, где выполнение занимало бы, скажем, 14 секунд — код работал либо очень быстро, либо совсем медленно, то есть проблема была, скажем так, черно белой.

    Что я сделал? Полез в метрики VMware. Там было все хорошо — реcурсов было в избытке, Ready time = 0, всего хватает, во время теста и на быстрых, и на медленных серверах CPU=100 на одном vCPU. Я взял тест по расчету числа Pi — тест показывал одинаковые результаты на любых серверах. Все сильнее пахло черной магией.

    Выбравшись на DEV ферму, я стал играться серверами. Выяснилось, что vMotion с хоста на хост может «вылечить» сервер, но может и наоборот, «быстрый» сервер превратить в «медленный». Кажется вот оно — какие то хосты имеют проблему… но… нет. Какая-то виртуалка тормозила на хосте, допустим, A но работала быстро на хосте B. А другая виртуалка наоборот, работала быстро на A и тормозила на B! На хосте часто крутились и «быстрые» и «медленные» машинки!

    С этого момента в воздухе отчетливо запахло серой. Ведь проблема не могла быть приписана ни виртуалке (windows patches, например) — ведь она превращалась в «быструю» при vMotion. Но проблема также не могла быть приписана хосту — ведь на нем могли быть как «быстрые», так и «медленные» машинки. Также это не было связано с нагрузкой — мне удалось получить «медленную» машинку на хосте, где кроме нее вообще не было ничего.

    От отчаяния я запустил Process Explorer от Sysinternals и посмотрел стек SQL. На медленных машинках мне сразу бросилась в глаза строка:

    ntoskrnl.exe!KeSynchronizeExecution+0x5bf6
    ntoskrnl.exe!KeWaitForMultipleObjects+0x109d
    ntoskrnl.exe!KeWaitForMultipleObjects+0xb3f
    ntoskrnl.exe!KeWaitForSingleObject+0x377
    ntoskrnl.exe!KeQuerySystemTimePrecise+0x881 < — !!!
    ntoskrnl.exe!ObDereferenceObjectDeferDelete+0x28a
    ntoskrnl.exe!KeSynchronizeExecution+0x2de2
    sqllang.dll!CDiagThreadSafe::PxlvlReplace+0x1a20
    … skipped
    sqldk.dll!SystemThread::MakeMiniSOSThread+0xa54
    KERNEL32.DLL!BaseThreadInitThunk+0x14
    ntdll.dll!RtlUserThreadStart+0x21


    Это было уже что-то. Была написана программа:

        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)
            {
                for (int i = 0; i < 16; i++)
                {
                    int counter = 0;
    
                    var stopwatch = Stopwatch.StartNew();
    
                    while (stopwatch.ElapsedMilliseconds < 1000)
                    {
                        GetSystemTimePreciseAsFileTime(out var fileTime);
                        counter++;
                    }
    
                    if (i > 0)
                    {
                        Console.WriteLine("{0}", counter);
                    }
                }
            }
        }

    Эта программа демонстрировала еще более яркое замедление — на «быстрых» машинах она показывает 16-18 миллионов циклов в секунду, тогда как на медленных — полтора миллиона, а то и 700 тысяч. То есть разница составляет 10-20 раз (!!!). Это было уже маленькой победой: во всяком случае, не было угрозы застрять между Microsoft и VMware support так, чтобы они переводили стрелки друг на друга.

    Далее прогресс остановился — отпуск, важные дела, вирусная истерия и резкое возрастание нагрузки. Я часто упоминал магическую проблему коллегам, но временами казалось, что они даже не всегда мне верят — слишком уж чудовищным было заявление от том, что VMware замедляет код в 10-20 раз.

    Я пытался сам раскопать, что же тормозит. Временами мне казалось, что я нашел решение — включение и выключение Hot plugs, изменение объема памяти или числа процессоров часто превращало машинку в «быструю». Но не навсегда. А вот что оказалось правдой — так это то, что достаточно выйти и постучать по колесу — то есть изменить любой параметр виртуалки

    Наконец, мои американские коллеги вдруг нашли root cause.



    Хосты отличались частотой!
    • Как правило, это не страшно. Но: при переезде с 'родного' хоста на хост с 'другой' частотой VMware должна корректировать результат GetTimePrecise.
    • Как правило это не страшно, если только не оказывается аппликации, которая запрашивает точное время миллионы раз в секунду, как SQL server.
    • Но и это не страшно, так как SQL server делает это далеко не всегда (см. Заключение)

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

    Решение


    www.vmware.com/files/pdf/techpaper/Timekeeping-In-VirtualMachines.pdf

    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.

    Короче говоря, надо добавить параметр

    monitor_control.virtual_rdtsc = FALSE

    Заключение


    У вас наверняка возник вопрос: а нафига SQL вызывать GetTimePrecise так часто?

    У меня нет исходников SQL server, но логика говорит вот что. SQL это почти операционка с cooperative concurrency, где каждый thread должен время от времени «уступать». А где это лучше сделать? Там, где есть естественное ожидание — lock или IO. Хорошо, а что, если мы крутим вычислительные циклы? Тогда очевидное и почти единственное место — в интерпертаторе (это не совсем интерпретатор), после выполнения очередного оператора.

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

    Кстати, если функцию обернуть в NATIVELY COMPILED, то она перестает запрашивать время, и ее скорость увеличивается раз в 10. А как же cooperative multitasking? А вот для natively compiled code и пришлось в SQL сделать PREEMPTIVE MULTITASKING.
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 73

      +3
      Может использовать в серверах одинаковые CPU? Если не ошибаюсь VMware рекомендует что бы при организации кластера на серверах были одинаковые CPU, да и все остальное лучше одинаковое иметь.
        +10

        В идеальном мире да
        Но у нас постепенно апгрейдили хосты, добавляли новые, списывали старые

          0
          C VMWare не знаком, но в Hyper-V для кластера нужны процы одного производителя — либо только Интелы, либо только АМД. Это не рекомендация, а требование
            0
            Так у нас везде Intel
            Но частота разная
            А как Hyper-V относится к машинам с разной частотой?
              0
              Но рекомендация — использовать одинаковые есть и в Hyper-V. Даже близкие разные поколения (26xx v2 и 26xx v1) уже требуют дополнительный флаг совместимости CPU в свойствах VM, что на некоторый процент понижает производительность.
                0

                понижает производительность или не даёт виртуальной машине использовать некоторые инструкции SIMD и т.п.?

                  +1
                  Не даёт использовать часть аппаратно-ускоряемых функций, что приводит к использованию программной реализации их. Например — AES.
                  https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn859550(v%3Dws.11)
                    0

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

                      0
                      Если не нужны SSE4/AVX/AVX2/AES, то пофиг. Если нужны — печаль. Что-то не запустится (если инструкции необходимы, а программной реализации при их отсутствии нет), что-то станет медленнее.
                      Скриншот для e3-1225 v3 при включенном и выключенном режимах
                      image
              +1
              А этого требования точно достаточно для решения проблемы? Не получится ли так, что одинаковые ЦП в разных условиях будут бустить по разному?
                0

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

              +17
              Люблю такие детективы.
                0
                Грубо говоря, мы загнали большой мощный грузовик в городской траффик, и наблюдаем, как его лихо обгоняют доставщики пиццы на скутерах — тут не важен throughput, важна лишь latency. А ни один network storage, сколько бы нулей ни было в его цене, не сможет выиграть по latency у локального SSD

                так-то у нас локальные nvme используются, но ЕМНИП от СХД тоже можно получить задержки менее 1мс. если, конечно, речь не про iSCSI и не про СХД в соседнем городе.

                  +1
                  Да, но в самом первом примере (insert 'What a slowpoke!') делается 600K транзакций за 5 сек у меня на декстопе с локальным SSD, то есть 120K транзакций в секунду… То есть меньше 10 микросекунд на disk roundtrip…
                    +1
                    Опаньки, я соврал… У меня там столяло delayed durability, рукалицо.

                    Desktop — 39 секунд, 15K tr/sec, 0.065ms /io roundtrip
                    PROD — 360 секунд, 1600 tr/sec, 0.6ms

                    Я должен был обратить внимание, что уж слишком быстро
                      0

                      всё равно быстро. обычно десктопные накопители выдают сотни iops на синхронной записи.
                      а что за ssd? может быть он просто их тех, что молча игнорируют fsync? )

                        0
                        Вот этот стоит:
                        ssd.userbenchmark.com/SpeedTest/495225/KINGSTON-SA1000M8960G
                        KINGSTON A1000 NVMe PCIe M.2 960GB
                        Как проферить вашу гипотезу?
                          0

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


                          fio  -sync=1 -name=test -bs=4k -iodepth=1 -rw=randwrite -runtime=60 -filename=bla-bla-bla

                          ну и без sync=1 и сравнить результат. ещё может быть стоит write вместо randwrite, запись в лог же линейная.

                        0
                        PROD — 360 секунд, 1600 tr/sec, 0.6ms

                        а почему так медленно?
                        мне кажется, что с вашей СХД что-то не в порядке.

                          0
                          NetApp AFF220 (то есть full flash),FC-8 = 254 секунды.
                            0

                            получается примерно 40мкс на операцию ввода-вывода, как-то грустно.
                            я думал, что СХД с FC (и агрессивным кэшированием) гораздо быстрее.

                              0
                              Как я понимаю все это в основном network roundtrip.
                              Сам storage отдает «готово» мгновенно (write-behind, с гарантией с помощью небольшого аккумулятора)
                                0

                                вот и странно, я получал RTT меньше 20мкс по обычному ethernet, FC должен быть быстрее.

                                  0
                                  Это напрямую?
                                  Думаю в нашем случае есть еще хопы
                                  Ведь любой из многих хостов может работать с любым из многих стораджей…
                                    0

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


                                    тут больше вклад обработки сетевых драйверов, обработки прерываний, стека tcp/ip и всего такого. шина pci-e небезгрешна, кстати, похоже (почему pci-e optane имеет latency порядка 10мкс? те же микросхемы в виде модулей памяти горадо быстрее).


                                    так вот, в случае подключения к схд по fc мы отказываемся от tcp/ip, драйверы (да и сами адаптеры) должны быть оптимизованы под низкие задержки — поэтому я ожидал результатов получше.

                      +17

                      Браво, хорошее, я бы даже сказал крутое расследование! Таким и должен быть айтишник.

                        –5
                        Таких случаев море, докапаится до сути это почти как крутую теорему решить, но решение чаще всего только костыыл
                          +8
                          По типу проблемы напомнило классический 500 мильный email — web.mit.edu/jemorris/humor/500-miles
                            0
                            Была написана программа
                            А можно бинарник?
                              0
                              С работы EXE не утащить, только copy/paste.
                              А студии дома нет, можете через консоль скомпилировать)
                                0
                                Так у меня тоже нет, не могу скомпилировать.
                                  0

                                  Компилятор дот нет (консольный) есть ВСЕГДА. Загуглите как скомпилить. Я просто с телефона сейчас

                                    0
                                    C:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe Program.cs (это же С#?):
                                    Program.cs(4,10): error CS0246: Не удалось найти имя типа или пространства имен «DllImport» (пропущена директива using или ссылка на сборку?)
                                    Program.cs(7,10): error CS0246: Не удалось найти имя типа или пространства имен «StructLayout» (пропущена директива using или ссылка на сборку?)

                                    Если добавить первой строчкой «using System.Runtime.InteropServices;», то на выходе:
                                    Program.cs(24,60): error CS1026: ожидалась )
                                    Program.cs(24,68): error CS1002: ожидалась;
                                    Program.cs(24,68): error CS1525: Недопустимый терм ")" в выражении
                                      +1
                                      FILE_TIME fileTime;
                                      GetSystemTimePreciseAsFileTime(out fileTime);
                                        +2
                                        out var это 4.8 дотнет.
                                          0
                                          Ok, заменил «GetSystemTimePreciseAsFileTime(out var fileTime);» на то, что вы предложили, в начало добавил
                                          using System;
                                          using System.Runtime.InteropServices;
                                          using System.Diagnostics;

                                          Заменил .Net на 4.8:
                                          C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe Program.cs
                                          Файл скомпилилровался и даже работает, начиная с Server 2012, спасибо.
                                  0
                                  Можно в base64 конвертировать и копипастить куда хочется.
                                0

                                Moral of the story: писать "if-then-else"-style на SQL — зло. Ибо заколачивание гвоздей микроскопом.

                                  0
                                  Да. Но (в статье я это не писал) при использовании CLR, если CLR делает короткие обращения к базе, то это подвержено подобным же тормозам. Так что бизнес лочику лучше все таки выносить в отдельный слой…
                                    0
                                    Так написано же:
                                    У вас наверняка возник вопрос: а нафига SQL вызывать GetTimePrecise так часто? [...] А где это лучше сделать? [...] очевидное и почти единственное место — в интерпертаторе (это не совсем интерпретатор), после выполнения очередного оператора.
                                  +10
                                  наконец-то хорошая статья
                                    –9
                                    Мда?
                                    Сферическому коню в вакууме пнуть по * и все заработало
                                    Не версия vmware, не патчи что что стоят, не hw версия виртуалки, не версии tools
                                    а к тому что волшебный параметр гугл вспоминает за 2010 год… вы думаете что это не разу не поправили?
                                    –2

                                    Чисто формально, ближайший PCI-Express свитч с соответствующими nvme утрёт нос десктопу (но не vmware, которая слоупок своего рода).

                                      +4
                                      Когда-то специально для виртуалок в MS SQL предлагали специально включать trace flag -T8038
                                      techcommunity.microsoft.com/t5/sql-server-support/how-it-works-sql-server-timings-and-timer-output-gettickcount/ba-p/315782
                                      randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted
                                        0
                                        Спасибо, обязательно проэкспериментирую и отпишусь
                                          +2
                                          На «медленном» сервере это ускорило c 31.5s до 30.0
                                          То есть почти без разницы…
                                          +1

                                          нетривиальных нулей дзета-функции

                                            0
                                            браво, вот это интересное расследование
                                              +5

                                              Напомнило историю с Windows 95 который как мне казалось в детстве быстрее работал если шевелить мышкой, а потом оказалось что не казалось, а так и было )


                                              Спасибо за статью!

                                                0

                                                "Оказалось, что не казалось" ©


                                                А что там за история (я не про "казалось", а про технические детали), ссылочка есть?

                                                +2
                                                А оно и сейчас так. Например, частота обновления страницы при отрисовки в Хроме зависит от скорости движения мышкой (ну, вернее, от самого факта наличия движения).
                                                  +1

                                                  И не только в Хроме. Windows динамически повышает базовый приоритет процессов который получают активный input. Пруф: https://docs.microsoft.com/en-us/windows/win32/procthread/priority-boosts


                                                  В «обычной» обстановке вы это вряд ли заметите, но вот если в результате такой динамической приоретизации какие-то потоки станут time critical (приоритет 31), тогда вы уже можете (теоретически) увидеть разницу на глаз. Потому что time critical это не просто «высокий» приоритет, это наивысший приоритет — потокам time critical отдаётся всё процессорное время, которое есть; отправляя остальные потоки отдыхать «за свой счёт».


                                                  Посмотрите на ютубе доклады CLRium если хочется больше подробностей, там хотя и про .NET, но многое справедливо для Windows в целом.

                                                    +1

                                                    Ах да, это десктопная штука, которую придумали чтоб пользователи могли ускорять инсталляторы рисуя на экране бесконечные восьмерки :)


                                                    На серверах эта магия обычно выключена. Помните настройку «отдавать приоритет фоновым процессам»? — она вот как раз про это (кроме всего прочего)

                                                      +1
                                                      но вот если в результате такой динамической приоретизации какие-то потоки станут time critical

                                                      Не станут, Windows управляет приоритетами потоков только в диапазоне 1-15. Все важные системные потоки имеют фиксированные приоритеты от 16 до 31, и никак не могут быть вытесненными пользовательскими потоками.
                                                        +3
                                                          0
                                                          Хорошая статья, хотел бы видеть её на Хабре.
                                                          Не знал о рангах. Видимо, в десятке внедрили механизм поверх приоритетов, для мобильных устройств.
                                                  0

                                                  у меня есть два совершенно одинаковых сервера, на одном стоит vmware, на другом нет виртуализации.


                                                  версии windows, ms sql одинаковые.
                                                  так вот, второй скрипт (арифметика) выполняется примерно одинаково (потери на виртуализацию менее 10%), первый же скрипт (много мелких транзакций) на "железной" машине выполняется за 26-27с, на виртуальной лучшее время 80с, среднее по 6 запускам — 91с.


                                                  WTF?

                                                    0
                                                    а какой у вас диск на железной машине?
                                                      0
                                                      а если использовать in-memory таблицы, то баг пропадет или все еще будет?
                                                        0
                                                        Если использовать natively compiled, тогда пропадет
                                                        Из обычных работа с in memory не ускорится
                                                        0

                                                        intel p4500

                                                      –3
                                                      Хо-хо, неплохо.
                                                      Спасибо за статью.
                                                        –4
                                                        Мощнее? Зимой сможет обогреть квартиру?
                                                          0
                                                          на «быстрых» машинах — 16-18 миллионов циклов в секунду.
                                                          на медленных — полтора миллиона, а то и 700 тысяч.
                                                          На моем i5-3570:
                                                          Релиз-программа x32 bit с выключенным в BIOS HPET выдает 7.6 миллионов циклов в секунду.
                                                          Дебаг-версия x32 bit с выключенным HPET выдает 3.2 м/сек.
                                                          У меня 32 бита не зависит от вкл/выкл HPET.

                                                          Релиз x64 bit с включенным HPET выдает 17 м/сек.
                                                          Релиз x64 bit с выключенным HPET выдает 15.5 м/сек.
                                                            0
                                                            7.6 немного медленновато
                                                            Интересно, неужели 32/64 bit transition так замедляет?
                                                              0
                                                              ИМХО HPET не всегда самый «крутой» event timer.
                                                              # sysctl kern.eventtimer
                                                              kern.eventtimer.periodic: 0
                                                              kern.eventtimer.timer: LAPIC
                                                              kern.eventtimer.idletick: 0
                                                              kern.eventtimer.singlemul: 2
                                                              kern.eventtimer.choice: LAPIC(600) HPET(550) HPET1(440) HPET2(440) HPET3(440) HPET4(440) HPET5(440) HPET6(440) i8254(100) RTC(0)
                                                              kern.eventtimer.et.i8254.quality: 100
                                                              kern.eventtimer.et.i8254.frequency: 1193182
                                                              kern.eventtimer.et.i8254.flags: 1
                                                              kern.eventtimer.et.RTC.quality: 0
                                                              kern.eventtimer.et.RTC.frequency: 32768
                                                              kern.eventtimer.et.RTC.flags: 17
                                                              kern.eventtimer.et.HPET6.quality: 440
                                                              kern.eventtimer.et.HPET6.frequency: 14318180
                                                              kern.eventtimer.et.HPET6.flags: 3
                                                              kern.eventtimer.et.HPET5.quality: 440
                                                              kern.eventtimer.et.HPET5.frequency: 14318180
                                                              kern.eventtimer.et.HPET5.flags: 3
                                                              kern.eventtimer.et.HPET4.quality: 440
                                                              kern.eventtimer.et.HPET4.frequency: 14318180
                                                              kern.eventtimer.et.HPET4.flags: 3
                                                              kern.eventtimer.et.HPET3.quality: 440
                                                              kern.eventtimer.et.HPET3.frequency: 14318180
                                                              kern.eventtimer.et.HPET3.flags: 3
                                                              kern.eventtimer.et.HPET2.quality: 440
                                                              kern.eventtimer.et.HPET2.frequency: 14318180
                                                              kern.eventtimer.et.HPET2.flags: 3
                                                              kern.eventtimer.et.HPET1.quality: 440
                                                              kern.eventtimer.et.HPET1.frequency: 14318180
                                                              kern.eventtimer.et.HPET1.flags: 3
                                                              kern.eventtimer.et.HPET.quality: 550
                                                              kern.eventtimer.et.HPET.frequency: 14318180
                                                              kern.eventtimer.et.HPET.flags: 7
                                                              kern.eventtimer.et.LAPIC.quality: 600
                                                              kern.eventtimer.et.LAPIC.frequency: 2893493164
                                                              kern.eventtimer.et.LAPIC.flags: 7
                                                              –1
                                                              del
                                                                0
                                                                Оптимизировать инфраструктуру нужно по всему стэку (железо, сеть, os, гипервизор, vm os, sql и т.п.)
                                                                Рекомендую автору начать со следующих ресурсов:
                                                                blogdonicolett.com.br/2015/03/01/melhor-configuracao-de-qlikview-para-vmware
                                                                www.microsoft.com/en-us/download/details.aspx?id=51960
                                                                www.gilev.ru/virtual
                                                                Также не забываем про NUMA, EVC, Ballooning и о многих других вещах, которые могут сильно влиять на производительность в виртуальных (и не только) средах
                                                                После оптимизации замерить вашей программой, и понять что как влияет
                                                                  0
                                                                  Как вы думаете, с чего мы начали?) Имеено когда стало ясно, что все очевидные вещи ни при чем, мы и стали копать глубже.
                                                                    0
                                                                    Судя по описанию, когда вы (спецы из VMWARE) внезапно обнаружили разные CPU на хостах, глубокого перед этой статьёй копания небыло…
                                                                  –1
                                                                  dup

                                                                  Only users with full accounts can post comments. Log in, please.