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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

Как я понимаю все это в основном network roundtrip.
Сам storage отдает «готово» мгновенно (write-behind, с гарантией с помощью небольшого аккумулятора)
Это напрямую?
Думаю в нашем случае есть еще хопы
Ведь любой из многих хостов может работать с любым из многих стораджей…

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


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


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

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

Таких случаев море, докапаится до сути это почти как крутую теорему решить, но решение чаще всего только костыыл
С работы EXE не утащить, только copy/paste.
А студии дома нет, можете через консоль скомпилировать)

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

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: Недопустимый терм ")" в выражении
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, спасибо.

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

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

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

На «медленном» сервере это ускорило c 31.5s до 30.0
То есть почти без разницы…

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


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

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


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

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

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


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


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

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


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

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

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

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


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


WTF?

а если использовать in-memory таблицы, то баг пропадет или все еще будет?
Если использовать natively compiled, тогда пропадет
Из обычных работа с in memory не ускорится
на «быстрых» машинах — 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 м/сек.
7.6 немного медленновато
Интересно, неужели 32/64 bit transition так замедляет?
ИМХО 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
Оптимизировать инфраструктуру нужно по всему стэку (железо, сеть, 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 и о многих других вещах, которые могут сильно влиять на производительность в виртуальных (и не только) средах
После оптимизации замерить вашей программой, и понять что как влияет
Как вы думаете, с чего мы начали?) Имеено когда стало ясно, что все очевидные вещи ни при чем, мы и стали копать глубже.
Судя по описанию, когда вы (спецы из VMWARE) внезапно обнаружили разные CPU на хостах, глубокого перед этой статьёй копания небыло…
Only those users with full accounts are able to leave comments. Log in, please.