Выбор процессора для 1С: конец споров или начало?

Компьютеры, принтеры, процессоры... (с)

ВВЕДЕНИЕ

Я давно уже занимаюсь проблемами производительности программного обеспечения и железа, поэтому решил поделиться с сообществом своим взглядом на данные проблемы как в части железа и настройки ОС (на примере запроса к данным, выгруженным из теста Гилева), так и в части подхода к архитектуре организации хранения данных (#тыжархитектор!)

Сначала я расскажу, какие данные я выгрузил из табличной части обработки тестирования производительности теста Гилева, как я это сделал, куда вставил и каким запросом получил результат для анализа. Далее мы пройдемся по списку процессоров и попробуем понять, от чего зависит производительность, а дальше я уже коснусь принципов организации данных для повышения производительности в тех или иных кейсах.

СБОР ДАННЫХ

Для сбора данных я использовал последнюю версию теста Гилева, в которой произвел тест своего компьютера - скромного ноутбука от HP с процессором Intel 8250U, 16 Гиб ОЗУ (2х8х2400 МГц) и SSD от SmartBuy - какой-то самый дешманский винт на полгига, который, кстати, работает быстрее основного винта от самсунга (SSD овер M2, 128 Гиг). Также в системе установлен Linux Mint с ядром 5.3.0.53 из стандартного репозитория, ядро это запускается без каких бы то ни было опций.

После теста файловой базы на экране отобразилось количество попугаев (80.65) и список произведенных тестов за всю тестовую историю (наверное).

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

В постгресе я создал табличку (без всяких там индексов) с полями: period, user, value, arch и proc, после чего попытался загрузить туда данные. Загрузка выдала ошибку в формате даты. После кучи попыток привести дату к вменяемому состоянию я натыкался на ошибку часового пояса, в качестве которого система пыталась интерпретировать поле с именем пользователя. В итоге трабла оказалась в разделителе, и поменяв ТАБ на "|" загрузка прошла. Вот команда, которой я преобразовал выгруженный файл в тот, который смог скушать постгрес:

sed -e 's/|/\_/g' \
-e 's/^\([0-9]\{2\}\)\.\([0-9]\+\)\.\([0-9]\+\)\s*[0-9:]\+\t/\3-\2-\1|/g' \
-e 's/\t/\|/g' \
-e 's/\([0-9]\+\)\,\([0-9]\+\)/\1\.\2/g' \
-e 's/||\B/|/g' \
-e '/||/d' \
gilev.txt > gilev1.txt

Здесь символ "\" означает перенос строки - в консоли Linux так делать можно и нужно.

Сначала я меняю все палки на подчеркивания, чтобы в последствии эти палки не были интерпретированы постгресом, как разделители. Дальше я меняю дату из формата ДД-ММ-ГГГГ ЧЧ:ММ:СС на ГГГГ-ММ-ДД, дальше меняю все ТАБ на "|", потом меняю запятые в дробном результате выгрузки на точки, потом меняю двойной разделитель в конце строки на одинарный (в случае, когда имя процессора отсутствует - это, обычно, клиент для Linux, в котором тест Гилева не может определить имя процессора - это можно сделать чтением /proc/cpuinfo - там есть и ядра, и частота, и вся прочая дичь). Дальше удаляю все строки, в которых идут два разделителя подряд - случаи, в которых значение теста равно нулю.

В итоге получаю файл с количеством строк, равным 227 493 (первая строка - заголовок):

$ head gilev1.txt -n 5
Период|Пользователь имя|Значение|Архитектура|Процессор наименование
2020-05-22|starik2005@bk.ru|80.65|Файловая|
2020-05-22|ssa2|28.25|SQL|Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
2020-05-22|SKUL-02@Eugenbot|24.39|SQL|Intel(R) Xeon(R) CPU E31275 @ 3.40GHz
2020-05-22|efsol@efsol.ru|13.23|SQL|Intel(R) Xeon(R) Gold 6242 CPU @ 2.80GHz

$ tail gilev1.txt -n 3
2014-04-10|sergey@savel.pro|7.58|SQL|Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
2014-04-10|sergey@savel.pro|7.53|SQL|Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
2014-04-10|sergey@savel.pro|7.59|SQL|Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz

$wc gilev1.txt -ml
  227493 16511743 gilev1.txt

Таким образом у нас здесь данные тестов с 4 октября 2014-го по 22 мая 2020-го, последний тест - мой (заметьте, нет названия процессора для Linux).

АНАЛИЗ

Для анализа данных я загрузил этот файл в постгрес - просто жамкнул правой кнопкой мышки в PgAdmin III на имени таблицы, выбрал "Импорт", выбрал файл, указал CSV, заголовок, кодировку и разделитель. Через секунду данные были загружены.

Дальше я написал вот такой вот запросик:

with
    t
    AS
    (
        select arch, case when proc is null then '-' else proc end as proc , max(value) as value
        from gilevtest
        group by arch,proc
    )
select t1.arch, t1.proc, max(t1.value), min(t1.value), avg(t1.value), sum(1)
from gilevtest as t1
    join t as t
    on t.proc = case when t1.proc is null then '-' else t1.proc end and t.arch = t1.arch
where t1.value > t.value / 2 and t1.value < 150
--and t1.proc like '%Xeon%'
group by t1.arch,t1.proc
having sum(1) > 100
order by t1.arch, avg(t1.value) desc, t1.proc 

Время выполнения этого запроса безо всяких индексов с первого раза всего ОДНА секунда.

Здесь я использовал общее табличное выражение - директива WITH, в котором я для каждого процессора получил среднее значение, чтобы потом убрать очень низкие результаты теста, которые были по всей видимости произведены в каких-то особенно плохих условиях. Фактически я здесь отрезаю все результаты, которые ниже половины среднего значения для этого процессора и выше 150. Ну и результат группирую по архитектуре и процессору, сортируя по убыванию среднего значения. Думаю, что можно было бы для этого использовать оконную функцию OVER, но до конца не понял, как ее тут применить )))

Кстати, там есть закомментированная строка с отбором по только по серверным процессорам Xeon - этим мы займемся между делом, попытавшись ответить на вопрос, какой же процессор имеет смысл тащить с китайских барахолок и сколько он стоит )))

Также я убрал процессоры, для которых было набрано меньше СОТНИ результатов тестирвоания.

РЕЗУЛЬТАТЫ

Я разделил в запросе результаты по архитектуре, так что посмотрим сначала на файловую базу.

Файловая база

> 80

Итак, для начала давайте посмотрим, какие процессоры в среднем дают больше 80 попугаев. В табличке ниже следующие колонки:

В итоге лидером у нас становится I9-9900K, что ожидаемо. Более быстрые процессоры от AMD просто не прошли ценз количества, т.к. AMD Ryzen 3900X показывает лучший результат, но его тестировали МЕНЕЕ ДЕСЯТИ раз.

На втором месте у нас безымянный процессор - это все процессоры, протестированные на платформе Linux в фвйловой базе - 303 результата. Где-то там есть и наш рабочий AMD Ryzen 3600, который в файловом тесте на платформе Linux набрал 125 попугаев, при том на винде эта цифра была в районе 80-ти, что как бы намекает...

Дальше идут разнообразные I7, замыкает топ лидеров I5-9600K. Думаю, что для бюджетных серверов этот процессор является самым предпочтительным по цене за попугай (если не считать Райзен 3600 с вдвое большим количеством потоков за немного меньшие деньги, или даже райзен 3500X, в котором потоков столько же, но в 4 раза больше кеша и цена ниже 10к, но т.к. тестов райзена очень мало, то считайте это моей субъективной оценкой).

70-80

Итак, в списке процессоров со средним баллом в файловой между 70 и 80 у нас ожидаемо все те же процессоры от Intel, но без суффикса "К", т.е. с заблокированным множителем и их типа нельзя гнать. Это говорит о том, что в общем и целом я использую правильную методику тестирования и данные очень коррелируют с маркетинговыми выкладками от Intel, позиционирующую процессоры со свободным множителем, как более быстрые (но, правда, и более дорогие). Да, они действительно более быстрые - тест Гилева это доказал.

Здесь у нас появляется "самый крутой" XEON - E2288G, который смог добраться до 74,68 попугаев. В принципе это аналог I9-9900K по ядрам/потокам/частоте, да и рассчитан на всего ОДИН сокет, имеет 2-х канальную память и стоимость в районе 50к. Смысла в его приобретении не вижу никакого.

Ну и "Common KVM processor" тут тоже засветился, что говорит о том, что для виртуальных сред не все потеряно.

60-70

Вот тут уже интересно - появляются базарные Xeon'ы, которые в принципе имеет смысл тащить с Китая, но их цены будут далеко не три копейки - ройте алик. Среди них выделяется E5-2667 v3, который в максимуме преодолевает планку в сотню попугаев, при том его цена на алике в районе 200 долларов, на e-bay - в районе 7к рублей, а в местной рознице - 140к, что как бы намекает бессмысленность его покупки у местных барыг )))

Также тут появился первый процессор от AMD, который в пределе набирает здесь 84,75 попугаев. Но это винда, а на Linux даже мой Ryzen 1600 набирает в пределе 89 попугаев, при этом ZEN+ должен набирать где-то под СТО (т.к. Ryzen 3600 на ZEN2 набирает 125).

Продолжать рассказ про файловую я не буду, т.к. процессор, который показал средний балл ниже 60-ти попугаев, в принципе недостоин быть в качестве камня для работы с 1С.

ИТОГИ ТЕСТА ФАЙЛОВОЙ

Итак, по итогам теста объективно самое лучшее решение для малобюджетного компьютера для 1С (например, компьютер разработчика с множеством файловых баз) - это компьютер на базе i5-9600K за 15 тысяч рублей (стоимость процессора). Субъективно же в качестве самого бюджетного лидера лично я бы взял AMD Ryzen 3600 или 3500X, кои в тесте отсутствуют из-за очень небольшого количества проведенных на них тестов, а эти тесты не могут показать объективную картину.

SQL - КЛИЕНТ-СЕРВЕРНЫЙ ВАРИАНТ

Я здесь не разделял PostgreSQL и MS SQL, т.к. для однопоточного теста Гилева разница средних значений для них несущественна.

> 40

Итак, тесты процессоров, у которых больше СОРОКА попугаев, тоже вполне ожидаемы. На первом месте опять I9-9900K, на втором все процессоры, которые тестировались на платформе Linux, соответственно независимо от процессора это был PostgreSQL - таких тестов 838. Это снова говорит о том, что даже несмотря на процессор, скульный тест под Lniux уступил только ТОПчику. Я бы тут сделал еще один возможно неправильный вывод, что Linux и Postgres - это ТОПчик. Предположу, что вклад сюда могли внести и вычеркнутые из тестов на винде процессоры AMD - там они не вычеркнуты, т.к. сами процессоры нет возможности определить, ибо тест Гилева не собирает данные о процессорах при работе под Linux'ом.

Также здесь у нас снова появляется I5-9600К - он здесь на ЧЕТВЕРТОМ месте. Поэтому я, лично, объективно признаю этот процессор самым эффективным по отношению цена/производительность. Т.к. рекомендуется, чтобы количество пользователей на ядро не превышало 10, то этот процессор смог бы дать работать 50-ти пользователям без особых напрягов.

30-40

Здесь уже процессоров куда больше. Радует появление в списке уже отметившегося в файловой базе E5-2667 v3 со средним значением в 38 попугаев, что делает его отличным вариантом для корпоративного использования, т.к. в нем 4 канала памяти и поддержка двух сокетов, что в пределе дает 16 ядер и 32 потока, которых должно хватить на обслуживание 200-300 пользователей с максимально возможной производительностью.

Смысла рассматривать процессоры, которые дали в среднем меньше 30 баллов, на мой взгляд нет.

ИТОГИ ТЕСТА SQL

Клиент-серверная база работает совсем не так, как файловая. В ней ПО, отвечающее за хранение данных, отделено от кода сервера приложений, поэтому скорость работы одного пользователя с такой базой будет в ДВА раза МЕНЬШЕ, т.к. 1С берет данные не из своего файлового хранилища, а запрашивает из внешней СУБД. Но если пользователей очень много, то клиент-серверный вариант обеспечивает производительность параллельной работы. И если в файловой базе без использования таких фич, как публикация на веб-сервере, скорость работы даже 10-ти пользователей может упереться в скорость обмена данными по сети, а если все это происходит на одном компьютере (например, когда все подключаются через удаленный рабочий стол), то все будет упираться в исключительные блокировки таблиц при записи данных, которые будут вынуждать остальных пользователей ждать, при этом перед любой транзакцией файловая база будет искать файлы блокировок и разбираться, какие ресурсы заблокированы, а какие - нет. Поэтому при работе даже двух пользователей файловая база иногда начинает тормозить.

На мой взгляд, по отношению цены и качества в клиент-серверном варианте побеждает опять I5-9600K за 15 тысяч рублей. Для работы до 50-ти пользователей этот процессор на мой скромный взгляд, основанный на результатах теста и количестве ядер, будет оптимальным. Субъективно же более дешевый AMD Ryzen 3500X будет не хуже, а 3600-й - лучше, т.к. у него в 2 раза больше потоков, что в пределе может обеспечить работу 100-ни пользователей клиент-серверной базы в комфортной зоне.

Среди процессоров класса Enterprise, к которым относятся процессоры Intel Xeon и AMD Epyc (тестов которых бескрайне мало), то объективно лучшим процессором по цене за попугай будет E5-2667 v3, т.к. он поддерживает ДВА сокета и может обеспечить приемлемой производительностью 200-300 пользователей на своих 16 ядрах и 32-х потоках и 4-х канальной памятью.

Среди дорогих процессоров этого сегмента самым лучшим для 1С будут Xeon(R) Gold 6144, у которого из этой серии максимальная частота в стоке и в бусте, но ценник в 3 килобакса за камень как бы намекает, что если у тебя меньше 300 пользователей, то это не для тебя. Этот процессор может быть установлен в плату с ЧЕТЫРЬМЯ сокетами и имеет 6-канальный контроллер памяти, что делает возможным собрать систему из 32-х ядер и 64-х потоков, которые могут дать вполне хорошо работать уже 600-м пользователям. Его собрат Xeon(R) Gold 6146 имея чуть более низкую частоту в стоке и в полтора раза большее количество ядер уже может позволить не сильно напрягаясь работать почти 1000 пользователей при 4-х сокетной сборке, стоимость и энергопотребление которой заставит взывать даже тех, кто покупает игровые компы на базе I9-9900X за пол-ляма.

ОБЩИЙ ИТОГ

Объективно побеждает у нас I9-9900K, который и в файловой, и в серверной в среднем набрал больше всех баллов. Но он не сильно выиграл у более дешевого I5-9600K, который я бы назвал лучшим процессором для компьютера разработчика 1С (если, конечно, Вы предвзято относитесь к процессорам на ZEN2 от AMD) и для небольшой компании, в которой с 1С одновременно работает не более 50-ти пользователей.

НАСТРОЙКА ПРОИЗВОДИТЕЛЬНОСТИ

Тесты хорошо показали, что один и тот же процессор как в файловой, так и в клиент-серверной базе может работать быстро, а может и тупить. Основная причина "тупизны" - это "сбалансированная" схема управления питанием, которая большую часть времени держит процессор на низкой частоте. Она в Windows является значением по-умолчанию, поэтому администратор легко может и забыть об этом, оставив все как есть. В 100% случаев установка максимальной производительности позволит повысить результат теста Гилева в полтора-два раза, а то и в три-четыре. Это в большей мере справедливо для серверной базы, но и в файловой такая настройка увеличит количество попугаев.

Т.е. первый совет самый простой - переключить схему энергопотребления сервера в режим высокой производительности.

Так же стоит обратить внимание на частоту памяти и на производительность дисковой подсистемы (IOPS). Чем больше эти цифры, тем выше скорость работы 1С.

Вообще, 1С - это стековая виртуальная машина интерпретатора, которая исполняя код кладет команды в стек и дальше вызывает функции, реализующие код команд на уровне процессора. При этом сначала строка разбирается, определяются функции, которые должны быть вызваны - присваивание, ветвление, встроенные функции и процедуры, вычисление выражений и т.д. Также происходят вызовы сервиса хранилища данных, в которые передается преобразованный текст запроса (если говорить о клиент-серверной базе, но в любом случае запрос к хранилищу данных вызывает кучу ожиданий на вводе-выводе или сетевом обмене).  И если система работает с данными, сохраненными в базе, то 1С производит кучу чтений из хранилища или кучу запросов к СУБД, которые предварительно преобразовываются. И тут причина того, что файловая база работает быстрее в однопоточном тесте в том, что не нужно ждать от СУБД данных - они читаются из файла файловой базы, содержимое которого находится в кеше ОС. Да, содержимое таблиц в СУБД тоже закешировно, но все-равно остается ожидание ответа запроса от другого процесса.

При этом скорость при включении профиля высокой производительности сильно растет из-за того, что процессор, переключаясь между контекстами выполнения кода 1С, ожидания на вводе-выводе и кода СУБД, производит изменение частоты конкретного ядра, занятого чем-либо. Пока сканируется память, работающая на более низкой частоте, чем частота процессора, пока читается файл, пока переключается контекст - все это вызывает циклы ожидания, и режим сбалансированной производительности снижает частоту ждущего ядра, пытаясь сэкономить электричество. При переключении в режим высокой производительности частота процессора может снижаться не так сильно и не так много времени нужно системе, чтобы восстановить максимально возможную частоту в бусте.

Из-за этого нужно не только включать высокую производительность, но и механизм Turbo-Boost, который позволяет системе работать куда быстрее стоковых частот. Благодаря этому даже процессоры со стоковой частотой в 1,6ГГц (как у меня) могут набрать в тесте Гилева более 80-ти баллов, при том субъективно работа в файловой базе ЕРП 2.4 на моем ноутбучном процессоре происходит куда быстрее, чем на рабочем 2ГГц Xeon с 32-мя ядрами - кто-то забыл грамотно настроить сервер.

ДАННЫЕ

Какой бы ни был быстрый и настроенный сервер, всегда найдутся данные, которые его завалят. Поэтому грамотная архитектура здесь, как говорится, "Must Have".

В основном запросы, которые кладут сервер, достаточно просты и однообразны и реализуют какое-нибудь декартово произведение достаточно большой таблицы на саму себя. Например, если соединить таблиц из 100к записей с самим собой, то на выходе мы получим 100 000 000 000 строк (я просто 100к умножил на 100к). Такой запрос легко убьет любую базу на любом сервере, ибо сто лярдов строк даже по килобайту дадут терабайт возвращаемой инфы, что повесит любой супермощный и отлично настроенный сервак. Отсюда как бы совсем простой и очевидный совет так не делать. А сделать так может пользователь, который, например, вызовет отчет без фильтрации, который в своей логике подразумевает эту фильтрацию в той или иной мере. Ну или отбор по реквизиту регистратора укажет, и если это бухгалтерский регистр, то регистраторов у него может быть очень много, и каждый регистратор станет соединением, что может создать очень нехорошую нагрузку на сервер.

Здесь мы можем подойти к двум видам баз данных - OLTP и OLAP. Первая база - это хранилище транзакций, вторая - большой регистр всего и вся для отчетов. Преобразуя логику отчетов из прямого доступа к регистрам бухгалтерии и документам к логике отдельного хранилища можно добиться роста производительности системы и снижения нагрузки на систему.

В принципе OLAP и OLTP  могут быть элементами одной базы, но лично я бы эти базы данных разделил, т.к. для каждой базы могут существовать разные настройки, позволяющие ей работать максимально быстро.

Разделив OLTP - базу данных, которая регистрирует события и контролирует остатки, оперирует множеством маленьких запросов для извлечения данных по индексам и множеством запросов на запись данных - и OLAP - базу, в которой осуществляются большие запросы к общему кубу данных, - можно уже значительно снизить нагрузку на сервер, даже не меняя базу для OLAP - просто скопировав в нее основную базу данных. Но если данные для OLAP преобразовать в отдельные регистры, то скорость доступа к ним даже больших запросов может серьезно вырасти.

В общем основной архитектурный совет - абстрагируйтесь от 1С в части построения хранилища отчетных данных, вытащите его наружу из Вашей транзакционной базы, используйте BI-инструменты - все это сократит время ожидания при отражении операций и при получении отчетных данных.

Для подобных архитектурных подходов в последнее время и сама 1С сделала немало: Анализ данных, Дата-акселератор и Копирование данных. Эти инструменты могут помочь выйти в части OLAP на другую архитектуру для крупных предприятий с хорошим бюджетом на IT, а мелким компаниям остается научиться выбирать и настраивать сервер, чтобы у него оставался запас по производительности, т.к. они вряд ли смогут оплатить OLAP, да и не нужен он им особо - свои три копейки они посчитают и без него, главное чтобы сервер не вис )))

Всем спасибо за внимание.