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

Публикация № 1240616

Администрирование - Производительность и оптимизация (HighLoad)

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

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

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

ВВЕДЕНИЕ

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

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

СБОР ДАННЫХ

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

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

Специальные предложения

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

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

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


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


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


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

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

Быстродействие != многопточность
Многопточность != асинхронность
21. starik-2005 2173 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 73 25.05.20 18:28 Сейчас в теме
Если бы на каждое содеинение инициировался поток, вам бы не процессора не оперативной памяти не хватило. Это довольно жуткий оверхед получился бы.

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

А то что вы мне какие то замеры кидаете...и про нейронки пишите...хм да это и так понятно, я ж не говорю, что многопоточность = зло. Я говорю, что это сложно, не всегда возможно (кстати да, GUI приложения очень сильно завязаны на одном едиственном GUI потоке) и что асинхронность это чаще всего залог производительности, которую часто путают с многопоточностью.
24. starik-2005 2173 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 73 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 2173 25.05.20 19:03 Сейчас в теме
(25)
в общем доклад выше, очень рекомендую
Посмотрел, хорошая презентация. Все упирается в асинхронность, за которую я уже давно топлю в 1С и подвижки вроде как есть, но пока, на мой взгляд, достаточно туго.

Да, давно применяется пул потоков, который ими рулит. В 1С даже это используется во многих подсистемах управления многопоточностью, где один управляющий поток кормит потоки обработки извлекаемыми данными.
90. nickperel 2 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 (думаю, здесь надо искать причины в откатах вендорам)
SuhoffGV; Evg-Lylyk; mrsmrv; +3 Ответить
8. capitan 1668 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 1668 25.05.20 14:35 Сейчас в теме
(13)
Ryzen 7
ИМХО процессоры так быстро дешевеют, что я пока на самых топовых не вижу смысла брать.
+ На них еще все сыро и по факту это недешевый эксперимент.
https://technical.city/ru/cpu/Core-i7-4500U-protiv-Ryzen-5-3500U
Технологии виртуализации - нет данных
дополнительные инструкции - нет данных
а дороже в 2 раза
23. mrsmrv 63 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 63 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 2173 25.05.20 19:31 Сейчас в теме
(41)
всегда был против этой байды.
Ну если говорить о сервисах, то вполне работоспособная система, ибо есть возможность выделить все небольшие сервисы в свой контейнер (сейчас для этого контейнеризация используется чаще). Да, нередко что-то большое и красивое, требовательное к частоте процессора типа 1С, в виртуальной среде начинает тупить, стоимость поиска проблем при таком раскладе может вылиться в стоимость нормального отдельного сервера.
46. Salavat 13 25.05.20 19:35 Сейчас в теме
(42)
есть возможность выделить все небольшие сервис
я так и обозвал - байда!
45. nomad_irk 47 25.05.20 19:34 Сейчас в теме
(41)Виртуализация - это благо в умелых руках, потому что процессор, как правило, простаивает бОльшую часть времени.
Да, за вирутализацию приходится платить "пенальти" в размере 20% абсолютной вычислительной мощности, но оно дает бОльшую утилизацию именно процессора.
47. Salavat 13 25.05.20 19:37 Сейчас в теме
(45)
потому что процессор, как правило, простаивает бОльшую часть времени.
у Вас (лично!) желудок тоже проставиват пустым, бОльшую часть времени.
Вы также - виртуализируете его, как я понимаю.
Ну - вперёд с оркестром!
50. nomad_irk 47 25.05.20 19:40 Сейчас в теме
(47)
у Вас (лично!) желудок тоже проставиват пустым, бОльшую часть времени.

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

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

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

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

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


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

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

"шире мазки, шире". пока не попал, но продолжай.
там (где-то) заговор против тебя, точно говорю
94. Salavat 13 26.05.20 17:37 Сейчас в теме
(91)
"шире мазки, шире"
зато ты - здесь попал.
Только - не буду говорить (цензурных слов не подобрал), чем и куда.
165. nickperel 2 27.05.20 19:51 Сейчас в теме
(94) Хамить что ли пытаешься?
167. Salavat 13 27.05.20 20:30 Сейчас в теме
(165), я не пытался, а ответил тебе твоимже хамством.
(но вообщето - термин ты здесь - точно не в погоду подобрал.
Прочти всёже - почему (и за что! самое главное) хамство называется так)
19. mrsmrv 63 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 1668 26.05.20 10:05 Сейчас в теме
(3)Чтобы расставить так сказать точки над ё
Создатель Linux променял Intel на AMD впервые за 15 лет
Это наверное всех примирит и многое объяснит.
Возможно AMD и стал так хорош, но понимание этого в умах старперов людей моего поколения очень-очень недавно произошло.
5. wolfsoft 2422 25.05.20 11:51 Сейчас в теме
Вывод: лучше быть богатым и здоровым, чем бедным и больным (с) :)
ipoloskov; starik-2005; +2 Ответить
6. CheBurator 3421 25.05.20 12:08 Сейчас в теме
Спасибо. Отправил своему сисадмину как инфу для выбора процессоров
9. Sedaiko 380 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 47 25.05.20 13:09 Сейчас в теме
(9)Попробуйте завести 1С на процессоре хотя бы 3ГГц и сравните с 1.5ГГц - там даже невооруженным глазом видны различия в скорости работы и "отзывчивости" учетной системы в целом.
Gilev.Vyacheslav; Salavat; +2 Ответить
12. Sedaiko 380 25.05.20 13:21 Сейчас в теме
(11) Это понятно. Я говорю про объективность теста Гилева - он не учитывает многопоточность.
14. nomad_irk 47 25.05.20 13:29 Сейчас в теме
(12) Она и не нужна в данном случае. Этот тест показывает скорость работы связки CPU-RAM-DISK для одного потока, т.к. интерпретатор языка 1С не умеет многопоточность, в привычном понимании этого термина.
34. Salavat 13 25.05.20 19:07 Сейчас в теме
(14)
т.к. интерпретатор языка 1С не умеет многопоточность, в привычном понимании этого термина.
1с - никогда и не будет многозадачным.
Пример - попробуйте распараллелить восстановление последовательности документов.

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

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

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

Попробуйте привести, реальный пример.
39. starik-2005 2173 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 47 25.05.20 19:26 Сейчас в теме
(34)
1с - никогда и не будет многозадачным.
Пример - попробуйте распараллелить восстановление последовательности документов.


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

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

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

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

В общем, ну его в болото........проехали.
196. mrsmrv 63 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 47 25.05.20 19:50 Сейчас в теме
(61)Вам никто в этой теме не говорил, что все задачи, решаемые с помощью процессора, могут распараллеливаться и никто не спорил с вашим утверждением, что приведенный вами пример не распараллеивается.
Все, вопрос про признаки распараллеливаемых задач исчерпан?
64. Salavat 13 25.05.20 19:52 Сейчас в теме
(63)вот именно, я только про это.
65. starik-2005 2173 25.05.20 19:59 Сейчас в теме
(63) просто задача восстановления последовательности документов не относится к задачам, которые не могут быть распараллелены, т.к. не все документы последовательности исторически зависимы. Если мы купили лоток булок и баранки, а потом продавали то булки, то баранки, то у нас тут как минимум два потока - продажа булок и продажа баранков. Если же случилось так, что и булки и бараки были куплены одновременно, то этот документ - точка синхронизации потоков. В реальной жизни все сложнее, поэтому и потоков больше, и точек синхронизации потоков больше, поэтому можно распараллелить иначе - вынести в отдельные потоки только результаты, которые нужно сохранить в БД, т.к. это самая длительная операция, а расчет движений сделать в один поток, только не читать остатки каждый раз, а поддерживать их в какой-нить коллекции - той же таблице значений, доступ к строкам которой будет быстрее, чем запрос к БД.
97. mrsmrv 63 26.05.20 18:16 Сейчас в теме
(65) Согласен. Если задача партионного учёта, от коего 1С давно пытается откреститься, то я бы вообще взял бы номенклатуру из документов и моменты проведения документов, и всё это в одной матрице сводил бы по партиям, а потом уже раскидал бы готовые записи по документам. Т.е. не решал бы задачу вот надо последовательно провести вот эту кучу документов. Нет, на задачу нужно взглянуть не как на дорогу, на которой мы стоим и вдоль которой нужно пройти, считая коробочки, а если можно так выразится со спутника, посмотреть - вот дорога, вот коробочки. зачем мне идти по дороге, и считать коробочки, когда я могу за один снимок количество коробочек посчитать. На задачи нужно глядеть по другим углом. во первых, нахрена нужно перепровести тучу документов, какая цель, а если и нужно, то эти же цифры, по себестоимости списания каждого товара в каждом документе, можно получить другим способом. Причем заметьте, Эти же, а не какое-то приближение. Ну да, документов может быть много, матрица получится большая, но и с огромными матрицами уже научились справляться, в том числе (и в первую очередь) благодаря распарарллеливанию.
nomad_irk; +1 Ответить
100. nomad_irk 47 26.05.20 18:26 Сейчас в теме
(97) У товарища Salovat паззл никак не складывается :)
104. mrsmrv 63 26.05.20 18:44 Сейчас в теме
(100) пока наливал чай, подумал, даже если документов миллион, и номенклатуры миллион, значит просто надо будет обработать миллион матриц по 1000x1000, ну или 1000000х1000 тысячу матриц, ну типа по временнЫм отрезкам разбить. Но ведь именно это насколько я помню и "внедряет" 1с в своей РАУЗ. Там как раз задачу они сводят к решению СЛАУ. а что такое матрица 1000000х1000 это всего лишь (да уже веголишь) миллиард записей. А что там у нас уже умеют видеокарты, обрабатывать 16 гигабайт в своей быстрой (4096 битной HBM2) памяти. А тредриппер 64-х ядерный или Epyc с 8-ю каналами памяти, разве именно такие решения не призваны Параллельно ворочать большие объёмы данных. Интел говорите...
106. nomad_irk 47 26.05.20 18:49 Сейчас в теме
(104)РАУЗ - это принципиальный уход от строгой хронологии ввода первичных данных
Квант данных - не момент времени, а набор аналитик. Документы двигают наборы аналитик и потом уже по этим наборам аналитик строятся графы ну и результатом является система из N линейных уравнений.
108. mrsmrv 63 26.05.20 18:50 Сейчас в теме
(106)осталось только некоторому товарищу это как-то осознать
110. nomad_irk 47 26.05.20 18:52 Сейчас в теме
(108) Ага, ему уже 3 человека говорят о том, что восстановление последовательности В ОБЩЕМ СЛУЧАЕ - очень даже параллелится, но он уперся в какие-то документы и все тут.
111. starik-2005 2173 26.05.20 18:53 Сейчас в теме
(110)
уперся в какие-то документы
В первый документ - у него дальше мозга не работает. Для параллельности же нужно больше одного документа, а у него, видите ли, в первом документе нет исторических данных - все, Гитлер-капут )))
mrsmrv; nomad_irk; +2 Ответить
58. acanta 25.05.20 19:45 Сейчас в теме
(34) были несколько попыток разделить поток документов на несколько последовательностей, партии отдельно, взаиморасчеты отдельно. Но издержки от того, что при восстановлении одной последовательности ломаются все остальные, не оправдываются.
60. starik-2005 2173 25.05.20 19:46 Сейчас в теме
(58)
Но издержки от того, что при восстановлении одной последовательности ломаются все остальные не оправдываются.
У кого как. У меня, например, в бухгалтерии параллельное проведение документов ускорило процесс в 5 раз (6 потоков). То, что делалось день, стало делаться за полтора часа.
78. mrsmrv 63 26.05.20 12:10 Сейчас в теме
(34)
1с - никогда и не будет многозадачным.
а что мешает поиск во всех текстах в конфигураторе делать в многопотоков. Или вот проведение закрытия месяца делать средствами видеоядер (а такая идея у меня при появлении ge-force 256 в 1999м году стала гложить).
79. starik-2005 2173 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 2173 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 47 26.05.20 15:16 Сейчас в теме
(85)
Я продолжаю утверждать, что как минимум одна задача (перепровести последовательность документов (порою - не единственную последовательность. Как минимум я знаю - Поступление и Реализация. Две последовательности. Затраты и Расходы - Плюс ещё две) встаёт ежемесячно и неединожды.
И эти расчёты (4, всего) - занимают продолжительное время.


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

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

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

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

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

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

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


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

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

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

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

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

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

И да - решения не было.
Была бубнёжка, пустая.
159. nomad_irk 47 26.05.20 21:18 Сейчас в теме
(156)
Хорошо, для простоты, как вы это любите, в последовательности участвуют 4 документа:

Поступление1
Поступление2
Реализация1
Реализация2

ПоступлениеN и реализацияN взаимосвязанные.

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

Самое простое решение:

1. Получаем запросом таблицу

Номенклатура1|Поступление1|
Номенклатура1|Реализация1|
Номенклатура2|Поступление2|
Номенклатура2|Реализация2|

2. Получаем из таблицы в п.1 список номенклатуры.
3. Формируем цикл по списку из п.2 , выполняя поиск строк в таблице из п.1 по номенклатуре.
4. Найденные строки сортируем по моменту времени документа, либо делаем свою сортировку списка в зависимости от прихода/расхода и сортируем так, чтобы приход был первым.
5. Внутри цикла из п.3. формируем фоновое задание, выполняющее процедуру проведения документа по набору значений.

Содержимое процедуры выполнения проведения из п.5:

1. Цикл по набору
2. Получить объект по ссылке в текущей строки набора.
3. Выполнить запись документа с проведением.


Это САМЫЙ ПРИМИТИВНЫЙ алгоритм из всех, что можно вообще придумать.
160. Salavat 13 26.05.20 21:28 Сейчас в теме
(159)
Для того, чтобы можно было выполнить параллельное выполнение восстановления последовательности необходимо наличие непересекающихся аналитик в документах. Непересекающейся аналитикой, опять же для простоты, будем считать номенклатуру - она разная в каждой паре документов приход-расход.

ах вон оно чё - собакато зарыта там, где я и говорил.
Дорогуша - это не распараллеливание, а "распараллеливание" всего-лишь.
(набор громких/звучных/.../бессмысленных наименований)

Ты предлагаешь (перед твоим "распараллеливанием" - сначала проверять исполнение твоих условий?
И - много ты покупателей "этого чудо-алгоритма" набрал?
А не многоли ты о себе возомнил?

на перельмановский приз - ты не претендуешь.
Скрытый текст


Это САМЫЙ ПРИМИТИВНЫЙ алгоритм
давай усложняй - мне главное решение.
(повторюсь - не "решение"!)
Всякое фуфло (хотя я понял уже бессмысленность - у нас разные понятия, об общеизвестных принципах/ценностях. Ты из тех, кто - "языком работает") - пропускай.
162. Salavat 13 26.05.20 22:00 Сейчас в теме
(161) я снова не понял - тебе опять надо повторить?
Нафига ты историю (сию) показываешь?
Я изменил свою т.з. или что/как?
Нет и не собираюсь - отрицать очевидное.
Единственное добавляю - покажите решение (кто не согласен с моей т.з.)

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

Называешь это троллингом - твоё право.
Впрочем - также как и "решения", продавать.
а потом придумывать оправдания.
150. Salavat 13 26.05.20 20:15 Сейчас в теме
(138) нам написали уже многие, да.
Я ответил одним вопросом - https://forum.infostart.ru/forum34/topic241565/?PAGEN_1=2#message2447915

Прицепился только потомучто вы (навальновцы, местные) - очевидность "отрицаете".
(надумываете какието условия выполнения своих распараллеливаний)

Два - это для простоты (также как начинают в школе - не с интегралов/диффернциалов, а именоо с 1+1)

Если тебе легче будет - покажи решение на трёх (или - какое у тебя условие "распараллеливания твоего")) документах.
Оставьте свое сообщение

См. также

Диспетчер Хранилища Запросов в SQL Server 2016+ (он же Query Store) Промо

Производительность и оптимизация (HighLoad) Бесплатно (free)

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

26.04.2019    10658    0    Aleksey.Bochkov    7    

Автоматическая классификация ошибок технологического журнала

Технологический журнал v8 1cv8.cf Бесплатно (free)

В статье обсудим пример практической настройки конфигурации «Мониторинг производительности» для автоматической классификации ошибок по группам/кластерам на данных текстов описания ошибок. Используем механизм векторной модели текстов и косинусное сходство между ними.

25.06.2020    1652    0    ivanov660    12    

Выявляем и оптимизируем ресурсоемкие запросы 1С:Предприятия

Производительность и оптимизация (HighLoad) Администрирование СУБД Технологический журнал Структура метаданных v8::Запросы Бесплатно (free)

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

24.05.2020    5816    0    DataReducer    22    

Учимся готовить кроликов с редиской: опыт применения Rabbit MQ и Redis в интеграционных проектах

Производительность и оптимизация (HighLoad) Интеграция Бесплатно (free)

При построении мощных производительных отказоустойчивых решений для интеграции во всем мире активно используются технологии обработки очередей сообщений с помощью брокера RabbitMQ и кэш-сервера Redis. О практическом опыте использования этих технологий при построении ИТ-ландшафта, включающего системы на 1С, на конференции Infostart Event 2019 Inception рассказал Сергей Наумов.

12.05.2020    4324    0    SergeyN    3    

Опыт миграции из собственного датацентра в облако AWS Промо

Производительность и оптимизация (HighLoad) Бесплатно (free)

Хотя данная публикация и не имеет прямого отношения к 1С, она может быть интересна тем, кто занимается крупными базами данных на MS SQL Server. Описывается опыт миграции баз данных в облако AWS в компании glassdoor.com, где я занимался этим проектом. Это первый драфт текста, получившийся довольно скомканным - в процессе буду дополнять.

29.07.2018    11125    0    Aleksey.Bochkov    9    

Ок, Лариса! Мониторинг проблем производительности с применением нейронных сетей

Производительность и оптимизация (HighLoad) Бесплатно (free)

Проводить мониторинг производительности вручную, выявляя закономерности в куче графиков и десятках таблиц, довольно сложно. Но это не значит, что разбираться с инцидентами нужно только после жалоб от пользователей. О том, как обучить нейронную сеть и заставить ее оповещать о проблемах, на конференции Infostart Event 2019 Inception рассказал начальник сектора разработки ООО «Группа Полипластик» Владимир Крючков.

27.04.2020    3545    0    ivanov660    5    

Пример поиска ошибок в технологическом журнале

Технологический журнал Производительность и оптимизация (HighLoad) Бесплатно (free)

Примеры bash - скриптов для поиска ошибок в технологическом журнале.

23.04.2020    2332    0    vasilev2015    6    

Фреймворк "Мониторинг производительности". Руководство пользователя

Производительность и оптимизация (HighLoad) Бесплатно (free)

Описание и руководство "Мониторинг производительности": краткое описание конфигурации, сборник из статей, примеров - собрано в одном файле.

21.04.2020    2720    0    ivanov660    3    

Исследование технологического журнала 1С при помощи регулярных выражений в блокноте Промо

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Все из тех, кто пробовали сдать на сертификат "Эксперт по технологическим вопросам 1С", сталкивались с методикой ЦКТП - разбор файлов технологического журнала при помощи консоли bash. Я, в свою очередь,внёс изменения в данную методику. Мне хотелось достичь более понятного вида и сфокусироваться на Perl, в качестве предпочтительного средства обработки файлов ТЖ. Вот что из этого вышло:

30.10.2017    28670    0    MrWonder    42    

Эти занимательные временные таблицы

Производительность и оптимизация (HighLoad) Администрирование СУБД v8 Бесплатно (free)

Кое-что интересное о временных таблицах и работе платформы 1С с ними.

06.04.2020    9846    0    YPermitin    0    

Как я собрал для себя высокопроизводительный и бесплатный облачный бекенд для 1С на PosgreSQL + PostgREST

Производительность и оптимизация (HighLoad) WEB Интеграция Мобильная разработка Администрирование веб-серверов v8 Бесплатно (free)

В этой статье я расскажу о проблемах бека для мобильных приложений или другого фронта, который требует производительности, быстрой реакции и отказоустойчивости, и как я решил это благодаря opensource проекту PostgREST и СУБД Postgre SQL 12. Проведу простой тест производительности для сравнения 1С с данным решением. Это может быть полезно всем, кто разрабатывает мобильные приложения либо фронтсайд-приложения для 1С на чем угодно - на мобильной платформе или на нативном языке или на Simple UI. И также обзор новых функций SimpleUI для связи с этим бекендом.

31.03.2020    10985    0    informa1555    21    

Многострочный контекст событий

Производительность и оптимизация (HighLoad) Технологический журнал v8 Бесплатно (free)

Разбор технологического журнала с группировкой событий по первой или последней строке многострочного контекста.

31.03.2020    2709    0    vasilev2015    9    

Опыт оптимизации и контроля производительности в БД с 3000 пользователей Промо

Производительность и оптимизация (HighLoad) Бесплатно (free)

Данная статья написана по материалам доклада, прочитанного на Конференции Инфостарта IE 2014 29-31 октября 2014 года. Меня зовут Сергей, являюсь руководителем отдела оптимизации и производительности систем в компании "Деловые линии". Цель этого доклада – поделиться информацией о нашем опыте работы с большой базой на платформе 1С, с чем пришлось столкнуться, как удалось обеспечить работоспособность. Уверен, что вам будет интересно, так как подобной информацией мало кто делится, да и про само существование таких систем их владельцы стараются не рассказывать, максимум про это «краем глаза» упоминают участвовавшие в проекте вендоры. **update от 04.03.2016 по вопросам из комментариев

05.08.2015    60266    0    Sergey.Noskov    119    

Анализ взаимоблокировок

Производительность и оптимизация (HighLoad) Технологический журнал v8 Бесплатно (free)

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

20.03.2020    3968    0    vasilev2015    21    

Многопоточность

Практика программирования Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Увеличиваем скорость загрузки данных в 20 раз. Как следует использовать многопоточность и готовый модуль для внедрения.

18.03.2020    5986    0    kaliuzhnyi    43    

Долго открывается конфигуратор Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

В ОС Windows Server 2012 бывает полезно выключать службу Dynamic Fair Share Scheduling (DFSS позволяет балансировать и распределять ресурсы между пользователями), чтобы повысить производительность 1С:Предприятие 8 в ряде случаев.

22.04.2015    39958    0    Gilev.Vyacheslav    1    

Улучшение пооперационного планирования в 1С:ERP 2.4 внешними средствами

Математика и алгоритмы Производительность и оптимизация (HighLoad) Бесплатно (free)

Задача построения оптимального производственного расписания требует сравнения тысяч и десятков тысяч вариантов. Выполнять такие вычисления средствами платформы 1С Предприятие нецелесообразно. Как реализовать пооперационное планирование с использованием генетических алгоритмов и параллельных вычислений в докладе на конференции Infostart Event 2019 Inception рассказал генеральный директор компании «ИНТЕХ» Сергей Сафаров.

02.03.2020    4324    0    ildarovich    7    

Делаем быстрее POSTGRESQL COUNT (*)

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Laurenz Albe "POSTGRESQL COUNT(*) MADE FAST". Оригинал доступен по ссылке https://www.cybertec-postgresql.com/en/postgresql-count-made-fast/

28.02.2020    2163    0    w.r.    1    

Повышенная нагрузка на диски сервера баз данных SQL Server Промо

Производительность и оптимизация (HighLoad) Бесплатно (free)

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

15.03.2015    39246    0    gallam99    17    

Простое обнаружение проблем производительности в PostgreSQL

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Hans-Jürgen Schönig "DETECTING PERFORMANCE PROBLEMS EASILY IN POSTGRESQL". Оригинал доступен по ссылке https://www.cybertec-postgresql.com/en/detecting-performance-problems-easily-in-postgresql/ Актуально для всех 1С ников, перешедших с MS SQL на Postgres

20.02.2020    3472    0    w.r.    4    

Планы запросов - это просто! Разбор оптимизаций запросов PostgreSQL на живых примерах

Производительность и оптимизация (HighLoad) v8::Запросы Бесплатно (free)

Проблема быстродействия 1С напрямую зависит от производительности запросов. Но как понять механику работы СУБД с помощью плана запроса? Андрей Овсянкин и Никита Грызлов на конференции Infostart Event 2019 Inception подробно рассмотрели алгоритм работы с планом запроса СУБД PostgreSQL, полученным из технологического журнала, и рассказали, на что обратить внимание, чтобы оптимизировать работу системы.

17.02.2020    7920    0    Evil Beaver    13    

Держи данные в тепле, транзакции в холоде, а VACUUM в голоде

Производительность и оптимизация (HighLoad) Бесплатно (free)

Чтобы база работала быстро – в ней нужен порядок. Это касается как MS SQL, так и PostgreSQL. Как настроить базу, чтобы в ней поддерживался порядок, какие регламентные операции нужно проводить, чтобы данные чистились, индексы перестраивались и оперативная память высвобождалась в своём выступлении на конференции Infostart Event 2019 Inception поделился руководитель ИТ в компании «ИнфоСофт» Антон Дорошкевич. 

07.02.2020    8638    0    a.doroshkevich    17    

Как можно "положить" SQL сервер с помощью обычной консоли запросов 1С Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Описано как из 1С, с помощью безобидной на первый взгляд обработки, можно сделать неработоспособным SQL сервер. Предложены меры, позволяющие избежать этого.

22.01.2014    66353    0    yuraos    112    

Оптимизатор запросов. Вторая часть

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Продолжение статьи об оптимизаторе запросов. Во второй части мы попробуем создать свой оптимизатор и попутно разберемся с такими вопросами, как: хранение файлов; индексы; статистика.

23.01.2020    5775    0    darkdan77    59    

Улучшаем производительность 1С. Рекомендации

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

Каждый уважаемый разработчик 1С сталкивался или столкнется с вопросом производительности высоконагруженных систем. В статье агрегирован основной набор рекомендаций, который позволит повысить производительность системы. Эти рекомендации должны быть просто must have по определению.

23.01.2020    7056    0    Kaval88    26    

Атака сервера кнопонажималкой

Нагрузочное тестирование Инструментарий разработчика Бесплатно (free)

Чтобы убедиться, что продукт выдержит планируемую нагрузку, необходимо провести нагрузочное тестирование – написать сценарии пользовательских действий и запустить их в несколько потоков, чтобы заранее найти проблемы в бизнес-логике и «узкие места». О том, как упростить написание сценариев тестирования для конфигурации Тест-центр с помощью фреймворка Vanessa Automation на конференции Infostart Event 2019 Inception рассказал ведущий программист компании «ПервыйБИТ» Никита Грызлов.

20.01.2020    5325    0    nixel    22    

Ускоряем списание партий УПП 1.2 / 1.3 / УТ 10.3 Промо

Производительность и оптимизация (HighLoad) v8 УТ10 УПП1 Бесплатно (free)

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

21.06.2013    53140    0    Антон Ширяев    116    

Мониторим производительность с помощью 1С RAS

Инструментарий разработчика Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Подключаемся и анализируем данные через 1С RAS. Необходимо выполнить 5 пунктов и серьезный инструмент мониторинга будет у вас в руках.

19.12.2019    9786    0    ivanov660    16    

История роста и работы команд 1С в условиях HighLoad и BigData

Автоматизация ИТ-компании Производительность и оптимизация (HighLoad) Бесплатно (free)

Современные потребности бизнеса заставляют программистов 1С решать все более сложные задачи. А главные требования, которым необходимо соответствовать, – вовремя поставлять ценности высокого качества. С какими сложностями приходится сталкиваться в работе программистам в динамично развивающейся брокерской сфере, и как их решают, на конференции Infostart Event 2018 Education рассказал начальник отдела интеграции БКС Технологии Сергей Артемов.

11.11.2019    6827    0    user826155    11    

Весёлые картинки о работе Performance Monitor на Windows Server 2016 Std по мотивам расследования потери производительности на базе 1С

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Данная публикация посвящена одной особенности Performance Monitor на Windows Server 2016 Std. Как понимать графики Performance Monitor на Windows Server 2016 Std при расследовании проблем в работе 1С.

22.10.2019    6847    0    EugeneSemyonov    11    

Сравнение скорости работы 1C+MSSQL и файлового варианта Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

На форумах постоянно задается один и тот же вопрос: почему 1C+MSSQL медленнее обрабатывает запросы чем файловая? Затем обычно идет «флуд» на несколько десятков страниц. Есть два популярных «течения» в таких форумах — одни говорят что для клиент-серверного варианта это нормально, файловый вариант всегда должен работать быстрее, другие говорят что 1С плохо работает с субд. В результате «баталий и выяснения отношений» на форумах люди расходятся при своих мнения.

19.02.2013    53808    0    Gilev.Vyacheslav    46    

Обслуживание баз данных. Не так просто, как кажется

Производительность и оптимизация (HighLoad) Администрирование СУБД v8 1cv8.cf Бесплатно (free)

Считаете, что обслуживание индексов и статистик дело простое? Что ж, это не всегда так.

14.10.2019    16250    0    YPermitin    28    

Набор скриптов для знакомства с SQL Server

Производительность и оптимизация (HighLoad) Администрирование СУБД Бесплатно (free)

Поговорим о скриптах, которые помогут быстро ознакомиться с состоянием SQL Server, в том числе с вопросами производительности.

30.09.2019    20548    0    YPermitin    14    

Мониторинг высоконагруженной системы

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Высоконагруженной системе (более 8000 клиентских сессий) мониторинг необходим. Про опыт использования инструментов для мониторинга – самописной системы информирования, написанной на C#, и конфигурации «Центр контроля качества» в связке с системой отображения данных Grafana, на конференции Infostart Event 2018 Education рассказал Олег Репников.

13.09.2019    8415    0    Repich    5    

Параллельные вычисления в 1С 8 Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Решение позволяет ускорять выполнение запросов в 1С 8 в отчетах путем их параллельного выполнения в разных потоках.

11.02.2013    29562    0    gallam99    19    

Использование Zabbix для сбора информации о серверных вызовах и управляемых блокировках с сервера 1С Предприятия, работающего на платформе GNU/Linux

Администрирование данных 1С Zabbix v8 Бесплатно (free)

Описанные в данном опусе механизмы ни в коей мере не противопоставляются тому, что реализует КИП от 1С или какие-либо другие инструменты (решения)! Это всего лишь еще один взгляд на "проблему", который может быть полезен в некоторых ситуациях.

10.09.2019    17313    0    Sloth    24    

Подбор оборудования для информационных систем на платформе 1С

Интеграция Производительность и оптимизация (HighLoad) Бесплатно (free)

При подборе оборудования по рекомендациям с сайта ИТС возникает противоречие: проводить ли нагрузочные тесты, чтобы определить возможную нагрузку, или достаточно просто взять данные из таблиц статистики? О том, какую тактику применить в том или ином случае, на конференции INFOSTART EVENT 2018 Education рассказал начальник отдела разработки компании IBS Филиппов Евгений.

09.09.2019    8528    0    jf2000    8    

Руководство по SQL: Как лучше писать запросы (Часть 2)

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию продолжение перевода статьи Karlijn Willems SQL Tutorial: How To Write Better Queries". Оригинал доступен по ссылке https://www.datacamp.com/community/tutorials/sql-tutorial-query. Первая часть доступна по ссылке https://infostart.ru/public/1115809/

03.09.2019    7070    0    w.r.    2    

Ubuntu vs CentOS vs Win2k8 vs Debian: производительность PostgreSQL Промо

Статистика базы данных Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Хотя интернет уже переполнен статьями о "правильной" настройке связки PostgreSQL и 1C 8.2, для подводных камней всегда остается место. При сравнении производительности СУБД PostgreSQL на разных ОС, показатели различаются в разы. Самую большую обиду принесла любимая Ubuntu (человечность). После долгих дней и ночей проведенных за консолью этой ОС, она разочаровала окончательно. Тормоза PostgreSQL в Ubuntu Server. Что с ними делать? Сколько раз можно наступать на грабли?

03.11.2012    41767    0    madmpro    32    

Анализ производительности APDEX

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Отчет для просмотра и анализа замеров производительности в конфигурациях на базе БСП.

31.08.2019    9707    2    YPermitin    7    

Руководство по SQL: Как лучше писать запросы (Часть 1)

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Karlijn Willems SQL Tutorial: How To Write Better Queries". Оригинал доступен по ссылке https://www.datacamp.com/community/tutorials/sql-tutorial-query. Узнайте о антипаттернах, планах выполнения, time complexity, настройке запросов и оптимизации в SQL.

30.08.2019    10113    0    w.r.    19    

Использование Union вместо OR

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Derek Dieter "Using Union Instead of OR". Оригинал доступен по ссылке http://sqlserverplanet.com/optimization/using-union-instead-of-or.

22.08.2019    3719    0    w.r.    35    

Тюнинг производительности запросов в PostgreSQL

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Brady Holt "Performance Tuning Queries in PostgreSQL ". Оригинал доступен по ссылке https://www.geekytidbits.com/performance-tuning-postgres/

31.07.2019    7055    0    w.r.    5    

Неочевидные проблемы производительности: важность системного подхода при анализе

Производительность и оптимизация (HighLoad) v8 Россия Бесплатно (free)

Часто программисты и 1С-ники сталкиваются с совершенно необъяснимыми на первый взгляд проблемами. Но это потому, что их внимание направлено только на один сегмент системы, а не на всю систему полностью. О том, почему нужно стараться смотреть на ситуацию комплексно, рассказал специалист по производительности компании SOFTPOINT Александр Денисов.

19.07.2019    8397    0    Филин    12    

Ловля блокировок на связке "Microsoft SQL server - 1С"

Производительность и оптимизация (HighLoad) v8 v8::blocking Бесплатно (free)

Материал относится к базам данных на связке «1С - MS SQL Server». Один из способов отлова блокировок в бд 1С . Переход к управляемым блокировкам через режим "Автоматический и управляемый".

16.07.2019    9014    0    fhqhelp    0    

Настройка параметров PostgreSQL для оптимизации производительности

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Ibrar Ahmed "Tuning PostgreSQL Database Parameters to Optimize Performance". Оригинал доступен по ссылке https://www.percona.com/blog/2018/08/31/tuning-postgresql-database-parameters-to-optimize-performance/

08.07.2019    6538    0    w.r.    19    

Сравнительное тестирование работы PostgreSQL с большими страницами Linux

Производительность и оптимизация (HighLoad) Бесплатно (free)

Представляю вашему вниманию перевод статьи Ibrar Ahmed "Benchmark PostgreSQL With Linux HugePages". Оригинал расположен по ссылке https://www.percona.com/blog/2018/12/20/benchmark-postgresql-with-linux-hugepages/

05.07.2019    4383    0    w.r.    6    

Настройка параметров ядра Linux для оптимизации PostgreSQL

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Ibrar Ahmed "Tune Linux Kernel Parameters For PostgreSQL Optimization". Оригинал доступен по ссылке https://www.percona.com/blog/2018/08/29/tune-linux-kernel-parameters-for-postgresql-optimization/

05.07.2019    5181    0    w.r.    1    

Анти-оптимизация: как мы ускорили запрос в 4 раза, сделав его неоптимальным

Производительность и оптимизация (HighLoad) Практика программирования Решение задач на 1С:Специалист Разработка v8 Бесплатно (free)

В этой статье приведен пример неочевидной "оптимизации" запроса, которая противоречит всем правилам, описанным в книгах для подготовки к сертификации "1С:Эксперт по технологическим вопросам", а также преподаваемым на курсах подготовки экспертов.

02.07.2019    10508    0    igordynets    119