Bug 5798

Summary:	Низкая скорость работы 1С с регистрами в многопользовательском режиме
Product:	WINE@Etersoft	Reporter:	Shestakov Dmitriy <mid>
Component:	Общее	Assignee:	Александр Морозов <amorozov>
Status:	CLOSED LATER	QA Contact:	Svetlana Zhukova <svzhu>
Severity:	blocker
Priority:	P1	CC:	bahalyan, baraka, khvalera, lav, piastry, svzhu
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	All
Whiteboard:
Заявки RT:	15211,23063	Связано с:	7350
Дата напоминания:
Bug Depends on:
Bug Blocks:	5906, 7052
Attachments:	обработка, которой измерялась производительность. Лог strace Регистр.СводныйОстаток в монопольном режиме

Description Shestakov Dmitriy 2010-07-21 17:04:35 MSD

1С 7.7 
Большие задержки при обращении к сводным остаткам.

Comment 1 Shestakov Dmitriy 2010-07-21 17:05:54 MSD

Не зависит от дистрибутива линуха(тестировалось на fedora, suse, ubuntu)
Протестировано на ТиС 7.70.963, типовая конфигурация, без каких-либо допиливаний.
Тестовая машина: Intel Core 2 Quad q9450 (2.66 Ghz)
                 RAM 4 Gb
                 Скорость записи на диск ~200Mb/s.

Использовались 2-е базы:
  demoDB - демо-база от 1с
  testDB - действующая база с ~200 контрагентами.

использовалась обработка tets.ert, которую прислал клиент(смотреть во вложении):
Результаты:

linux demoDB
монопольный режим
Общее время 38
Среднее время получения долга по клиенту 0.86363636363636363636
Общее время 38
Среднее время получения долга по клиенту 0.86363636363636363636
Общее время 45
Среднее время получения долга по клиенту 1.02272727272727272727


linux demoDB
сетевой режим
Общее время 483
Среднее время получения долга по клиенту 10.97727272727272727273
Общее время 451
Среднее время получения долга по клиенту 10.25
Общее время 555
Среднее время получения долга по клиенту 12.61363636363636363636


linux testDB
монопольно
Общее время 5535
Среднее время получения долга по клиенту 6.4585764294049008168
Общее время 5507
Среднее время получения долга по клиенту 6.42590431738623103851
Общее время 5528
Среднее время получения долга по клиенту 6.45040840140023337223

linux testDB
сетевой режим
Общее время 164102
Среднее время получения долга по клиенту 191.48424737456242707118
Общее время 164244
Среднее время получения долга по клиенту 191.64994165694282380397


windows testDB
монопольно
Общее время 7364
Среднее время получения долга по клиенту 8.59276546091015169195
Общее время 7363
Среднее время получения долга по клиенту 8.5915985997666277713
Общее время 7358
Среднее время получения долга по клиенту 8.58576429404900816803


windows testDB
сетевой режим
Общее время 21611
Среднее время получения долга по клиенту 25.21703617269544924154
Общее время 21786
Среднее время получения долга по клиенту 25.42123687281213535589
Общее время 21598
Среднее время получения долга по клиенту 25.20186697782963827305

windows demoDB
монопольно
Общее время 61
Среднее время получения долга по клиенту 1.38636363636363636364
Общее время 61
Среднее время получения долга по клиенту 1.38636363636363636364
Общее время 60
Среднее время получения долга по клиенту 1.36363636363636363636


windows demoDB
сетевой режим
Общее время 118
Среднее время получения долга по клиенту 2.68181818181818181818
Общее время 119
Среднее время получения долга по клиенту 2.70454545454545454545
Общее время 119
Среднее время получения долга по клиенту 2.70454545454545454545

"очевидно, что во всех конфах, где активно идет обращение к сводным
остаткам (определение остатков товара, долгов, резервов номенклатуры..)
- под wine@etersoft тормоза будут тем большими, чем чаще сводные остатки
считаются.."

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

Comment 2 Alexandr 2010-07-21 19:10:55 MSD

(In reply to comment #0)
> 1С 7.7 
> Большие задержки при обращении к сводным
> остаткам.
> 
Я бы пожалуй выставил уровень серьезности "Серьезная" - по сути, все конфы работающие с компонентой Оперативный Учет (Комплексная, ТиС, ПУБ.., не говоря о самописных - они почти все нацелены на создание подобия CRM на базе 1С с оперативным учетом) "благодаря" этому багу будут тормозить (особенно в "управленческих" отчетах, которыми пользуется РУКОВОДСТВО - которое в конечном итоге из-за тормозов может "зарубить" использование wine@etersoft в организации).

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

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

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

Comment 3 Shestakov Dmitriy 2010-08-09 14:29:51 MSD

Created attachment 1783 [details]
обработка, которой измерялась производительность.

Comment 4 Pavel Shilovsky 2010-09-08 11:08:35 MSD

Надо измерить производительность со сборками 4.5.1.3 и 4.5.1.4 из баги 5442.

Comment 5 Alexandr 2010-10-01 23:20:31 MSD

(In reply to comment #4)
> Надо измерить производительность со
> сборками 4.5.1.3 и 4.5.1.4 из баги 5442.
> 
Если речь о сборках etercifs - то первоначальное тестирование шло вообще без него, база используется в терминале без использования подключения по сети. Стоит etercifs или нет - результат один..

Comment 6 Alexandr 2010-10-01 23:46:30 MSD

(In reply to comment #0)
> 1С 7.7 
> Большие задержки при обращении к сводным
> остаткам.
> 
Порадовала гордая цифра в "проценте звершения" %)) Что, проблема решена?
Если имелось ввиду, что "раз зависит от бага 3031, то делать тут нечего, вот решим баг 3031.." - то простите, не согласен. 
В баге 3031 речь о том что "при вызове номенклатуры идет постоянный перерасчет итогов. На винде он выполняется секунд 5-9, а в wine секунд 30." - и ни слова про разницу в монопольном и сетевом режимах.. Хотя может подразумевается именно сетевой режим? А как база из бага 3031 ведет себя в монопольном?
Данный же баг - про НЕАДЕКВАТНУЮ разницу скорости работы в монопольном и многопользовательском вариантах под wine  по сравнению с виндами. Причем в МОНОПОЛЬНОМ расчет итогов регистров РАБОТАЕТ БЫСТРЕЕ чем в винде. Что означает что с реализацией функций-прокладок между wine  и linux (на что делается упор в баге 3031, насколько понял) все относительно хорошо.
А вот плохо - с системой блокировок, заставляющих выполняться те самые функции-прокладки многократно большее количество раз, по сравнению с аналогичным механизмом виндов.. 
Простите, если все это покажется вам мнением дилетанта. Я то свою базу переделал - в октябре контора переводится на линух. Но кое-какие тормоза все равно остались, надеюсь что все таки данный баг найдет решение, а не будет положен "на полочку".
К слову - руководство готово поддержать разработчиков материально, если будет результат (вот только ответа на вопрос "сколько" я не знаю)..

Comment 7 Денис Баранов 2010-10-29 20:51:10 MSD

Уточнение баги, корректировка зависимостей.

Укороченная формулировка:
При работе в многопользовательском режиме идет очень долгое построение отчета.

to amorozov@:
Есть какие либо предположения почему такие задержки? Возможно ли это исправить? Сколько потребуется времени на оптимизацию?

Comment 8 Pavel Shilovsky 2010-10-29 22:12:46 MSD

Раз речь идёт о разнице при работе монопольного режима и многопользовательского, то данная проблема сходна с багой 3032. В баге 5442 были предложены прототипы (4.5.1.3, 4.5.1.4, 4.5.1.5, 4.5.1.6), для решения последней. Думаю, стоит попробовать их на данной проблеме.

baraka@, что скажешь?

Comment 9 Денис Баранов 2010-10-30 12:21:35 MSD

(In reply to comment #8)
> Раз речь идёт о разнице при работе монопольного режима и
> многопользовательского, то данная проблема сходна с багой 3032. В баге
> 5442 были предложены прототипы (4.5.1.3, 4.5.1.4, 4.5.1.5, 4.5.1.6), для решения
> последней. Думаю, стоит попробовать их на данной проблеме.

Я думаю сначала стоит решить проблему без использования CIFS, т.к. в  Комментарий #5 написано что изначально тестирование шло без CIFS'а.
Сначала попытаемся решить проблемы без CIFS, а потом посмотрим что изменится при использовании etercifs.

Comment 10 Alexandr 2010-11-23 13:19:54 MSK

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

На моей рабочей базе эти действия дали уменьшение среднего времени получения долга клиента с 1100-1600 тиков до 180-230. В монопольном режиме - с 73-76 тиков до 7-8..

Минус - если база большая, пересчет итогов может идти очень долго.. Моя база объемом 2Gb не пересчиталась даже за 2,5 дня (с вечера пятницы по утро понедельника). В этом случае выход - создание чистой базы, установка в ней всех действий пунктов а) и б), перенос в нее всех документов из рабочей базы (у меня самописная обработка переноса OLE, но таких в сети валяется много.. Лишь бы работали правильно:)) ) После переноса - пункт в), делается довольно быстро, в течение дня на моей базе..

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

2. Относительно решения проблемы.
Я тут попробовал wine подсунуть через LD_PRELOAD библиотеку пустышку с функциями fsync(), sync(), fdatasync() - и убедился что вроде как эти фунции не используются. Из чего вывод - скорее всего диски wine монтирует в режиме "sync". Это оправдано, если диск подключается сетевой, Но в случае монтирования локального диска (что и происходит в терминальном режиме работы) - совсем не хорошо.
МОЖЕТЕ ЛИ СДЕЛАТЬ СБОРКУ С ВОЗМОЖНОСТЬЮ ВЫБОРА ОПЦИЙ МОНТИРОВАНИЯ ПРИ КОНФИГУРИВОВАНИИ ДИСКОВ? - в частности "sync", "nosync" (ну и "noatime" тож неплохо бы..)
Думаю, в режиме "nosync" монтирования диска с базами результаты тестирования будут гораздо лучше. При этом риск только один - вырубание электричества при отсутствии ИБП или авральный ребут - частичная потеря информации. Блокировки тож по идее будут работать нормально. Пусть пользователь сам выберет вариант монтирования - скорость или супернадежность..

Comment 11 Александр Морозов 2010-11-23 22:26:39 MSK

> МОЖЕТЕ ЛИ СДЕЛАТЬ СБОРКУ С ВОЗМОЖНОСТЬЮ ВЫБОРА ОПЦИЙ МОНТИРОВАНИЯ ПРИ
> КОНФИГУРИВОВАНИИ ДИСКОВ? - в частности "sync", "nosync" (ну и "noatime" тож
> неплохо бы..)
WINE сам ничего не монтирует.

Comment 12 Alexandr 2010-11-25 06:12:45 MSK

(В ответ на comment #11)
> WINE сам ничего не монтирует.
Понял)
Я тут решил через strace процесса wineserver посмотреть что происходит в монопольном и немонопольном режимах (считал каждого 400-го контрагента, чтобы 
быстрее):
Монопольно
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 87.85    0.005917           0     44665         1 epoll_wait
  4.75    0.000320           0     31711           write
  3.10    0.000209           0     44666           gettimeofday
  2.79    0.000188           0     45954           read
  1.25    0.000084           0     11948           writev
  0.18    0.000012           0       681        29 close
  0.07    0.000005           0        70           time
Немонопольно
 69.97    0.039689           0    658688           epoll_wait
 14.93    0.008470           0    636831           write
  5.33    0.003025           0    586490           fcntl64
  4.99    0.002832           0    659503           read
  4.38    0.002483           0    658690           gettimeofday
  0.36    0.000207           0     20332           writev
  0.03    0.000015           0        37         1 statfs

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

ТекстФайл=СоздатьОбъект("Текст");
ТекстФайл.КодоваяСтраница(0); 
ТекстФайл.ДобавитьСтроку("Start");
ТекстФайл.Записать("G:\123.txt");

Рез1    = РабРегПоставщики.СводныйОстаток(, ТекЭлДоговора, , , "СуммаВал");
			 
ТекстФайл=СоздатьОбъект("Текст");
ТекстФайл.КодоваяСтраница(0); 
ТекстФайл.ДобавитьСтроку("End");
ТекстФайл.Записать("G:\321.txt");

Дальше поиском в логе strace искал имена файлов, и все что между ними (между close(дескриптор 123.txt) и open(321.txt) )- ет собственно и то, что относится к РабРегПоставщики.СводныйОстаток..

Лог в монопольном режиме - это m.txt, Немонопольном - n.txt. 
Стал сравнивать, и выяснилось что логи отличаются началом (если не считать разницу в номерах файловых дескрипторов и отличие параметров epoll_wait). 
В файле r.txt - разница логов. 
Грубо говоря, лог немонопольного режима n.txt = r.txt + m.txt.
Обратите внимание на размеры логов..

Таким образом, если проанализировать содержание r.txt, то возмозможно появятся у Вас светлые мысли по поводу причин столь большой разницы работы с регистрами в монопольном и немонопольном режимах.. Бог в помощь.
P/S. Если решите перепроверять - рекомендую сравнивать файлы с конца - быстрее будет..))

Comment 13 Alexandr 2010-11-25 06:15:15 MSK

Created attachment 1965 [details]
Лог strace Регистр.СводныйОстаток в монопольном режиме

Comment 14 Alexandr 2010-11-25 06:21:30 MSK

Логи Немонопольного режима и Разницы логов загрузить не получилось - слишком большие - 7,65 и 7,63 Мб соответственно. Отправил все 3 лога на почту amorozov@etersoft.ru. Авось пройдет.

Comment 16 Денис Баранов 2011-02-16 17:32:43 MSK

*** Bug 6911 has been marked as a duplicate of this bug. ***

Comment 17 khvalera 2011-03-11 15:18:59 MSK

Исправить данную проблему, вобще попытки какие то делаются?!

Comment 18 Александр Морозов 2011-03-11 15:42:13 MSK

> Исправить данную проблему, вобще попытки какие то делаются?!
Она ждёт своей очереди.

Comment 19 Александр Морозов 2011-03-11 21:23:16 MSK

Сравнил количество вызовов некоторых функций при выполнении тестовой обработки в монопольном и немонопольном режиме под wine. Использовалась база из /var/ftp/pvt/Windows/1C/1Cv77_configs/TIS2006.tar.bz2 (Торговля + Склад, редакция 9.2. Оптово-розничная конфигурация).

            монопольно  немонопольно
CreateFile  657         657
WriteFile   102         100
ReadFile    9313        2951648
LockFile    18          2950319

Посмотрел, для каких файлов больше всего вызывается ReadFile.
Монопольно
     62 C:\\TIS2006\\SC2875.CDX
     69 C:\\TIS2006\\SC172.CDX
    130 C:\\TIS2006\\SC204.CDX
   1249 C:\\TIS2006\\SC172.DBF
   2000 C:\\TIS2006\\SC204.DBF
Немонопольно
   5675 C:\\TIS2006\\SC204.DBF
   5803 C:\\TIS2006\\SC204.CDX
   8865 C:\\TIS2006\\1SSYSTEM.DBF
1459263 C:\\TIS2006\\RG4314.DBF
1463711 C:\\TIS2006\\RG4314.CDX

А также для каких файлов больше всего вызвается LockFile в немонопольном режиме:
   2540 C:\\TIS2006\\SC172.DBF
   8862 C:\\TIS2006\\1SSYSTEM.DBF
  11346 C:\\TIS2006\\SC204.DBF
2927364 C:\\TIS2006\\RG4314.DBF

Comment 20 Александр Морозов 2011-03-16 16:49:16 MSK

На WinXP распределение вызовов ReadFile и LockFile по файлам точно такое же:

$ grep -o 'ReadFile([[:alnum:]]*' winxp_file.log | sort | uniq -c | sort -n | tail                             
     62 ReadFile(25c
     62 ReadFile(294
     72 ReadFile(19c
   1280 ReadFile(250
   1339 ReadFile(254
   5675 ReadFile(218
   5803 ReadFile(21c
   8865 ReadFile(178
1459263 ReadFile(8f4
1463711 ReadFile(8f8

$ grep -o 'LockFile([[:alnum:]]*' winxp_file.log | sort | uniq -c | sort -n | tail
      3 LockFile(ac
      4 LockFile(288
      6 LockFile(994
     10 LockFile(1a4
     14 LockFile(c
     62 LockFile(19c
   2540 LockFile(250
   8862 LockFile(178
  11346 LockFile(218
2927364 LockFile(8f4

Comment 21 Александр Морозов 2011-03-16 17:58:43 MSK

valgrind --trace-children=yes --tool=callgrind в случае с wine, к сожалению, падает

Comment 22 Александр Морозов 2011-03-16 21:45:58 MSK

Если сделать, чтобы функции LockFile и UnlockFile ничего не делали для файлов с дескриптором больше 0x100, то время выполнения обработки сокращается приблизительно в десять раз.

Измерил скорость работы блокировок на Windows и Linux с помощью тестовых программ, устанавливающих и снимающих блокировку на первые 16 байт файла 1000000 раз (locks/lockperf в wine-etersoft-devel):
Windows  ~1,4 с
WINE     ~37 с
Linux    ~1,9 с

Comment 23 Александр Морозов 2011-03-17 16:34:49 MSK

> WINE     ~37 с
Если закомментировать обработчики lock_file и unlock_file в wineserver, то время выполнения теста сокращается до ~29 с. По-видимому, большая часть времени тратится на запрос к wineserver.

Comment 24 Александр Морозов 2011-03-17 18:14:07 MSK

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

Comment 25 Pavel Shilovsky 2011-03-17 18:18:11 MSK

(В ответ на comment #24)
> Думаю, работу с блокировками можно ускорить, если вынести их установку из
> wineserver в ntdll. Но это заметная переделка, потом могут быть сложности с
> применением изменений из апстрима.

А если попробовать обсудить проблему в апстрим и согласовать с ними эту переделку? Возможно идея найдёт отклик, и нам помогут с реализацией.

Comment 26 Александр Морозов 2011-03-24 21:57:03 MSK

> А если попробовать обсудить проблему в апстрим и согласовать с ними эту
> переделку? Возможно идея найдёт отклик, и нам помогут с реализацией.
Маловероятно. Думаю, чтобы протолкнуть такое глубинное изменение, нужны веские причины.

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

Comment 27 Pavel Shilovsky 2011-03-25 11:46:59 MSK

(В ответ на comment #26)
> > А если попробовать обсудить проблему в апстрим и согласовать с ними эту
> > переделку? Возможно идея найдёт отклик, и нам помогут с реализацией.
> Маловероятно. Думаю, чтобы протолкнуть такое глубинное изменение, нужны веские
> причины.
> 
> Сейчас думаю в сторону параллельной реализации в закрытой части без переделки
> wineserver. Функции установки/снятия блокировок можно вызывать из
> NtLockFile/NtUnlockFile. Для wineserver установленные таким образом блокировки
> будут выглядеть как поставленные внешним процессом, но это вроде бы не должно
> вызвать каких-либо проблем.

Обсудили с amorozov@ данное изменение с точки зрения работы CIFS, так как в таком случае придётся менять логику работы модуля, а так же возникнет проблема с потерей блокировки после печати на принтере. Проблема требует более детального рассмотрения.

Comment 28 Александр Морозов 2011-04-07 21:27:18 MSK

Пока не видно способа реализовать перенос установки блокировок из wineserver в процесс запущенной под WINE программы.
При использовании etercifs чтение выполняется с использованием pid процесса, открывшего файл. Открывает файл wineserver. Если мы поставим блокировку не из wineserver, то мы не сможем читать/писать (блокировки mandatory). Если реализовать в etercifs хак, чтобы при установке блокировки на дескриптор любым процессом получалось так, будто эту блокировку поставил процесс, открывший файл, то в качестве побочного эффекта при закрытии файла будут сбрасываться все блокировки. Проблема в том, что файл может быть закрыт при завершении какой-нибудь дочерней утилиты, например, при печати.

Comment 29 Alexandr 2011-04-08 14:11:18 MSK

(В ответ на comment #28)
> Пока не видно способа реализовать перенос установки блокировок из wineserver в
> процесс запущенной под WINE программы.
> При использовании etercifs чтение выполняется с использованием pid процесса,
> открывшего файл. Открывает файл wineserver. Если мы поставим блокировку не из
> wineserver, то мы не сможем читать/писать (блокировки mandatory). Если
> реализовать в etercifs хак, чтобы при установке блокировки на дескриптор любым
> процессом получалось так, будто эту блокировку поставил процесс, открывший
> файл, то в качестве побочного эффекта при закрытии файла будут сбрасываться все
> блокировки. Проблема в том, что файл может быть закрыт при завершении
> какой-нибудь дочерней утилиты, например, при печати.

Вам конечно виднее по статистике покупки лицензий, но по моему в большинстве случаев связка 1С+Linux+wine@etersoft реализуется в терминальном режиме. А в терминальном режиме etrcifs не нужен.
Сделайте тестовую сборку, решающую проблему в терминальном режиме (с оговоркой-предупреждением о невозможности использования etercifs) - и мы Вам скажем спасибо и протестируем.
Как вариант в дальнейшем можно просто под терминальное решение делать отдельную сборку. Ведь лицензии у вас отличаются..

Comment 30 khvalera 2011-04-15 17:42:48 MSK

...полностью согласен с Alexandr!

Comment 31 Александр Морозов 2011-04-27 23:13:59 MSK

Начал реализовывать механизм для установки блокировок не в wineserver для файлов, расположенных на NFS и локальных ФС.

Comment 32 Alexandr 2011-04-28 12:43:58 MSK

(В ответ на comment #31)
> Начал реализовывать механизм для установки блокировок не в wineserver для
> файлов, расположенных на NFS и локальных ФС.

БОГ в помощь))) я уж думал до конца года трабла останется.. Ждемс..)))

Comment 33 Александр Морозов 2011-04-28 21:40:46 MSK

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

Comment 34 Александр Морозов 2011-04-29 21:07:30 MSK

Поведение блокировок в Linux и Windows отлчается в плане пересечения и снятия, так что просто вызывать fcntl в лоб нельзя. В Windows эксклюзивные блокировки не могут пересекаться, даже если они устанавливаются одним процессом, сниматься блокировка должна с тем же смещением и длиной, нельзя поставить большую блокировку, а потом выключить кусочек в середине.

Comment 35 Александр Морозов 2011-05-03 20:17:03 MSK

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

Comment 36 Александр Морозов 2011-05-04 21:20:07 MSK

Занимался реализацией снятия блокировок в случае, если у нас стоят пересекающиеся блокировки.

Comment 37 Александр Морозов 2011-05-05 21:49:37 MSK

Занимался данным багом.

Comment 38 khvalera 2011-05-06 14:18:00 MSK

Читал комментарии о проделанной работе, но так и не понял, есть шанс все таки победить баг или нет?

Comment 39 Александр Морозов 2011-05-10 16:04:48 MSK

> Читал комментарии о проделанной работе, но так и не понял, есть шанс все таки
> победить баг или нет?
Баг будет решён для NFS и локальных ФС.

Comment 40 Александр Морозов 2011-05-10 21:54:50 MSK

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

Comment 41 khvalera 2011-05-11 13:16:12 MSK

(В ответ на comment #39)
> > Читал комментарии о проделанной работе, но так и не понял, есть шанс все таки
> > победить баг или нет?
> Баг будет решён для NFS и локальных ФС.

...это замечательно, большего для решения моей проблемы и не нужно!

Comment 42 Александр Морозов 2011-05-11 21:32:51 MSK

Для более быстрого доступа к дескрипторам можно использовать две хеш-таблицы: в одной ключом будет хэндл, в другой - dev_t и ino_t файла. Вторая будет использоваться при проверке пересечений блокировок для файла и при закрытии хэндла (если это последний хэндл для файла - всё освобождаем). В качестве хеш-таблицы можно использовать вот это: http://www.pomakis.com/hashtable/ (public domain). Можно было бы использовать стандартные функции hcreate/hsearch, но там в качестве ключа используется строка, что нам не подходит.

Comment 43 Александр Морозов 2011-05-12 21:59:39 MSK

Занимался данным багом.

Comment 44 Александр Морозов 2011-05-13 19:57:14 MSK

Закоммитил изменения в закрытую часть. Отправил патчи для открытой части в рассылку.

Comment 45 Александр Морозов 2011-05-13 20:00:01 MSK

Результаты выполнения тестовой обработки на расположенной локально базе "Торговля + Склад, редакция 9.2. Оптово-розничная конфигурация" (/var/ftp/pvt/Windows/1C/1Cv77_configs/TIS2006.tar.bz2)

1.0.12-eter8/18, монопольно
Общее время 5918
Среднее время получения долга по клиенту 4.73061550759392486011

1.0.12-eter8/18, немонопольно
Общее время 158131
Среднее время получения долга по клиенту 126.40367705835331734612

1.0.12 с последними патчами, немонопольно
Общее время 27704
Среднее время получения долга по клиенту 22.14548361310951239009

Comment 46 Alexandr 2011-05-16 15:18:27 MSK

(В ответ на comment #45)
> Результаты выполнения тестовой обработки на расположенной локально базе
> "Торговля + Склад, редакция 9.2. Оптово-розничная конфигурация"
> (/var/ftp/pvt/Windows/1C/1Cv77_configs/TIS2006.tar.bz2)
> 
> 1.0.12-eter8/18, монопольно
> Общее время 5918
> Среднее время получения долга по клиенту 4.73061550759392486011
> 
> 1.0.12-eter8/18, немонопольно
> Общее время 158131
> Среднее время получения долга по клиенту 126.40367705835331734612
> 
> 1.0.12 с последними патчами, немонопольно
> Общее время 27704
> Среднее время получения долга по клиенту 22.14548361310951239009

СУПЕР! %)) Осталось выложить новую сборку - потестить..))

Comment 47 Pavel Shilovsky 2011-05-16 16:44:14 MSK

После обсуждения с amorozov@, появилась идея использовать такой режим и для cifs. Для этого надо убрать проброс пида  - то есть монтировать просто с forcemand  и strictcache, но без опции wine (для 4.8.1 сборки strictcache есть в 32,35,37 и 38 ядрах, для остальных использовать direct) - временная мера для тестирования.
Что следует проверить:
1) возможность приложения писать и читать из заблокированной им же самим области.
2) невозможность писать и читать из заблокированной другим процессом области.
3) невозможность установки блокировки из одного процесса на область заблокированную другим процессом - блокировки на запись. Возможность этого для блокировки на чтение.
4) 1С:
4.1) монитор пользователей, блокировка документа, одновременнная проводка.
4.2) открытие документа на запись и печать документа на принтере - после окончании печати документ всё ещё заблокирован, а после закрытия документа блокировка снимается успешно (проверка на то, что программа печати не влияет на блокировки установленные самой 1С).

Comment 48 Pavel Shilovsky 2011-05-16 16:47:37 MSK

Забыл добавить, что первый три пункта проверки нужно проводить так же из-под wine.

Comment 49 Александр Морозов 2011-05-16 21:02:30 MSK

Закомментировал проверку на ФС в закрытой части.
Написал утилиты для тестирования чтения и записи из заблокированной области: locks/linlock/linrw.c и locks/winlock/rwlock.c. Также использовал locks/linlock/linlock.c и locks/winlock/winlock.c для установки блокировок. Все утилиты лежат в репозитории wine-etersoft-devel.

etercifs-4.8.1, 2.6.38-std-def-alt2
mount -o user=guest,rw,iocharset=utf8,noperm,strictcache,forcemand //winxp/Rarus /mnt/cifs
Для Linux-программ все тесты проходят.
Для Windows-программ результаты такие:
1) чтение из заблокированной области не проходит, запись работает;
2) чтение и запись в область, на которой стоит эксклюзивная блокировка, проходят;
3) любые блокировки ставятся несколькими процессами одновременно.

Comment 50 Александр Морозов 2011-05-16 21:40:27 MSK

> 1) чтение из заблокированной области не проходит
Посмотрел, что происходит в этом случае: read возвращает EACCES.
Возможно, это связано с тем, что открытие файла происходит не в том процессе, который читает.

Comment 51 Vitaly Lipatov 2011-05-17 12:01:33 MSK

Мне кажется, стоит работы по CIFS вести в отдельной баге. А эту либо закрыть, либо проставить оставшееся время.

Comment 52 Pavel Shilovsky 2011-05-17 15:35:46 MSK

По CIFS создал отдельную багу: http://bugs.etersoft.ru/show_bug.cgi?id=7302. Здесь выставляю решено.

Comment 53 khvalera 2011-05-18 01:36:17 MSK

... Супер! Теперь расскажите как можно протестировать то что сделано? На персональной страничке заказать тестовую сборку?

Comment 54 Александр Морозов 2011-05-18 14:12:21 MSK

> ... Супер! Теперь расскажите как можно протестировать то что сделано? На
> персональной страничке заказать тестовую сборку?

Открытая часть 1.0.12-alt11.2, закрытая часть следующая после 1.0.12-alt19. При заказе тестовой сборки сейчас скорее всего соберётся 1.0.12-alt19, так что надо подождать, когда выйдет следующая версия закрытой части.

Comment 55 Александр Морозов 2011-05-18 14:12:37 MSK

> ... Супер! Теперь расскажите как можно протестировать то что сделано? На
> персональной страничке заказать тестовую сборку?

Открытая часть 1.0.12-alt11.2, закрытая часть следующая после 1.0.12-alt19. При заказе тестовой сборки сейчас скорее всего соберётся 1.0.12-alt19, так что надо подождать, когда выйдет следующая версия закрытой части.

Comment 56 Alexandr 2011-06-09 05:32:15 MSK

(В ответ на comment #55)
> > ... Супер! Теперь расскажите как можно протестировать то что сделано? На
> > персональной страничке заказать тестовую сборку?
> 
> Открытая часть 1.0.12-alt11.2, закрытая часть следующая после 1.0.12-alt19. При
> заказе тестовой сборки сейчас скорее всего соберётся 1.0.12-alt19, так что надо
> подождать, когда выйдет следующая версия закрытой части.

Скачал тестовую сборку eter21. Пока что о полном тестировании говорить рано. 
Но!
БОЛЬШОЕ СПАСИБО %) 
Не знаю как там двигаются дела по CIFS в баге 7302, но в плане скорости на локальных файловых системах (в варианте терминального сервера) - ПРОСТО СУПЕР! 
На моей бух базе (Комплексная конфа) - отношение НеМонопольно/Монопольно в районе 2. ЭТО ЛУЧШЕ аналогичного показателя под Windows! там 2,5 - 3
Причем абсолютные показатели также лучше Windows. 

Господин Александр Морозов - YOU ARE THE BEST! Это от души)

Comment 57 Александр Морозов 2011-06-14 15:21:46 MSK

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

1. Невозможно запустить две копии базы из под одного пользователя.
Запускаем 1С 7.7, выбираем любую базу, появляется окно "Авторизация доступа", оставляем базу в таком состоянии. Пытаемся запустить вторую копию базы, получаем окно "Общая файловая ошибка при доступе к c:\base\1Cv7.MD" Если в базу зайти ошибка остается т.е. 2 копии никак...

2. Монитор пользователей работает некорректно.
Запускаем 1С в режиме Монитора. Выводим список активных пользователей. Пользователи отображаются. Нажимаем кнопку обновить. Пользователи исчезают из списка. Для повторного вывода списка необходимо перезагрузить 1С. В режиме Предприятие Монитор ведет себя аналогично.

Comment 58 Александр Морозов 2011-06-14 21:13:46 MSK

Проблема вызвана использованием для блокировок специального дескриптора. Скорее всего, дело в том, что получается одно общее смещение для разных хэндлов. Откатил хак для бага #7350, т.к. теперь работает и без него.

Comment 59 Svetlana Zhukova 2011-08-11 12:02:25 MSK

ubuntu 11.04
WINE@Etersoft 1.0 Network 1.0.12-eter12/23
etercifs   4.8.0-eter1ubuntu    
samba   2:3.5.8~dfsg-1ubuntu2.3 
1с77 торговля и склад (демо)
обработка test.ert

в сетевом режиме:
Общее время 952
Среднее время получения долга по клиенту 24.41025641025641025641
Общее время 997
Среднее время получения долга по клиенту 25.56410256410256410256
Общее время 923
Среднее время получения долга по клиенту 23.66666666666666666667

в монопольном:

Общее время 20
Среднее время получения долга по клиенту 0.51282051282051282051
Общее время 14
Среднее время получения долга по клиенту 0.35897435897435897436
Общее время 15


если не использовать etercifs, то

в сетевом:
Общее время 17
Среднее время получения долга по клиенту 0.43589743589743589744
Общее время 17
Среднее время получения долга по клиенту 0.43589743589743589744
Общее время 16
Среднее время получения долга по клиенту 0.41025641025641025641


в монопольном:
Общее время 15
Среднее время получения долга по клиенту 0.38461538461538461538
Общее время 14
Среднее время получения долга по клиенту 0.35897435897435897436
Общее время 14
Среднее время получения долга по клиенту 0.35897435897435897436

Comment 60 Andrey Vusik 2011-08-23 12:54:13 MSK

Проверь пожалуйста https://bugs.etersoft.ru/show_bug.cgi?id=5798#c46

Comment 61 Svetlana Zhukova 2011-08-24 11:05:16 MSK

результаты описаны в http://bugs.etersoft.ru/show_bug.cgi?id=5798#c59
после слов "если не использовать etercifs, то" - тут проверялось на локальной базе.

Comment 62 Andrey Vusik 2011-08-24 11:07:27 MSK

(В ответ на comment #60)
> Проверь пожалуйста https://bugs.etersoft.ru/show_bug.cgi?id=5798#c46

Прошу прощения.
проверь http://bugs.etersoft.ru/show_bug.cgi?id=5798#c57

Comment 63 Svetlana Zhukova 2011-08-24 11:09:05 MSK

результаты описаны в http://bugs.etersoft.ru/show_bug.cgi?id=5798#c59
после слов "если не использовать etercifs, то" - тут проверялось на локальной базе.

Comment 64 Svetlana Zhukova 2011-08-24 11:35:33 MSK

бутылка wine@cellar bottle bugs/5798
WINE@Etersoft 1.0 SQL 1.0.12-eter12.1/23

> 1. Невозможно запустить две копии базы из под одного пользователя.
> Запускаем 1С 7.7, выбираем любую базу, появляется окно "Авторизация доступа",
> оставляем базу в таком состоянии. Пытаемся запустить вторую копию базы,
> получаем окно "Общая файловая ошибка при доступе к c:\base\1Cv7.MD" Если в базу
> зайти ошибка остается т.е. 2 копии никак...

ошибка сохраняется: "каталог пользователя занят"

> 2. Монитор пользователей работает некорректно.
> Запускаем 1С в режиме Монитора. Выводим список активных пользователей.
> Пользователи отображаются. Нажимаем кнопку обновить. Пользователи исчезают из
> списка. Для повторного вывода списка необходимо перезагрузить 1С. В режиме
> Предприятие Монитор ведет себя аналогично.

Данная ошибка не воспроизвелась.

Comment 65 Svetlana Zhukova 2011-08-24 11:37:52 MSK

1с77,база "торговля и склад"-локальная.

Comment 66 Александр Морозов 2011-08-24 14:42:48 MSK

> ошибка сохраняется: "каталог пользователя занят"
Не получилось воспроизвести.

Comment 67 Svetlana Zhukova 2011-08-24 17:05:08 MSK

Всё правильно,не воспроизводится.
Ошибка появляется,когда сначала запустишь конфигурацию от конкретного пользователя, а потом попытаешься запустить вторую копию этой конфигурации от этого пользователя.

Comment 68 Andrey Vusik 2011-08-25 17:01:08 MSK

(В ответ на comment #67)
> Всё правильно,не воспроизводится.
> Ошибка появляется,когда сначала запустишь конфигурацию от конкретного
> пользователя, а потом попытаешься запустить вторую копию этой конфигурации от
> этого пользователя.

Это не является ошибкой. Ошибкой было "Общая файловая ошибка при доступе к c:\base\1Cv7.MD"

По этой баге всё решено.

Comment 69 Shestakov Dmitriy 2012-02-07 17:17:01 MSK

WINE 2.0 клиент жалуется на низкую скорость работы даже в однопользовательском режиме 1с v7.7. Надо протестировать.

Comment 70 Svetlana Zhukova 2012-02-10 15:44:19 MSK

на dragonfly,ALT Linux 6.0.1 KDesktop по ssh:

WINE@Etersoft Network 2.0.0-eter2.13/8

1с77, Бухгалтерия демо.

> Использовались 2-е базы:
>   demoDB - демо-база от 1с
>   testDB - действующая база с ~200 контрагентами.
Не смогла обнаружить testDB ни на фтп,ни в бутылках(хотелось бы,коненечно,на действующей).

Торговля и склад (ATCDemo)

В монопольном режиме:

Общее время 121
Среднее время получения долга по клиенту 2.16071428571428571429
Общее время 116
Среднее время получения долга по клиенту 2.07142857142857142857
Общее время 116
Среднее время получения долга по клиенту 2.07142857142857142857
Общее время 130
Среднее время получения долга по клиенту 2.32142857142857142857

В сетевом:
Общее время 25052
Среднее время получения долга по клиенту 447.35714285714285714286
Общее время 24542
Среднее время получения долга по клиенту 438.25
Общее время 25262
Среднее время получения долга по клиенту 451.10714285714285714286
Общее время 34430
Среднее время получения долга по клиенту 614.82142857142857142857

В бутылке eterhack bottle 1c77/5798 :

Монопольно:
Общее время 116
Среднее время получения долга по клиенту 2.07142857142857142857
Общее время 112
Среднее время получения долга по клиенту 2
Общее время 108
Среднее время получения долга по клиенту 1.92857142857142857143
Общее время 114
Среднее время получения долга по клиенту 2.03571428571428571429

Сетевой режим:
Общее время 325
Среднее время получения долга по клиенту 5.80357142857142857143
Общее время 332
Среднее время получения долга по клиенту 5.92857142857142857143
Общее время 320
Среднее время получения долга по клиенту 5.71428571428571428571
Общее время 320
Среднее время получения долга по клиенту 5.71428571428571428571



Это действительно не сравнить с предыдущими результатами,слишком долго.

Comment 71 Александр Морозов 2012-03-21 19:16:35 MSK

> на dragonfly,ALT Linux 6.0.1 KDesktop по ssh:
Похоже, этой машины больше нет.

Comment 72 Svetlana Zhukova 2012-03-22 11:37:06 MSK

раньше:
(В ответ на comment #59)
> в сетевом:
> Общее время 17
> Среднее время получения долга по клиенту 0.43589743589743589744

> в монопольном:
> Общее время 15
> Среднее время получения долга по клиенту 0.38461538461538461538
потом:
(В ответ на comment #70)
> В бутылке eterhack bottle 1c77/5798 :
> 
> Монопольно:
> Общее время 116
> Среднее время получения долга по клиенту 2.07142857142857142857

> Сетевой режим:
> Общее время 325
> Среднее время получения долга по клиенту 5.80357142857142857143

> Это действительно не сравнить с предыдущими результатами,слишком долго.

Возможно,бутылки достаточно, разница в скорости существенная.
Также добавила на Fltlinux 6 stand nx.

Comment 73 Svetlana Zhukova 2012-03-22 14:14:03 MSK

> Возможно,бутылки достаточно, разница в скорости существенная.
> Также добавила на Аltlinux 6 stand nx.
В vbox на Аltlinux скорость обработки примерно такая же,как в бутылке,выше,чем была на dragonfly.

На asu:

в сетевом режиме:
Общее время 23936
Среднее время получения долга по клиенту 427.42857142857142857143
в монопольном:
Общее время 116
Среднее время получения долга по клиенту 2.07142857142857142857
2.0.0-eter4.6/9
Везде 1с77, база ATCDemo.

Comment 74 Александр Морозов 2012-03-27 17:38:48 MSK

На asu тормоза, если база лежит на nfs. Это проблемы не wine, это так медленно работают POSIX-блокировки.

Результаты locks/lockperf/linlockperf из репозитория wine-etersoft-devel в /home/guest/wine_c (смонтирован по nfs) на asu:
i = 1000000
39.250000 - 0.000000 = 39.250000

В /var/tmp на asu:
i = 1000000
1.240000 - 0.000000 = 1.240000

В бутылке на eterhack:
i = 1000000
2.180000 - 0.000000 = 2.180000

Comment 75 Svetlana Zhukova 2012-03-28 09:14:30 MSK

(В ответ на comment #72)
> раньше:
> (В ответ на comment #59)
> > в сетевом:
> > Общее время 17
> > Среднее время получения долга по клиенту 0.43589743589743589744
> 
> > в монопольном:
> > Общее время 15
> > Среднее время получения долга по клиенту 0.38461538461538461538


> потом:
> (В ответ на comment #70)
> > В бутылке eterhack bottle 1c77/5798 :
> > 
> > Монопольно:
> > Общее время 116
> > Среднее время получения долга по клиенту 2.07142857142857142857
> 
> > Сетевой режим:
> > Общее время 325
> > Среднее время получения долга по клиенту 5.80357142857142857143


Если это не является существенной разницей,тогда закрываем?

Comment 76 Pavel Shilovsky 2012-03-28 09:16:23 MSK

(В ответ на comment #75)
> Если это не является существенной разницей,тогда закрываем?
Раз клиент жалуется, значит проблема-то есть, разве не так?

Comment 77 Svetlana Zhukova 2012-03-28 09:20:06 MSK

(В ответ на comment #76)

> Раз клиент жалуется, значит проблема-то есть, разве не так?

Мне сложно сказать. С клиентом общается техподдержка. Подождем ответа программиста.

Comment 78 Александр Морозов 2012-03-28 15:19:53 MSK

> (В ответ на comment #72)
> > раньше:
> > (В ответ на comment #59)
> > > в сетевом:
> > > Общее время 17
> > > Среднее время получения долга по клиенту 0.43589743589743589744
> > 
> > > в монопольном:
> > > Общее время 15
> > > Среднее время получения долга по клиенту 0.38461538461538461538
> 
> 
> > потом:
> > (В ответ на comment #70)
> > > В бутылке eterhack bottle 1c77/5798 :
> > > 
> > > Монопольно:
> > > Общее время 116
> > > Среднее время получения долга по клиенту 2.07142857142857142857
> > 
> > > Сетевой режим:
> > > Общее время 325
> > > Среднее время получения долга по клиенту 5.80357142857142857143
> 
> 
> Если это не является существенной разницей,тогда закрываем?
Разница между монопольным и сетевым режимом меньше, чем была изначально (в комментарии 1). Что касается разницы между раньше и позже - это измерения в идентичных условиях с разными wine? Если нет, то причин может быть много, и это вообще не обязательно баг wine. Если да, то надо определить, что на такой версии wine у нас было так, а вот на такой стало медленнее. Тогда можно смотреть и что-то делать.

> (В ответ на comment #75)
> > Если это не является существенной разницей,тогда закрываем?
> Раз клиент жалуется, значит проблема-то есть, разве не так?
Проблема может быть не связана с данным багом.

Comment 79 Svetlana Zhukova 2012-03-29 10:44:31 MSK

Откладываю.

Comment 80 Alexandr 2013-02-07 23:25:15 MSK

> Что касается разницы между раньше и позже - это измерения в
> идентичных условиях с разными wine? Если нет, то причин может быть много, и это
> вообще не обязательно баг wine. Если да, то надо определить, что на такой
> версии wine у нас было так, а вот на такой стало медленнее. Тогда можно
> смотреть и что-то делать.
> 

Сегодня откатил 2.0.3-eter23/5 на 1.0.12 - в новой версии не работает OLE как надо (но об этом другая бага) - и попутно решил потестить разные сборки 1.0.12, благо они у меня сохранились, ну и перед удалением - прогнал по тесту 2.0.3-eter23/5.
Чтобы не было лишних вопросов - сразу скажу что для того чтобы старые сборки нормально вставали на Ubuntu 12.04 amd64 - просто сделал симлинк /usr/lib64 на /usr/lib

Так что все условия для корректного сравнения - одно и тоже железо, операционка, база 1С.
Железо: Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz, 8 cores, RAM 12 Gb
OS: Ubuntu Linux 12.04.1 server amd64
kernel Linux 3.2.0-37-server on x86_64
Terminal server: RX@Etersoft 1.0.2
etercifs не установлен - за ненадобностью.
База 1С - около 2000 клиентов

Результаты:

WINE@Etersoft Network 2.0.3-eter23/5 монопольно

Общее время 1925
Среднее время получения долга по клиенту 19.84536082474226804124
Общее время 1922
Среднее время получения долга по клиенту 19.81443298969072164948
Общее время 1914
Среднее время получения долга по клиенту 19.73195876288659793814

============================================================
WINE@Etersoft Network 2.0.3-eter23/5 сетевой

Общее время 5215
Среднее время получения долга по клиенту 53.7628865979381443299
Общее время 5230
Среднее время получения долга по клиенту 53.91752577319587628866
Общее время 5238
Среднее время получения долга по клиенту 54

*****************************************************************
WINE@Etersoft 1.0 Network 1.0.12-eter11.12/21 монопольно

Общее время 1952
Среднее время получения долга по клиенту 20.12371134020618556701
Общее время 1957
Среднее время получения долга по клиенту 20.1752577319587628866
Общее время 1974
Среднее время получения долга по клиенту 20.3505154639175257732

==============================================================
WINE@Etersoft 1.0 Network 1.0.12-eter11.12/21 сетевой

Общее время 5235
Среднее время получения долга по клиенту 53.96907216494845360825
Общее время 5225
Среднее время получения долга по клиенту 53.86597938144329896907
Общее время 5261
Среднее время получения долга по клиенту 54.2371134020618556701

*****************************************************************
WINE@Etersoft 1.0 Network 1.0.12-eter11.15/22 монопольно

Общее время 1953
Среднее время получения долга по клиенту 20.13402061855670103093
Общее время 1960
Среднее время получения долга по клиенту 20.20618556701030927835
Общее время 1959
Среднее время получения долга по клиенту 20.19587628865979381443

=============================================================
WINE@Etersoft 1.0 Network 1.0.12-eter11.15/22 сетевой

Общее время 5319
Среднее время получения долга по клиенту 54.83505154639175257732
Общее время 5311
Среднее время получения долга по клиенту 54.75257731958762886598
Общее время 5334
Среднее время получения долга по клиенту 54.98969072164948453608

*****************************************************************
WINE@Etersoft 1.0 Network 1.0.12-eter12.9/25 монопольно

Общее время 1914
Среднее время получения долга по клиенту 19.73195876288659793814
Общее время 1905
Среднее время получения долга по клиенту 19.63917525773195876289
Общее время 1932
Среднее время получения долга по клиенту 19.91752577319587628866
Общее время 1920
Среднее время получения долга по клиенту 19.79381443298969072165

=============================================================
WINE@Etersoft 1.0 Network 1.0.12-eter12.9/25 сетевой

Общее время 5281
Среднее время получения долга по клиенту 54.44329896907216494845
Общее время 5665
Среднее время получения долга по клиенту 58.40206185567010309278
Общее время 5286
Среднее время получения долга по клиенту 54.49484536082474226804
Общее время 5292
Среднее время получения долга по клиенту 54.55670103092783505155

*****************************************************************
WINE@Etersoft 1.0 Network 1.0.12-eter13/26 монопольно

Общее время 1903
Среднее время получения долга по клиенту 19.61855670103092783505
Общее время 1913
Среднее время получения долга по клиенту 19.72164948453608247423
Общее время 1931
Среднее время получения долга по клиенту 19.90721649484536082474
Общее время 1919
Среднее время получения долга по клиенту 19.78350515463917525773

=============================================================
WINE@Etersoft 1.0 Network 1.0.12-eter13/26 сетевой

Общее время 5331
Среднее время получения долга по клиенту 54.95876288659793814433
Общее время 5270
Среднее время получения долга по клиенту 54.32989690721649484536
Общее время 5264
Среднее время получения долга по клиенту 54.26804123711340206186
Общее время 5283
Среднее время получения долга по клиенту 54.46391752577319587629

*****************************************************************
WINE@Etersoft 1.0 Network 1.0.12-eter14/28 монопольно

Общее время 1938
Среднее время получения долга по клиенту 19.97938144329896907216
Общее время 1943
Среднее время получения долга по клиенту 20.03092783505154639175
Общее время 1915
Среднее время получения долга по клиенту 19.74226804123711340206
Общее время 1943
Среднее время получения долга по клиенту 20.03092783505154639175

=============================================================
WINE@Etersoft 1.0 Network 1.0.12-eter14/28 сетевой

Общее время 7885
Среднее время получения долга по клиенту 81.28865979381443298969
Общее время 7880
Среднее время получения долга по клиенту 81.2371134020618556701
Общее время 7923
Среднее время получения долга по клиенту 81.68041237113402061856
Общее время 7891
Среднее время получения долга по клиенту 81.3505154639175257732

*****************************************************************
WINE@Etersoft 1.0 Network 1.0.12-eter14/28 i386  монопольно

Общее время 1880
Среднее время получения долга по клиенту 19.38144329896907216495
Общее время 1875
Среднее время получения долга по клиенту 19.32989690721649484536
Общее время 1898
Среднее время получения долга по клиенту 19.56701030927835051546
Общее время 1873
Среднее время получения долга по клиенту 19.30927835051546391753

=============================================================
WINE@Etersoft 1.0 Network 1.0.12-eter14/28 i386 сетевой

Общее время 7932
Среднее время получения долга по клиенту 81.77319587628865979381
Общее время 7769
Среднее время получения долга по клиенту 80.09278350515463917526
Общее время 7878
Среднее время получения долга по клиенту 81.21649484536082474227
Общее время 7764
Среднее время получения долга по клиенту 80.04123711340206185567

Как видно из результатов - WINE@Etersoft Network 2.0.3-eter23/5 показала один из лучших результатов в сравнении с 1.0.12 - так что в этом смысле багу можно спокойно закрывать как неподтвержденную.

А вот почему последняя сборка 1.0.12-eter14/28 продемонстрировала худший результат из всех - НА 48% ХУЖЕ eter13/26 в сетевом режиме!! - вот это интересный вопрос..