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

25.05.20

База данных - HighLoad оптимизация

Периодически занимаясь исследованиями производительности я повидал много решений. Делюсь некоторыми выводами на основании теста Гилева и собственных мыслей.

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

ВВЕДЕНИЕ

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

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

СБОР ДАННЫХ

Для сбора данных я использовал последнюю версию теста Гилева, в которой произвел тест своего компьютера - скромного ноутбука от 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 попугаев. В табличке ниже следующие колонки:

arch proc Max Min Avg
Файловая Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz 119,05 62,5 95,87
Файловая - = LINUX = - 142.86 72.46 95.40
Файловая Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz 128.21 78.13 94.98
Файловая Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz 111.11 80.65 91.27
Файловая Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz 113.64 57.47 87.32
Файловая Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz 106.38 54.95 83.74
Файловая Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz 111.11 55.56 83.15
Файловая Intel(R) Core(TM) i5-9600K CPU @ 3.70GHz 113.64 57.47 81.53


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

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

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

70-80

arch proc Max Min Avg
Файловая Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz 108.7 56.18 79.40
Файловая Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz 96.15 48.08 78.87
Файловая Intel(R) Xeon(R) E-2288G CPU @ 3.70GHz 98.04 54.95 74.68
Файловая Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz 100 50.51 74.24
Файловая Common KVM processor 106.38 53.76 73.18
Файловая Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz 100 50.51 70.48
Файловая Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz 90.91 46.3 70.22

 

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

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

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

60-70

arch proc Max Min Avg
Файловая Intel(R) Core(TM) i5-4670 CPU @ 3.40GHz 84.75 42.74 66.01
Файловая Intel(R) Xeon(R) CPU E5-2637 v4 @ 3.50GHz 80.65 43.86 64.65
Файловая Intel(R) Xeon(R) CPU E5-2667 v3 @ 3.20GHz 102.04 51.55 63.69
Файловая Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz 86.21 44.25 62.79
Файловая AMD Ryzen 5 2600 Six-Core Processor 84.75 42.74 62.60
Файловая Intel(R) Core(TM) i3-4170 CPU @ 3.70GHz 76.92 40.32 62.11
Файловая Intel(R) Core(TM) i3-8100 CPU @ 3.60GHz 78.13 42.74 61.41
Файловая Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz 81.97 41.32 61.29
Файловая Intel(R) Core(TM) i3-7100 CPU @ 3.90GHz 83.33 44.25 61.19
Файловая Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz 79.37 40.65 61.15
Файловая Intel(R) Core(TM) i5-4460  CPU @ 3.20GHz 87.72 44.25 60.79
Файловая Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz 75.76 39.06 60.78
Файловая Intel(R) Core(TM) i3-6100 CPU @ 3.70GHz 79.37 40 60.50
Файловая Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz 80.65 41.32 60.16
Файловая Intel(R) Core(TM) i5-3550 CPU @ 3.30GHz 83.33 41.67 60.13

 

Вот тут уже интересно - появляются базарные 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

arch proc Max Min Avg
SQL Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz 68.49 34.25 46.43
SQL - = LINUX = - 76.92 38.76 45.53
SQL Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz 68.49 34.25 44.75
SQL Intel(R) Core(TM) i5-9600K CPU @ 3.70GHz 62.5 31.65 44.52
SQL Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz 64.1 32.26 43.30
SQL Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz 64.1 32.26 42.81
SQL Intel(R) Xeon(R) Gold 6144 CPU @ 3.50GHz 60.98 30.67 42.04
SQL Intel(R) Xeon(R) Gold 6154 CPU @ 3.00GHz 67.12 33.78 41.74
SQL Intel(R) Xeon(R) W-2145 CPU @ 3.70GHz 58.14 29.24 41.72
SQL Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz 65.79 33.11 41.10
SQL Intel(R) Xeon(R) Gold 5122 CPU @ 3.60GHz 52.63 26.6 40.89
SQL Intel(R) Xeon(R) CPU E5-2643 v4 @ 3.40GHz" 68.49 34.25 40.70
SQL Intel(R) Xeon(R) Gold 6254 CPU @ 3.10GHz 54.95 28.41 40.31

 

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

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

30-40

arch proc Max Min Avg
SQL Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz 56.18 28.57 39.49
SQL Intel(R) Xeon(R) Gold 6134 CPU @ 3.20GHz 51.55 25.91 38.96
SQL Intel(R) Xeon(R) CPU E5-2667 v3 @ 3.20GHz 62.5 31.45 38.67
SQL Intel(R) Xeon(R) Gold 6128 CPU @ 3.40GHz 54.35 27.47 37.84
SQL Intel(R) Xeon(R) CPU E5-2643 v3 @ 3.40GHz 48.08 24.15 36.55
SQL Intel(R) Xeon(R) CPU E5-1650 v4 @ 3.60GHz 49.5 24.88 36.49
SQL Intel(R) Xeon(R) CPU E3-1270 v6 @ 3.80GHz 52.08 26.18 36.23
SQL Intel(R) Xeon(R) E-2186G CPU @ 3.80GHz 47.62 26.46 35.54
SQL Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz 51.55 25.91 35.25
SQL Intel(R) Xeon(R) Gold 6136 CPU @ 3.00GHz 50 25.13 34.88
SQL Intel(R) Xeon(R) CPU E5-2637 v4 @ 3.50GHz 46.3 23.26 34.81
SQL Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz 50.51 25.51 34.74
SQL Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz 49.02 24.63 34.53
SQL Intel(R) Xeon(R) CPU E3-1270 V2 @ 3.50GHz 43.48 21.83 33.72
SQL Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz 47.62 24.15 33.64
SQL Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz 61.73 31.06 33.51
SQL Intel(R) Xeon(R) Gold 6126 CPU @ 2.60GHz" 47.62 24.15 33.04
SQL Intel(R) Xeon(R) CPU E5-1650 v2 @ 3.50GHz 45.45 22.73 32.89
SQL Intel(R) Xeon(R) CPU E3-1220 v3 @ 3.10GHz 43.86 22.03 32.68
SQL Intel(R) Xeon(R) CPU E5-2667 v4 @ 3.20GHz 46.73 23.47 32.60
SQL Intel(R) Xeon(R) CPU E5-2623 v3 @ 3.00GHz 43.86 22.32 32.56
SQL Intel(R) Xeon(R) Silver 4210 CPU @ 2.20GHz 43.1 22.52 32.38
SQL Intel(R) Xeon(R) CPU E3-1220 V2 @ 3.10GHz 40.98 20.66 32.34
SQL Intel(R) Core(TM) i7-3820 CPU @ 3.60GHz 47.17 23.7 31.94
SQL Intel(R) Xeon(R) CPU E3-1270 v3 @ 3.50GHz 42.74 22.52 31.54
SQL Intel(R) Xeon(R) CPU E5-2667 v2 @ 3.30GHz 45.45 22.73 31.48
SQL Intel(R) Xeon(R) CPU E5-2643 0 @ 3.30GHz 47.62 24.04 31.35
SQL Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz 42.37 21.19 31.23
SQL Intel(R) Xeon(R) CPU E3-1240 v5 @ 3.50GHz 44.25 22.32 30.76
SQL Intel(R) Xeon(R) CPU E3-1240 v3 @ 3.40GHz 40.65 20.33 30.14
SQL Intel(R) Core(TM) i3-4330 CPU @ 3.50GHz 33.33 17.99 30.08

 

Здесь уже процессоров куда больше. Радует появление в списке уже отметившегося в файловой базе 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, да и не нужен он им особо - свои три копейки они посчитают и без него, главное чтобы сервер не вис )))

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

процессор выбор скорость hiload benchmark производительность

См. также

Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Анализ простого плана запроса. Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы.

13.03.2024    2982    spyke    26    

42

Быстродействие типовой 1С

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Оказывается, в типовых конфигурациях 1С есть, что улучшить!

13.03.2024    5111    vasilev2015    19    

37

Анализируем SQL сервер глазами 1С-ника

HighLoad оптимизация Инструменты администратора БД Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Обработка для простого и удобного анализа настроек, нагрузки и проблем с SQL сервером с упором на использование оного для 1С. Анализ текущих зааросов на sql, ожиданий, конвертация запроса в 1с и рекомендации где может тормозить

1 стартмани

15.02.2024    7641    158    ZAOSTG    68    

96

Удаление строк из таблицы значений различными способами с замером производительности

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Встал вопрос: как быстро удалить строки из ТЗ? Рассмотрел пять вариантов реализации этой задачи. Сравнил их друг с другом на разных объёмах данных с разным процентом удаляемых строк. Также сравнил с выгрузкой с отбором по структуре.

09.01.2024    5978    doom2good    48    

63

Опыт оптимизации 1С на PostgreSQL

HighLoad оптимизация Бесплатно (free)

При переводе типовой конфигурации 1C ERP/УТ/КА на PostgreSQL придется вложить ресурсы в доработку и оптимизацию запросов. Расскажем, на что обратить внимание при потерях производительности и какие инструменты/подходы помогут расследовать проблемы после перехода.

20.11.2023    8872    ivanov660    6    

76

ТОП проблем/задач у владельцев КОРП лицензий 1С на основе опыта РКЛ

HighLoad оптимизация Бесплатно (free)

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

15.11.2023    5105    a.doroshkevich    20    

72

Начните уже использовать хранилище запросов

HighLoad оптимизация Запросы

Очень немногие из тех, кто занимается поддержкой MS SQL, работают с хранилищем запросов. А ведь хранилище запросов – это очень удобный, мощный и, главное, бесплатный инструмент, позволяющий быстро найти и локализовать проблему производительности и потребления ресурсов запросами. В статье расскажем о том, как использовать хранилище запросов в MS SQL и какие плюсы и минусы у него есть.

11.10.2023    16186    skovpin_sa    14    

98
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. 3vs 25.05.20 07:39 Сейчас в теме
Интересно на серверах Омской фирмы BITBLAZE на отечественных процессорах Эльбрус bitblaze.ru кто-нибудь подобные тесты проводил?
maksa2005; KilloN; METAL; gc3; +4 Ответить
2. maksal 51 25.05.20 08:24 Сейчас в теме
Отличная статья! Спасибо за труд!
user932300; METAL; +2 Ответить
3. capitan 2466 25.05.20 09:46 Сейчас в теме
Круто. Где можно столько процов достать ? )
Практически никогда не видел сервера приложений, производительность которого уперлась бы в процессор.
Скорее в винты все упирается.
А процессор конечно всегда хочется побыстрее, это первое что на ум приходит.
И от AMD еще с давних времен осадочек остался. В основном конечно они как печка греют. Не знаю как нынешние.
Ну и компилируют софт в 90% исходя их интелов.
Поэтому не знаю не знаю.
4. nickperel 5 25.05.20 11:12 Сейчас в теме
Надо уже, наверно, в 2020 переехать на многопоточность внутри кода клиентов и платформы. Многоядерные процессоры общедоступны
Нет - по прежнему 1С хорошо пилят те процессоры, где высокая максимальная частота на ядро и архитектура старается "держать" ее как можно выше при общей нагрузке.
Да и вообще, желательно убрать ее совсем - эту "общую нагрузку". Тогда тест покажет особенно высокие попугаи.
У 1С везде пилит линейный код. Я даже не слышал чтобы на это обращалось внимание и считалось проблемой.
"Используйте регламентные задания..", да да.
15. ArchLord42 83 25.05.20 14:12 Сейчас в теме
(4) Ох уж эти разрабы, не дают простому один эснику страдать от синхронизации потоков, конкуретности, дедлоков и контекст свитчинга :(((
Фоновые задания слишком легко...понимаю :)

Если вы думаете, что сделать многопоточное приложение легко, то я вас разочарую, это довольно сложный процесс, я даже больше скажу, в 2020!!! году современные приложения на других языках пишутся не с оглядкой на многопоточность, а на максимальную утилизацию потоков, распространненный async \ await паттерн тому пример.
16. starik-2005 3033 25.05.20 14:21 Сейчас в теме
(15)
Если вы думаете, что сделать многопоточное приложение легко, то я вас разочарую, это довольно сложный процесс
В действительности все зависит от сложности приложения. Я, например, множество Мандельброта на С рисовал, разделив окно на столько частей, сколько у меня ядер/потоков. Более того, встречал в интернете простой код, который делал то же самое - создать поток и передать ему координаты - вообще не проблема.

Но когда в приложении разные потоки могут читать и писать одно и то же, то, обычно, выделяют быстрый однопоточный механизм вставки/чтения и вокруг него множество потоков генерируют ему задачи. На этом принципе основан REDIS и NGINX, например, поэтому они такие резкие )))
20. ArchLord42 83 25.05.20 18:18 Сейчас в теме
(16)
Я, например, множество Мандельброта на С рисовал, разделив окно на столько частей, сколько у меня ядер/потоков. Более того, встречал в интернете простой код, который делал то же самое - создать поток и передать ему координаты - вообще не проблема.


Вы как пример приводите 1 алгоритм, который к счастью, хорошо лег, на многопоточную архитектуру, я же говорю о приложении, где алгоритмов много и не всё хорошо ложится в многопоточность и начинаются проблемы.


(16)
Но когда в приложении разные потоки могут читать и писать одно и то же, то, обычно, выделяют быстрый однопоточный механизм вставки/чтения и вокруг него множество потоков генерируют ему задачи. На этом принципе основан REDIS и NGINX, например, поэтому они такие резкие )))


Вот как раз наоборот, из-за того NGINX однопоточен и у него нет контекст свитчинга, он работает быстро :)
Так же у него выделяется несколько дочерних процессов (workers) обычно на количество ядер, но все процессы работают в однопоточном режиме, тут скорость же достигается из-за того, что работает они в асинхронном режиме со стейт машинами, async IO + events, грубо говоря тот же async \ await.

В общем формула тут такая:

Быстродействие != многопточность
Многопточность != асинхронность
21. starik-2005 3033 25.05.20 18:27 Сейчас в теме
(20)
NGINX однопоточен
У него процесс, который обходит пул, соединений действительно однопоточен. Остальные потоки - это потоки инициируемых соединений, которые вставляют в пул новые задачи. ТАкже и в REDIS - есть поток работы с таблицей, есть потоки, которые поставляют ему порции данных и ключей, в итоге блокируются только они, а основной процесс работает без блокировок, поэтому и быстрый. У меня REDIS показывает на set/get тесте больше 2кк операций в секунду:
sergey*ProBook430G5:~$ redis-benchmark -P 100 -n 3000000 -t get set
====== set ======
3000000 requests completed in 1.43 seconds
50 parallel clients
3 bytes payload
keep alive: 1

0.02% <= 1 milliseconds
15.29% <= 2 milliseconds
99.94% <= 3 milliseconds
100.00% <= 3 milliseconds
2102312.50 requests per second


Но, например, множество математических задач могут хорошо параллелиться - нейросети те же, рендеринг, кодировка видео/фото, архивирование/разархивирование. Там основной принцип в разделении данных на порции и скармливание этих порций параллельным обработчикам, в итоге скорость растет пропорционально количеству потоков процессора.
22. ArchLord42 83 25.05.20 18:28 Сейчас в теме
Если бы на каждое содеинение инициировался поток, вам бы не процессора не оперативной памяти не хватило. Это довольно жуткий оверхед получился бы.

Рекомендую ознакомится с докладом Jeffrey Richter — Building responsive and scalable applications, на ютубчике есть, там супер подробно рассказано что такое асинхронность, почему многопточность это иногда зло и как делать приложения быстрыми. Правда про .NET (но кода почти нет) и на иглише, но подробнее не видел

А то что вы мне какие то замеры кидаете...и про нейронки пишите...хм да это и так понятно, я ж не говорю, что многопоточность = зло. Я говорю, что это сложно, не всегда возможно (кстати да, GUI приложения очень сильно завязаны на одном едиственном GUI потоке) и что асинхронность это чаще всего залог производительности, которую часто путают с многопоточностью.
24. starik-2005 3033 25.05.20 18:33 Сейчас в теме
(22)
Если бы на каждое содеинение инициировался поток
Смотря сколько бы он жил. Если миллисекунду, то за секунду таких потоков можно было бы очень много породить. В вебке все как раз меряется этими миллисекундами, и борьба, соответственно, идет за них. Здесь у меня бенчмарк REDISа работает в режиме именованного потока, т.е. пишет в pipe-файл данные, а на той стороне кто-то этот файл слушает. Но если сделать это без именованного потока, то скорость падает лишь в 10 раз:
sergey*ProBook430G5:~$ redis-benchmark -n 3000000 -t get set
====== set ======
3000000 requests completed in 14.59 seconds
50 parallel clients
3 bytes payload
keep alive: 1

99.94% <= 1 milliseconds
100.00% <= 2 milliseconds
100.00% <= 3 milliseconds
100.00% <= 3 milliseconds
205578.02 requests per second
Показать
25. ArchLord42 83 25.05.20 18:34 Сейчас в теме
(24) Не важно сколько бы он жил, важно что если я кину 1000 реквестов в одну единицу времени оверхед по памяти и процессору (на инициализацию потока) был бы очень сильным, вот как раз так АПАЧ \ IIS и работают.

Даже если представить что у нас 512gb оперативки, и скажем 64 ядерный проц, то в тик времени, процессор будет пережевывать только 64 потока \ реквеста, ну а на завершение реквеста нам будет нужно явно не 1 тик, а намного больше, что же для остальных реквестов?) ну ничего подождут :))

Ваш бенчмарк, который вы мне второй раз кидаете, показывает как хорошо работает асинхронность в nginx, спасибо я и так это знаю :)

Раз так любите бенчмарки, вот вам бенчмарк, который показывает разницу в подходах:
1) поток на реквест
2) асинхронный поток, который обрабатывает несколько реквестов.
https://i.stack.imgur.com/ds7Ly.png

ЗЫ. на самом деле, там все посложней, осюда чаще всего для повышения производительсности используется thread pool ибо не всегда можно избежать блокирующего вызова, в общем доклад выше, очень рекомендую :)
32. starik-2005 3033 25.05.20 19:03 Сейчас в теме
(25)
в общем доклад выше, очень рекомендую
Посмотрел, хорошая презентация. Все упирается в асинхронность, за которую я уже давно топлю в 1С и подвижки вроде как есть, но пока, на мой взгляд, достаточно туго.

Да, давно применяется пул потоков, который ими рулит. В 1С даже это используется во многих подсистемах управления многопоточностью, где один управляющий поток кормит потоки обработки извлекаемыми данными.
90. nickperel 5 26.05.20 16:35 Сейчас в теме
(15) Я знаю как их не просто делать. Поэтому давайте ничего не делать.
7. AndrewAks 11 25.05.20 12:20 Сейчас в теме
(3) Давно уже прошли времена горячих AMD, сейчас Intel гораздо горячее. И производительность в пересчёте на ватт у AMD гораздо выше, не зря Cloudflare в последнее время только Epyc ставят - по их исследованиям, AMD аж на 25% превосходят Intel по этому показателю. По абсолютной производительности Intel рулит только в играх, (да и то уже не во всех) буквально на единицы FPS. Ну и по цене AMD очень сильно дешевле. Остаётся загадкой, почему до сих пор в корпоративном сегменте царствует Intel (думаю, здесь надо искать причины в откатах вендорам)
unduty; SuhoffGV; Evg-Lylyk; mrsmrv; +4 Ответить
8. capitan 2466 25.05.20 12:30 Сейчас в теме
(7)Когда поколение сменится, тогда может быть )
Откаты не при чем. Вендорам нужна стабильность, чем выше тем лучше.
Даже андроид студии эмулятор только в этом году оптимизировали под AMD и то под относительно новые камни.
А я со своим домашним ПК тихо курю в сторонке. Как два ветеранчика )
Посмотрю пока как на ноутах дело пойдет.
И да, не бывает очень сильно дешевле ни с того ни с сего.
13. AndrewAks 11 25.05.20 13:27 Сейчас в теме
(8) Ни с того ни с сего не бывает ) если AMD прочно займут положение лидера, то цены тоже повысят. Сейчас же их цель - откусить как можно бОльшую долю рынка. Что касается ноутов - Ryzen 4xxx рвут новейшие мобильные Intel по всем показателям, и даже настольные часто опережают. Я бы вот с удовольствием взял какой-нибудь неттоп на Ryzen 7 4800H, холодный(45 Ватт), 8 ядер/16 потоков, высокая частота, быстрое видеоядро (старые игрушки раз в год гоняю), быстрее Intel Core i7-9700K(у которого в номинале потребление 95 Ватт, а по факту выше!), мне бы лет на 7 хватило. Но пока только ноуты на них делают.
17. capitan 2466 25.05.20 14:35 Сейчас в теме
(13)
Ryzen 7
ИМХО процессоры так быстро дешевеют, что я пока на самых топовых не вижу смысла брать.
+ На них еще все сыро и по факту это недешевый эксперимент.
https://technical.city/ru/cpu/Core-i7-4500U-protiv-Ryzen-5-3500U
Технологии виртуализации - нет данных
дополнительные инструкции - нет данных
а дороже в 2 раза
23. mrsmrv 125 25.05.20 18:33 Сейчас в теме
(17)
Технологии виртуализации - нет данных
дополнительные инструкции

Технологии виртуализации в процессорах амд чуть ли не раньше интела появились. А что за дополнительные инструкции?
В процессорах АМД сейчас нет лишь AVX512 относительно интела, но и они пока мало где применяются. Ну вряд ли в СУБД а тем более в 1С. Ну и актуальный сейчас Ryzen 4500u, который при 15 ваттах обходит в 65 ваттные и даже 95 ваттные процессоры конкурента. 7nm против 14nm всё же дают о себе знать, хоть и нанометры современные больше маркетинг, но всё же.
30. Salavat 13 25.05.20 18:58 Сейчас в теме
(28)
AMD-V
эта байда - в 1с, насколько сильно используется?

У АМД, есть однозначное преимущество (в настоящее время!) - с ОЗУ, они (последнее поколение) работают быстрее.
(У Интела, было быстрее, но... ряд патчей безопасности, снизил их скорость работы с ОЗУ)
38. mrsmrv 125 25.05.20 19:25 Сейчас в теме
(30)
AMD-V
эта байда - в 1с, насколько сильно используется?
Незнаю, но я просто отвечал на 17й коммент товарища и там он что-то про виртуализацию намекал что в АМД её нет. Ну вот я ему отписал что де, она там есть и даже лучше вроде как интеловской, по крайней мере что я помню, что она появилась давно и чуть ли не раньше интелей, а в википедии пишут что она ещё и лучше.
41. Salavat 13 25.05.20 19:28 Сейчас в теме
(38)
про виртуализацию
всегда был против этой байды.
вещают на 1 железку ещё кучу хрени.
И хотят выжать ещё соки (подозреваю и тот с 1,5 ГГц - в томже духе)
42. starik-2005 3033 25.05.20 19:31 Сейчас в теме
(41)
всегда был против этой байды.
Ну если говорить о сервисах, то вполне работоспособная система, ибо есть возможность выделить все небольшие сервисы в свой контейнер (сейчас для этого контейнеризация используется чаще). Да, нередко что-то большое и красивое, требовательное к частоте процессора типа 1С, в виртуальной среде начинает тупить, стоимость поиска проблем при таком раскладе может вылиться в стоимость нормального отдельного сервера.
46. Salavat 13 25.05.20 19:35 Сейчас в теме
(42)
есть возможность выделить все небольшие сервис
я так и обозвал - байда!
45. nomad_irk 71 25.05.20 19:34 Сейчас в теме
(41)Виртуализация - это благо в умелых руках, потому что процессор, как правило, простаивает бОльшую часть времени.
Да, за вирутализацию приходится платить "пенальти" в размере 20% абсолютной вычислительной мощности, но оно дает бОльшую утилизацию именно процессора.
47. Salavat 13 25.05.20 19:37 Сейчас в теме
(45)
потому что процессор, как правило, простаивает бОльшую часть времени.
у Вас (лично!) желудок тоже проставиват пустым, бОльшую часть времени.
Вы также - виртуализируете его, как я понимаю.
Ну - вперёд с оркестром!
Gilev.Vyacheslav; +1 Ответить
50. nomad_irk 71 25.05.20 19:40 Сейчас в теме
(47)
у Вас (лично!) желудок тоже проставиват пустым, бОльшую часть времени.

Это однозначно "мемориз" в контексте сравнения подсистемы живого организма и компьютера.

Вопросов больше не имею.
starik-2005; +1 Ответить
54. пользователь 25.05.20 19:43
Сообщение было скрыто модератором.
...
92. nickperel 5 26.05.20 16:48 Сейчас в теме
(45) Она, виртуализация, не нужна в большинстве российских контор. Причина - объективно не нужна.
Практически - сисадминов привлекает копирование и хранение актуального рабочего образа.
И кто там простаивает никого не волнует.
Gilev.Vyacheslav; +1 Ответить
93. Salavat 13 26.05.20 17:35 Сейчас в теме
(92)
Она, виртуализация, не нужна в большинстве российских контор. Причина - объективно не нужна.
Прям удивлён такой, правоте.
(надеюсь - это не сарказм был).
У нас, как минимум 4 из 5 сисадминов - считают за правило, виртуализировать всегда.
При любой возможности.
Если причины нет - рады придумать.
Gilev.Vyacheslav; +1 Ответить
164. nickperel 5 27.05.20 19:49 Сейчас в теме
(93) Нет, не сарказм.

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

Вот тот, что про "кучу херни" тут писал, тоже не прав. Виртуализация решает простую и нерешаемую спроста проблему - две независимых конторы (или подразделения конторы) на одном сервере. Данные будут взаимно закрыты и ими будут рулить независимые суперюзеры.
Или открытый интернету сервер.

Если это деньги, тогда можно и 1С подвинуть. Но 1С давят вируализацией по совершенно субъективным причинам в 99% случаях. Да еще и на убогом железе. Хотя она - прямые деньги.
166. Salavat 13 27.05.20 20:27 Сейчас в теме
(164)
тот, что про "кучу херни" тут писал, тоже не прав.
тот - это именно я.
потомучто чаще всего получается эта херня именно -
(164)
давят вируализацией по совершенно субъективным причинам в 99% случаях. Да еще и на убогом железе.


(164)
на одном сервере
- вот именно - виртуализация, это всего-лишь способ выкрутиться на безрыбьи.

И - ничего более.
(по своей сути)
Gilev.Vyacheslav; +1 Ответить
168. starik-2005 3033 27.05.20 22:01 Сейчас в теме
(164)
две независимых конторы (или подразделения конторы) на одном сервере. Данные будут взаимно закрыты и ими будут рулить независимые суперюзеры.
Или открытый интернету сервер.
Так это может быт решено на сервере СУБД путем создания двух пользователей для двух баз. И если пользователи эти внезапно оказались на одном сервере, значит что-то их связывает, если это не аренда. А если связывает, то смысл держать два сервера СУБД на одном железе? Да если и не связывает - все делится. Да и в базу зайти - пароль нужен, кто-то прописать к ней путь должен, связав сервер приложений и базу данных. На худой конец есть докер с контейнерами, в которых может быть поднято несколько серверов приложений 1С, но СУБД вполне может быть одна - она ровно тау же будет утилизировать "простаивающие" ресурсы сервера, только без штрафа виртуализации.
91. nickperel 5 26.05.20 16:45 Сейчас в теме
(41)
"
> про виртуализацию
>> всегда был против этой байды...... выжать соки.... куча херни....подозреваю.."

"шире мазки, шире". пока не попал, но продолжай.
там (где-то) заговор против тебя, точно говорю
94. Salavat 13 26.05.20 17:37 Сейчас в теме
(91)
"шире мазки, шире"
зато ты - здесь попал.
Только - не буду говорить (цензурных слов не подобрал), чем и куда.
165. nickperel 5 27.05.20 19:51 Сейчас в теме
(94) Хамить что ли пытаешься?
167. Salavat 13 27.05.20 20:30 Сейчас в теме
(165), я не пытался, а ответил тебе твоимже хамством.
(но вообщето - термин ты здесь - точно не в погоду подобрал.
Прочти всёже - почему (и за что! самое главное) хамство называется так)
241. starik-2005 3033 05.02.21 13:40 Сейчас в теме
(13) Ну вот, прошло время: теперь есть и гибридные процы для десктопов, и 5-е райзены, которые стали совсем быстрыми и дорогими (хотя прогресс наметился и 5600Х стоит 24 666 в наших краях),
19. mrsmrv 125 25.05.20 18:18 Сейчас в теме
(3)
И от AMD еще с давних времен осадочек остался.
помню в 2002-2003м году внедрял на шиферном заводе 1с 7.7 Комплексную, так вот мой домашний Дюрон 650, разогнанный до 950 мгц, перепроводил базу в два раза быстрее пня-4 клиентского серверного, дорогущий, навороченный сервак, а базу перепроводить я забирал себе. И да Дюрон этот у меня потом еще лет 10 проработал в качестве сервера, сначала основного. потом запасного. не подводил ни разу. вот такой у меня осадочек. А когда Athlon64 появились - вообще красота была. Железо надо брать по совокупности а не по осадочкам. Вот теперь интел делает печки, да и проблем с безопасностью нашлось уже порядком, да и проблемы с sata были в чипсетах. Короче проблем дохрена, но пипл хавает, как это было во времена пня-4. Да, сейчас у меня i-8700k, и брал я его когда уже ryzen первый появился, а до этого был i7-920, так что обвинять меня в предвзятости к интелу как-то смысла особого нет. Теперь присматриваюсь ко всем кандидатам, пока не решил. Посмотрим что будет ближе к новому году. Там и zen3 подойдёт к рынку уже.

p.s. знаете почему дюрон базу перепроводил быстрее? Скорее всего потому кэш первого уровня был по 64 килобайта на инструкции и данные, а не по 8 килобайт на данные и 12 киломикроопераций. Видимо это играло ключевую роль. Ну и длинный конвейер у пня-4 играл злую шутку с ветвящимся кодом.
72. 3vs 26.05.20 06:11 Сейчас в теме
(19)Кстати, Линус Торвальдс проапгрейдил свой основной рабочий ПК и перешел на AMD Ryzen Threadripper после 15 лет с Intel.
Линус Торвальдс (Linus Torvalds) в переписке, касающейся объявления о выходе Linux 5.7-rc7, рассказал, что на прошлой неделе он модернизировал свой рабочий ПК. Таким образом, впервые за 15 лет Торвальдс не использует сборку на базе компонентов Intel. Правда он добавил, что пока еще не перешел на ARM. Теперь рабочая система Торвальдса основана на AMD Threadripper 3970X.

Линус дополнительно уточнил, что модернизация на 32-ядерный 64-поточный процессор AMD Threadripper 3970X была очень волнительной для него.

Источник:
habr.com/ru/news/t/503658/

Линус что-то знает... :-)
mrsmrv; starik-2005; +2 Ответить
75. capitan 2466 26.05.20 10:05 Сейчас в теме
(3)Чтобы расставить так сказать точки над ё
Создатель Linux променял Intel на AMD впервые за 15 лет
Это наверное всех примирит и многое объяснит.
Возможно AMD и стал так хорош, но понимание этого в умах старперов людей моего поколения очень-очень недавно произошло.
256. 33333 09.08.21 10:59 Сейчас в теме
(3)Опыт каких годов с AMD? 1990х?
Очень часто вижу такие заявления, основанные на событиях 20 лет назад......
5. wolfsoft 2421 25.05.20 11:51 Сейчас в теме
Вывод: лучше быть богатым и здоровым, чем бедным и больным (с) :)
zliden1; ipoloskov; starik-2005; +3 Ответить
6. CheBurator 3119 25.05.20 12:08 Сейчас в теме
Спасибо. Отправил своему сисадмину как инфу для выбора процессоров
9. Sedaiko 572 25.05.20 12:47 Сейчас в теме
Уже давно не использую на клиент-серверных системах тест Гилева. Там он ни о чем не говорит.
На том же Xeon D-1557 1.50GHz дает результат ниже плинтуса.
Однако на на этом же хосте конфигурация из трех раздельных виртуальных серверов на ESXi - PSQL, 1С (8 ядер 2 сокета) и Apache при тестировании типовой конфигурации с тест-центром - дает вполне приемлемые результат на 50 пользователей.
И главное - ИМХО сервер для 1С должен быть сервером ТОЛЬКО для 1С (ну и СУБД). никакой терминалки, AD, файлопомойки и касперского. Максимум можно еще IIS или Apache. Терминалку, если обычные формы, лучше вывести на отдельный сервер.
11. nomad_irk 71 25.05.20 13:09 Сейчас в теме
(9)Попробуйте завести 1С на процессоре хотя бы 3ГГц и сравните с 1.5ГГц - там даже невооруженным глазом видны различия в скорости работы и "отзывчивости" учетной системы в целом.
Gilev.Vyacheslav; Salavat; +2 Ответить
12. Sedaiko 572 25.05.20 13:21 Сейчас в теме
(11) Это понятно. Я говорю про объективность теста Гилева - он не учитывает многопоточность.
14. nomad_irk 71 25.05.20 13:29 Сейчас в теме
(12) Она и не нужна в данном случае. Этот тест показывает скорость работы связки CPU-RAM-DISK для одного потока, т.к. интерпретатор языка 1С не умеет многопоточность, в привычном понимании этого термина.
Gilev.Vyacheslav; +1 Ответить
34. Salavat 13 25.05.20 19:07 Сейчас в теме
(14)
т.к. интерпретатор языка 1С не умеет многопоточность, в привычном понимании этого термина.
1с - никогда и не будет многозадачным.
Пример - попробуйте распараллелить восстановление последовательности документов.

Параллельность можно применить, только - если есть статические данные.
Архивирование, картинки, видео - всё.
А не те, что зависят от других (меняющихся).
Gilev.Vyacheslav; +1 Ответить
36. starik-2005 3033 25.05.20 19:16 Сейчас в теме
(34)
Пример - попробуйте распараллелить восстановление последовательности документов.
Не поверите, но даже на Инфостарте есть примеры этого распараллеливания с генерацией непересекающихся последовательностей документов по соглашениям/номенклатуре/комиссионерам.

Я в свое время на БП 2.0 делал многопоточное проведение документов. Т.к. это были услуги, то разделение пулов шло по контрагентам и комиссионерам. Это позволяло существенно снизить время проведения документов - практически пропорционально количеству потоков.
unduty; Irwin; mrsmrv; +3 Ответить
37. Salavat 13 25.05.20 19:20 Сейчас в теме
(36)
Не поверите
Здесь Вы правы абсолютно - не поверю!

Как можно выполнить задачу, у которой исходных данных, элементарно нет?

Попробуйте привести, реальный пример.
39. starik-2005 3033 25.05.20 19:26 Сейчас в теме
(37)
Как можно выполнить задачу, у которой исходных данных, элеме
Ну вот есть у Вас сто документов, в которых Вы продаете услуги. В этих ста документах есть сто разных соглашений с покупателями. Вы можете провести эти сто документов в ста разных потоках в любой последовательности, и это никак не нарушит согласованность данных, т.к. взаиморасчеты в каждом документе зависят от договора, а все договора разные.

Допустим, у нас есть тысяча документов. И в них есть сто разных товаров, у которых есть остатки, сто разных соглашений с покупателями. В итоге нам нужно найти документы, в которых соглашения и номенклатура не пересекается, сгруппировать их по пересекающейся номенклатуре и соглашениям. Пусть у нас получится сто групп по 5-15 документов. Дальше мы эти группы можем скормить разным потокам, упорядочив по дате и времени продажи. В итоге мы получим сто порций данных и будем последовательно кормить их освободившимся потокам. Если же это документы поступления, то нам тут вообще не нужно особо заморачиваться - достаточно скормить их до проведения реализаций, т.к. они не используют историческую информацию об остатках.
44. Salavat 13 25.05.20 19:33 Сейчас в теме
(39)многа букав - бессмысленных

ответил короче - http://forum.infostart.ru/forum34/topic241565/message2447157/#message2447157
Gilev.Vyacheslav; +1 Ответить
40. nomad_irk 71 25.05.20 19:26 Сейчас в теме
(34)
1с - никогда и не будет многозадачным.
Пример - попробуйте распараллелить восстановление последовательности документов.


Ой, никогда не говорите "никогда" :)
Восстановление последовательности может распараллелиться, если в ней будут разрезы ведения этой самой последовательности.
43. Salavat 13 25.05.20 19:32 Сейчас в теме
(40)
если в ней
если да кабы, да в роту росли грибы,..
я ведь привёл элементарную задачу - попробуйте её решить:
Распараллельте выполнение двух задач.
Исходные данные одной из них, зависят от решения другой.
Это и есть - последовательность.

хоть как её разрезайте - но - нет у Вас исходных данных, для решения первой задачи! она вынуждена ждать решения второй!
48. starik-2005 3033 25.05.20 19:39 Сейчас в теме
(43)
нет у Вас исходных данных, для решения первой задачи! она вынуждена ждать решения второй!
|Когда нет, а когда и есть.

Можно и иначе распараллелить проведение документов: получить остатки в какую-нить коллекцию, взять документ, создать наборы записей, создать проводки на основании остатков из коллекции и поменять значения в коллекции, но не записывать эти проводки, а поместить в пул записи, т.к. запись - это длительный процесс. Дальше идти к следующему документу, добавляя его проводки в пул, после того, как пул достигнет определенного размера, отправить данные пула в поток для записи. Т.к. запись - операция длительная, то следующая порция данных будет накоплена раньше, чем эти операции будут записаны - скормить их второму потоку, и т.д. В итоге один поток, формирующий движения, будет работать с памятью, а потоки персистентности будут параллельно записывать наборы записей в базу данных.
unduty; mrsmrv; +2 Ответить
51. Salavat 13 25.05.20 19:40 Сейчас в теме
(48)
Когда нет, а когда и есть.
я и говорю - нельзя распараллелить любое!
53. starik-2005 3033 25.05.20 19:42 Сейчас в теме
(51) очень большая часть задач в той или иной мере может быть распараллелена. 100% компьютерной графики в играх рассчитывается на огромном количестве параллельных графических процессоров в GPU.
57. Salavat 13 25.05.20 19:45 Сейчас в теме
(53)повторюсь - распараллеливается легко то - что имеются данные.
(архивирование - типичный пример)
когда нет данных - не распаралелить никак!!!
98. mrsmrv 125 26.05.20 18:18 Сейчас в теме
(57) т.е. вы считаете что восстановление последовательности документов для партионного учета, можно делать только последовательно? Даже если в базе уже все нужные документы есть?
49. nomad_irk 71 25.05.20 19:39 Сейчас в теме
(43)Как реализованы последовательности в условиях типовых конфигураций - это частный случай, в общем случае оно может распараллеливаться.
Если говорить общими терминами, так любая задача будет однопоточной, если для ее решения нужен результат решения другой задачи.
При чем тут 1С?
starik-2005; +1 Ответить
52. Salavat 13 25.05.20 19:42 Сейчас в теме
(49)при том, что - в 1с (как и в играх, кстати!) - именно это и есть аксиома!
55. nomad_irk 71 25.05.20 19:44 Сейчас в теме
(52) Вы выбрали какой-то частный случай в качестве примера, притянули сюда 1С и теперь пытаетесь доказать, что оно не работает или работает не так как хотелось бы?
Троллинг?
56. starik-2005 3033 25.05.20 19:45 Сейчас в теме
(55)
Троллинг?
Скорее троттлинг ))) Перегрелся парниша )))
unduty; nomad_irk; +2 Ответить
59. nomad_irk 71 25.05.20 19:46 Сейчас в теме
(56)Ага, по-другому и не назовешь :)
173. nickperel 5 28.05.20 19:06 Сейчас в теме
(56)
Интернетный спорщик. Это типа спорта. Открывает в другом окне браузера ответы какого - нибудь разработчика 1с и зачесывает оттуда.
Припоминаю этот примерчик с двумя зависимыми задачами.
174. nomad_irk 71 28.05.20 19:26 Сейчас в теме
(173)Да это тролль чистой воды. Изначально было лично мной сказано, что интерпретатор 1С не умеет многопоточность в привычном понимании этого термина.
Далее ему Сергей сказал о том, что при определенных условиях задача восстановления последовательности может быть распараллелена.
Но индивид топил тут усиленно именно за истинную многопоточность в его понимании, типа мы все тут мушкетеры, а он один - д'Артаньян.
Туды его в качель ©, блин.....

Я еще раз покажу историю, с чего начался весь сыр-бор:
Прикрепленные файлы:
176. nickperel 5 28.05.20 19:53 Сейчас в теме
(174)
Предполагается, что тролли остроумные и веселые ребята. А этот чего-то Навального давай поминать. УГ
Его вот эти загадки и заходы похожи на те, что программисты со стажем 100500+ лет задают на собеседованиях.
Нет цели узнать решение.
Что - то психологическое... хз
177. nomad_irk 71 28.05.20 20:15 Сейчас в теме
(176)Так ему ж 100500 раз ответил лично я, что, если прям только 2 документа взаимосвязанных, то задачу нельзя распараллелить и параллелить такие объемы данных никто в здравом уме даже не будет пытаться.

В общем, ну его в болото........проехали.
196. mrsmrv 125 03.06.20 10:35 Сейчас в теме
(177)Если интересно, то я ему выложил свой вариант параллельной обработки цепочек приходов и расходов товаров с текстом модулей: http://forum.infostart.ru/forum34/topic241565/message2451732/#message2451732
starik-2005; nomad_irk; +2 Ответить
61. Salavat 13 25.05.20 19:46 Сейчас в теме
(55)я привёл типичный пример - нерешаемости!
сами считайте как хотите.
63. nomad_irk 71 25.05.20 19:50 Сейчас в теме
(61)Вам никто в этой теме не говорил, что все задачи, решаемые с помощью процессора, могут распараллеливаться и никто не спорил с вашим утверждением, что приведенный вами пример не распараллеивается.
Все, вопрос про признаки распараллеливаемых задач исчерпан?
64. Salavat 13 25.05.20 19:52 Сейчас в теме
(63)вот именно, я только про это.
65. starik-2005 3033 25.05.20 19:59 Сейчас в теме
(63) просто задача восстановления последовательности документов не относится к задачам, которые не могут быть распараллелены, т.к. не все документы последовательности исторически зависимы. Если мы купили лоток булок и баранки, а потом продавали то булки, то баранки, то у нас тут как минимум два потока - продажа булок и продажа баранков. Если же случилось так, что и булки и бараки были куплены одновременно, то этот документ - точка синхронизации потоков. В реальной жизни все сложнее, поэтому и потоков больше, и точек синхронизации потоков больше, поэтому можно распараллелить иначе - вынести в отдельные потоки только результаты, которые нужно сохранить в БД, т.к. это самая длительная операция, а расчет движений сделать в один поток, только не читать остатки каждый раз, а поддерживать их в какой-нить коллекции - той же таблице значений, доступ к строкам которой будет быстрее, чем запрос к БД.
97. mrsmrv 125 26.05.20 18:16 Сейчас в теме
(65) Согласен. Если задача партионного учёта, от коего 1С давно пытается откреститься, то я бы вообще взял бы номенклатуру из документов и моменты проведения документов, и всё это в одной матрице сводил бы по партиям, а потом уже раскидал бы готовые записи по документам. Т.е. не решал бы задачу вот надо последовательно провести вот эту кучу документов. Нет, на задачу нужно взглянуть не как на дорогу, на которой мы стоим и вдоль которой нужно пройти, считая коробочки, а если можно так выразится со спутника, посмотреть - вот дорога, вот коробочки. зачем мне идти по дороге, и считать коробочки, когда я могу за один снимок количество коробочек посчитать. На задачи нужно глядеть по другим углом. во первых, нахрена нужно перепровести тучу документов, какая цель, а если и нужно, то эти же цифры, по себестоимости списания каждого товара в каждом документе, можно получить другим способом. Причем заметьте, Эти же, а не какое-то приближение. Ну да, документов может быть много, матрица получится большая, но и с огромными матрицами уже научились справляться, в том числе (и в первую очередь) благодаря распарарллеливанию.
nomad_irk; +1 Ответить
100. nomad_irk 71 26.05.20 18:26 Сейчас в теме
(97) У товарища Salovat паззл никак не складывается :)
104. mrsmrv 125 26.05.20 18:44 Сейчас в теме
(100) пока наливал чай, подумал, даже если документов миллион, и номенклатуры миллион, значит просто надо будет обработать миллион матриц по 1000x1000, ну или 1000000х1000 тысячу матриц, ну типа по временнЫм отрезкам разбить. Но ведь именно это насколько я помню и "внедряет" 1с в своей РАУЗ. Там как раз задачу они сводят к решению СЛАУ. а что такое матрица 1000000х1000 это всего лишь (да уже веголишь) миллиард записей. А что там у нас уже умеют видеокарты, обрабатывать 16 гигабайт в своей быстрой (4096 битной HBM2) памяти. А тредриппер 64-х ядерный или Epyc с 8-ю каналами памяти, разве именно такие решения не призваны Параллельно ворочать большие объёмы данных. Интел говорите...
106. nomad_irk 71 26.05.20 18:49 Сейчас в теме
(104)РАУЗ - это принципиальный уход от строгой хронологии ввода первичных данных
Квант данных - не момент времени, а набор аналитик. Документы двигают наборы аналитик и потом уже по этим наборам аналитик строятся графы ну и результатом является система из N линейных уравнений.
108. mrsmrv 125 26.05.20 18:50 Сейчас в теме
(106)осталось только некоторому товарищу это как-то осознать
110. nomad_irk 71 26.05.20 18:52 Сейчас в теме
(108) Ага, ему уже 3 человека говорят о том, что восстановление последовательности В ОБЩЕМ СЛУЧАЕ - очень даже параллелится, но он уперся в какие-то документы и все тут.
111. starik-2005 3033 26.05.20 18:53 Сейчас в теме
(110)
уперся в какие-то документы
В первый документ - у него дальше мозга не работает. Для параллельности же нужно больше одного документа, а у него, видите ли, в первом документе нет исторических данных - все, Гитлер-капут )))
mrsmrv; nomad_irk; +2 Ответить
58. acanta 25.05.20 19:45 Сейчас в теме
(34) были несколько попыток разделить поток документов на несколько последовательностей, партии отдельно, взаиморасчеты отдельно. Но издержки от того, что при восстановлении одной последовательности ломаются все остальные, не оправдываются.
60. starik-2005 3033 25.05.20 19:46 Сейчас в теме
(58)
Но издержки от того, что при восстановлении одной последовательности ломаются все остальные не оправдываются.
У кого как. У меня, например, в бухгалтерии параллельное проведение документов ускорило процесс в 5 раз (6 потоков). То, что делалось день, стало делаться за полтора часа.
78. mrsmrv 125 26.05.20 12:10 Сейчас в теме
(34)
1с - никогда и не будет многозадачным.
а что мешает поиск во всех текстах в конфигураторе делать в многопотоков. Или вот проведение закрытия месяца делать средствами видеоядер (а такая идея у меня при появлении ge-force 256 в 1999м году стала гложить).
79. starik-2005 3033 26.05.20 12:21 Сейчас в теме
(78)
Или вот проведение закрытия месяца делать средствами видеоядер
Закрытие тормозит не из-за того, что производительности не хватает - я в 90-х разрабатывал системы для науки и там даже первопень справлялся за минуты, а данных было не в пример больше, чем в большинстве современных бухгалтерий. И даже используя СЛАУ основное время тратится не на сам расчет, а на извлечение данных для него. С другой стороны, распределение затрат - а именно это и является основной нагрузкой закрытия - достаточно быстрая однопроходная операция, и все умирает на реализации, а не на принципе, так что GPU тут, на мой скромный взгляд, - лишнее, ибо рендеринг одного кадра 4К содержит больше данных и операций, чем, полагаю, данные всех предприятий РОСТЕХа (более 1к), участвующих в закрытии, а современные игры на таком разрешении с хорошим видеоадаптером могут показать и 60 таких кадров в секунду.
82. Salavat 13 26.05.20 13:45 Сейчас в теме
(79)
Закрытие тормозит не из-за того, что производительности не хватает
Не согласен здесь.
Именно - производительности и не хватает.
(я не говорю, что есть ошибки и в методологии, в т.ч.. Они могут быть везде!)
Поставьте две копии одинаковой базы - на по-быстрее и по-медленнее системе.
И поймёте - хватает или нет.
(комуто хватает и 1,5 ГГц - как он сказал)
84. starik-2005 3033 26.05.20 14:30 Сейчас в теме
(82)
Именно - производительности и не хватает.
Так никто и не спорит, что один и тот же плохой алгоритм на более быстрой системе будет работать быстрее, но все-равно очень долго. И в закрытии месяца не производительности не хватает, а ума у разработчиков типовой (с другой стороны их можно понять - они делают очень универсальный инструмент для всех случаев жизни, но почти в каждой конторе чуть крупнее находятся случаи, на которые типовая не рассчитана, и приходится изобретать велосипеды).

(81)
В 1с, есть задачи, которые невозможно сделать параллельными.
Этих задач не так много, более того, параллелить можно не всю задачу, а ее часть (например, сохранение данных). То, что Вы не можете это понять - не грех, т.к. вообще мало народу, кто это понимает - тут уже нужно быть совсем не 1С-программистом.
Salavat; nomad_irk; +2 Ответить
85. Salavat 13 26.05.20 14:46 Сейчас в теме
(84)
никто и не спорит, что один и тот же плохой алгоритм на более быстрой системе будет работать быстрее
Вы не поняли про что я.
Конкретизирую - любая (абсолютно!) задача, будет решаться быстрее! На более быстрой системе.

(84)
Вы не можете это понять
здесь похоже, не понимаю, ни я, а именно Вы (и/или - мы друг друга).
задач, которые невозможно распараллелить, возможно и не сильно много.
я в принципе и не утверждал, что их количество - преобладает.
Я продолжаю утверждать, что как минимум одна задача (перепровести последовательность документов (порою - не единственную последовательность. Как минимум я знаю - Поступление и Реализация. Две последовательности. Затраты и Расходы - Плюс ещё две) встаёт ежемесячно и неединожды.
И эти расчёты (4, всего) - занимают продолжительное время.

Этот факт, надеюсь - не будете оспаривать.
86. nomad_irk 71 26.05.20 15:16 Сейчас в теме
(85)
Я продолжаю утверждать, что как минимум одна задача (перепровести последовательность документов (порою - не единственную последовательность. Как минимум я знаю - Поступление и Реализация. Две последовательности. Затраты и Расходы - Плюс ещё две) встаёт ежемесячно и неединожды.
И эти расчёты (4, всего) - занимают продолжительное время.


В первом приближении:

Восстановление последовательности Поступление/Реализация нельзя распараллелить ТОЛЬКО в случае одного склада.
Восстановление последовательности Затраты нельзя распараллелить ТОЛЬКО в случае одного подразделения/строго последовательной маршрутной карты/ и одного вида затрат(чего не может быть)
Восстановление последовательности Расходы нельзя распараллелить ТОЛЬКО в случае одного вида расходов.
87. Salavat 13 26.05.20 16:05 Сейчас в теме
Именно так -
(86)
В первом приближении:

А в реальности (если нужно точное значение) - распараллелить последовательность невозможно.
И это - в независимости, ни от чего.

Ответьте мне (повторюсь) - какую Вы возьмёте себестоимость остатка?
Если у Вас - предыдущие документы не сформировали его.

Ответ один - Только - Приближённую!

(ещё 1 подвопрос - зачем нужен документ "Корректировка Себестоимости"?)

Этим - и довольствуйтесь.
88. nomad_irk 71 26.05.20 16:18 Сейчас в теме
(87)
Ответьте мне (повторюсь) - какую Вы возьмёте себестоимость остатка?
Если у Вас - предыдущие документы не сформировали его.


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

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

Даже если себестоимость позиции атомарна, то параллелить можно по этой самой номенклатуре.
mrsmrv; starik-2005; +2 Ответить
89. Salavat 13 26.05.20 16:23 Сейчас в теме
(88)
Пока вы не поймете
Мы уже прекрасно поняли, что Вы - слова "умные" зазубрили, а смысл их, понять Вам не под силу, оказалось.
Скрытый текст
138. mrsmrv 125 26.05.20 20:00 Сейчас в теме
(87)
А в реальности (если нужно точное значение) - распараллелить последовательность невозможно.
И это - в независимости, ни от чего.

Ответьте мне (повторюсь) - какую Вы возьмёте себестоимость остатка?
Если у Вас - предыдущие документы не сформировали его.

Ответ один - Только - Приближённую!
Ну вам же описали КАК можно взять данные из базы одним запросом, всё в обработать и обратно результат в базу записать. А вы теперь прицепились к Двум документам и возможно по одному товару в каждому. Т.е. к вырожденным условиям задачи не требующими параллельности.
Roman_SE; nomad_irk; +2 Ответить
143. starik-2005 3033 26.05.20 20:06 Сейчас в теме
(138)
прицепились к Двум документам и возможно по одному товару в каждому
Ну так я ж говорил, что спорить с упертным математиком пенсионного возраста - задача бессмысленная: и нам не в кайф, и у него сердце может не выдержать - печалька.
nomad_irk; +1 Ответить
152. nomad_irk 71 26.05.20 20:23 Сейчас в теме
(143)да тут математическим складом ни ума, ни характера и не пахнет, на мой чисто субъективный взгляд :)
Тут скорее, эффект Даннинга-Крюгера.......
154. Salavat 13 26.05.20 20:38 Сейчас в теме
(152) Вопрос/задачу реши - продемонстрируй свой "ум" и "склад".
(или наверное даже "кладезь ума"?)
155. nomad_irk 71 26.05.20 20:44 Сейчас в теме
(154) Вам предыдущих решений недостаточно для понимания ущербности своего мышления?
Хорошо, повторюсь в 100500 раз: задача с двумя взаимозависимыми документами не сможет распараллелиться, потому, что это квант всего массива данных.
Про квант данных - не запоминайте, а то кэш переполнится и до кернел-паник не далеко.....
156. Salavat 13 26.05.20 20:47 Сейчас в теме
(155) я повторяюсь - сделай на любом количестве, которое позволяет.
Три - нормально?
Если нет - 4,.. и т.д.

Именно против этого (увеличения количества документов) - я не возражал(-ю).
Скрытый текст

И да - решения не было.
Была бубнёжка, пустая.
Оставьте свое сообщение