1С 7.7 Большие задержки при обращении к сводным остаткам.
Не зависит от дистрибутива линуха(тестировалось на 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 тормоза будут тем большими, чем чаще сводные остатки считаются.." Соответственно, для увеличения скорости работы надо переделывать конфигурацию на предмет минимизации обращений к сводным остаткам. Но это не панацея, и далеко не каждый возьмется переписывать конфигурацию, чтобы добиться комфортной работы.
(In reply to comment #0) > 1С 7.7 > Большие задержки при обращении к сводным > остаткам. > Я бы пожалуй выставил уровень серьезности "Серьезная" - по сути, все конфы работающие с компонентой Оперативный Учет (Комплексная, ТиС, ПУБ.., не говоря о самописных - они почти все нацелены на создание подобия CRM на базе 1С с оперативным учетом) "благодаря" этому багу будут тормозить (особенно в "управленческих" отчетах, которыми пользуется РУКОВОДСТВО - которое в конечном итоге из-за тормозов может "зарубить" использование wine@etersoft в организации). А если организация большая с крупными клиентами (с кучей реализаций), то и любой менеджер желающий узнать сколько должен клиент, сколько осталось товара на складе и прочее - будет врагом wine@etersoft. Т.е фактически за счет этого бага отсекается масса клиентов еще на этапе "триала", остаются те кому нужна "в чистом виде 1С бухгалтерия", и энтузиасты вроде меня, готовые "перелопатить" конфигурацию ради комфортной работы. Ведь для крупной конторы легальная винда - не проблема. Если же "победите" тормоза в оперативном учете (читай работа с регистрами и сводными остатками в частности) - и в крупных конторах деньги считают (тем более, что лицензия на корпоративную винду при смене юрлица - что норма жизни для отечественного бизнеса, ануллируется. И надо покупать лицензию по новой). Так что для работы Вашей разработки - может серьезность и незначительная, а вот для Вашего бизнеса - очень даже..
Created attachment 1783 [details] обработка, которой измерялась производительность.
Надо измерить производительность со сборками 4.5.1.3 и 4.5.1.4 из баги 5442.
(In reply to comment #4) > Надо измерить производительность со > сборками 4.5.1.3 и 4.5.1.4 из баги 5442. > Если речь о сборках etercifs - то первоначальное тестирование шло вообще без него, база используется в терминале без использования подключения по сети. Стоит etercifs или нет - результат один..
(In reply to comment #0) > 1С 7.7 > Большие задержки при обращении к сводным > остаткам. > Порадовала гордая цифра в "проценте звершения" %)) Что, проблема решена? Если имелось ввиду, что "раз зависит от бага 3031, то делать тут нечего, вот решим баг 3031.." - то простите, не согласен. В баге 3031 речь о том что "при вызове номенклатуры идет постоянный перерасчет итогов. На винде он выполняется секунд 5-9, а в wine секунд 30." - и ни слова про разницу в монопольном и сетевом режимах.. Хотя может подразумевается именно сетевой режим? А как база из бага 3031 ведет себя в монопольном? Данный же баг - про НЕАДЕКВАТНУЮ разницу скорости работы в монопольном и многопользовательском вариантах под wine по сравнению с виндами. Причем в МОНОПОЛЬНОМ расчет итогов регистров РАБОТАЕТ БЫСТРЕЕ чем в винде. Что означает что с реализацией функций-прокладок между wine и linux (на что делается упор в баге 3031, насколько понял) все относительно хорошо. А вот плохо - с системой блокировок, заставляющих выполняться те самые функции-прокладки многократно большее количество раз, по сравнению с аналогичным механизмом виндов.. Простите, если все это покажется вам мнением дилетанта. Я то свою базу переделал - в октябре контора переводится на линух. Но кое-какие тормоза все равно остались, надеюсь что все таки данный баг найдет решение, а не будет положен "на полочку". К слову - руководство готово поддержать разработчиков материально, если будет результат (вот только ответа на вопрос "сколько" я не знаю)..
Уточнение баги, корректировка зависимостей. Укороченная формулировка: При работе в многопользовательском режиме идет очень долгое построение отчета. to amorozov@: Есть какие либо предположения почему такие задержки? Возможно ли это исправить? Сколько потребуется времени на оптимизацию?
Раз речь идёт о разнице при работе монопольного режима и многопользовательского, то данная проблема сходна с багой 3032. В баге 5442 были предложены прототипы (4.5.1.3, 4.5.1.4, 4.5.1.5, 4.5.1.6), для решения последней. Думаю, стоит попробовать их на данной проблеме. baraka@, что скажешь?
(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.
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" монтирования диска с базами результаты тестирования будут гораздо лучше. При этом риск только один - вырубание электричества при отсутствии ИБП или авральный ребут - частичная потеря информации. Блокировки тож по идее будут работать нормально. Пусть пользователь сам выберет вариант монтирования - скорость или супернадежность..
> МОЖЕТЕ ЛИ СДЕЛАТЬ СБОРКУ С ВОЗМОЖНОСТЬЮ ВЫБОРА ОПЦИЙ МОНТИРОВАНИЯ ПРИ > КОНФИГУРИВОВАНИИ ДИСКОВ? - в частности "sync", "nosync" (ну и "noatime" тож > неплохо бы..) WINE сам ничего не монтирует.
(В ответ на 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. Если решите перепроверять - рекомендую сравнивать файлы с конца - быстрее будет..))
Created attachment 1965 [details] Лог strace Регистр.СводныйОстаток в монопольном режиме
Логи Немонопольного режима и Разницы логов загрузить не получилось - слишком большие - 7,65 и 7,63 Мб соответственно. Отправил все 3 лога на почту amorozov@etersoft.ru. Авось пройдет.
*** Bug 6911 has been marked as a duplicate of this bug. ***
Исправить данную проблему, вобще попытки какие то делаются?!
> Исправить данную проблему, вобще попытки какие то делаются?! Она ждёт своей очереди.
Сравнил количество вызовов некоторых функций при выполнении тестовой обработки в монопольном и немонопольном режиме под 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
На 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
valgrind --trace-children=yes --tool=callgrind в случае с wine, к сожалению, падает
Если сделать, чтобы функции LockFile и UnlockFile ничего не делали для файлов с дескриптором больше 0x100, то время выполнения обработки сокращается приблизительно в десять раз. Измерил скорость работы блокировок на Windows и Linux с помощью тестовых программ, устанавливающих и снимающих блокировку на первые 16 байт файла 1000000 раз (locks/lockperf в wine-etersoft-devel): Windows ~1,4 с WINE ~37 с Linux ~1,9 с
> WINE ~37 с Если закомментировать обработчики lock_file и unlock_file в wineserver, то время выполнения теста сокращается до ~29 с. По-видимому, большая часть времени тратится на запрос к wineserver.
Думаю, работу с блокировками можно ускорить, если вынести их установку из wineserver в ntdll. Но это заметная переделка, потом могут быть сложности с применением изменений из апстрима.
(В ответ на comment #24) > Думаю, работу с блокировками можно ускорить, если вынести их установку из > wineserver в ntdll. Но это заметная переделка, потом могут быть сложности с > применением изменений из апстрима. А если попробовать обсудить проблему в апстрим и согласовать с ними эту переделку? Возможно идея найдёт отклик, и нам помогут с реализацией.
> А если попробовать обсудить проблему в апстрим и согласовать с ними эту > переделку? Возможно идея найдёт отклик, и нам помогут с реализацией. Маловероятно. Думаю, чтобы протолкнуть такое глубинное изменение, нужны веские причины. Сейчас думаю в сторону параллельной реализации в закрытой части без переделки wineserver. Функции установки/снятия блокировок можно вызывать из NtLockFile/NtUnlockFile. Для wineserver установленные таким образом блокировки будут выглядеть как поставленные внешним процессом, но это вроде бы не должно вызвать каких-либо проблем.
(В ответ на comment #26) > > А если попробовать обсудить проблему в апстрим и согласовать с ними эту > > переделку? Возможно идея найдёт отклик, и нам помогут с реализацией. > Маловероятно. Думаю, чтобы протолкнуть такое глубинное изменение, нужны веские > причины. > > Сейчас думаю в сторону параллельной реализации в закрытой части без переделки > wineserver. Функции установки/снятия блокировок можно вызывать из > NtLockFile/NtUnlockFile. Для wineserver установленные таким образом блокировки > будут выглядеть как поставленные внешним процессом, но это вроде бы не должно > вызвать каких-либо проблем. Обсудили с amorozov@ данное изменение с точки зрения работы CIFS, так как в таком случае придётся менять логику работы модуля, а так же возникнет проблема с потерей блокировки после печати на принтере. Проблема требует более детального рассмотрения.
Пока не видно способа реализовать перенос установки блокировок из wineserver в процесс запущенной под WINE программы. При использовании etercifs чтение выполняется с использованием pid процесса, открывшего файл. Открывает файл wineserver. Если мы поставим блокировку не из wineserver, то мы не сможем читать/писать (блокировки mandatory). Если реализовать в etercifs хак, чтобы при установке блокировки на дескриптор любым процессом получалось так, будто эту блокировку поставил процесс, открывший файл, то в качестве побочного эффекта при закрытии файла будут сбрасываться все блокировки. Проблема в том, что файл может быть закрыт при завершении какой-нибудь дочерней утилиты, например, при печати.
(В ответ на comment #28) > Пока не видно способа реализовать перенос установки блокировок из wineserver в > процесс запущенной под WINE программы. > При использовании etercifs чтение выполняется с использованием pid процесса, > открывшего файл. Открывает файл wineserver. Если мы поставим блокировку не из > wineserver, то мы не сможем читать/писать (блокировки mandatory). Если > реализовать в etercifs хак, чтобы при установке блокировки на дескриптор любым > процессом получалось так, будто эту блокировку поставил процесс, открывший > файл, то в качестве побочного эффекта при закрытии файла будут сбрасываться все > блокировки. Проблема в том, что файл может быть закрыт при завершении > какой-нибудь дочерней утилиты, например, при печати. Вам конечно виднее по статистике покупки лицензий, но по моему в большинстве случаев связка 1С+Linux+wine@etersoft реализуется в терминальном режиме. А в терминальном режиме etrcifs не нужен. Сделайте тестовую сборку, решающую проблему в терминальном режиме (с оговоркой-предупреждением о невозможности использования etercifs) - и мы Вам скажем спасибо и протестируем. Как вариант в дальнейшем можно просто под терминальное решение делать отдельную сборку. Ведь лицензии у вас отличаются..
...полностью согласен с Alexandr!
Начал реализовывать механизм для установки блокировок не в wineserver для файлов, расположенных на NFS и локальных ФС.
(В ответ на comment #31) > Начал реализовывать механизм для установки блокировок не в wineserver для > файлов, расположенных на NFS и локальных ФС. БОГ в помощь))) я уж думал до конца года трабла останется.. Ждемс..)))
Пока дескрипторы будут храниться в двусвязном списке. Потом можно будет перейти на более быструю в плане поиска структуру.
Поведение блокировок в Linux и Windows отлчается в плане пересечения и снятия, так что просто вызывать fcntl в лоб нельзя. В Windows эксклюзивные блокировки не могут пересекаться, даже если они устанавливаются одним процессом, сниматься блокировка должна с тем же смещением и длиной, нельзя поставить большую блокировку, а потом выключить кусочек в середине.
Реализовал сохранение установленных для хэндла блокировок в двусвязном списке. Добавил поиск пересечения с уже установленными экслюзивными блокировками при установке блокировки. Добавил проверку на то, что блокировка установлена, при снятии блокировки. Пофиксил баг с неудачей при установке блокировки нулевого размера.
Занимался реализацией снятия блокировок в случае, если у нас стоят пересекающиеся блокировки.
Занимался данным багом.
Читал комментарии о проделанной работе, но так и не понял, есть шанс все таки победить баг или нет?
> Читал комментарии о проделанной работе, но так и не понял, есть шанс все таки > победить баг или нет? Баг будет решён для NFS и локальных ФС.
Реализовал установку блокировок не в wineserver с хранением дескрипторов в двусвязном списке. Теперь надо перейти от списка к более быстрой структуре, т.к. наблюдается регресс в скорости чтения с использованием большого количества дескрипторов из-за медленного поиска в списке.
(В ответ на comment #39) > > Читал комментарии о проделанной работе, но так и не понял, есть шанс все таки > > победить баг или нет? > Баг будет решён для NFS и локальных ФС. ...это замечательно, большего для решения моей проблемы и не нужно!
Для более быстрого доступа к дескрипторам можно использовать две хеш-таблицы: в одной ключом будет хэндл, в другой - dev_t и ino_t файла. Вторая будет использоваться при проверке пересечений блокировок для файла и при закрытии хэндла (если это последний хэндл для файла - всё освобождаем). В качестве хеш-таблицы можно использовать вот это: http://www.pomakis.com/hashtable/ (public domain). Можно было бы использовать стандартные функции hcreate/hsearch, но там в качестве ключа используется строка, что нам не подходит.
Закоммитил изменения в закрытую часть. Отправил патчи для открытой части в рассылку.
Результаты выполнения тестовой обработки на расположенной локально базе "Торговля + Склад, редакция 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 #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 СУПЕР! %)) Осталось выложить новую сборку - потестить..))
После обсуждения с amorozov@, появилась идея использовать такой режим и для cifs. Для этого надо убрать проброс пида - то есть монтировать просто с forcemand и strictcache, но без опции wine (для 4.8.1 сборки strictcache есть в 32,35,37 и 38 ядрах, для остальных использовать direct) - временная мера для тестирования. Что следует проверить: 1) возможность приложения писать и читать из заблокированной им же самим области. 2) невозможность писать и читать из заблокированной другим процессом области. 3) невозможность установки блокировки из одного процесса на область заблокированную другим процессом - блокировки на запись. Возможность этого для блокировки на чтение. 4) 1С: 4.1) монитор пользователей, блокировка документа, одновременнная проводка. 4.2) открытие документа на запись и печать документа на принтере - после окончании печати документ всё ещё заблокирован, а после закрытия документа блокировка снимается успешно (проверка на то, что программа печати не влияет на блокировки установленные самой 1С).
Забыл добавить, что первый три пункта проверки нужно проводить так же из-под wine.
Закомментировал проверку на ФС в закрытой части. Написал утилиты для тестирования чтения и записи из заблокированной области: 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) любые блокировки ставятся несколькими процессами одновременно.
> 1) чтение из заблокированной области не проходит Посмотрел, что происходит в этом случае: read возвращает EACCES. Возможно, это связано с тем, что открытие файла происходит не в том процессе, который читает.
Мне кажется, стоит работы по CIFS вести в отдельной баге. А эту либо закрыть, либо проставить оставшееся время.
По CIFS создал отдельную багу: http://bugs.etersoft.ru/show_bug.cgi?id=7302. Здесь выставляю решено.
... Супер! Теперь расскажите как можно протестировать то что сделано? На персональной страничке заказать тестовую сборку?
> ... Супер! Теперь расскажите как можно протестировать то что сделано? На > персональной страничке заказать тестовую сборку? Открытая часть 1.0.12-alt11.2, закрытая часть следующая после 1.0.12-alt19. При заказе тестовой сборки сейчас скорее всего соберётся 1.0.12-alt19, так что надо подождать, когда выйдет следующая версия закрытой части.
(В ответ на 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! Это от души)
Оказалось, что патч для данного бага приводит к следующим проблемам при работе с локальной базой. 1. Невозможно запустить две копии базы из под одного пользователя. Запускаем 1С 7.7, выбираем любую базу, появляется окно "Авторизация доступа", оставляем базу в таком состоянии. Пытаемся запустить вторую копию базы, получаем окно "Общая файловая ошибка при доступе к c:\base\1Cv7.MD" Если в базу зайти ошибка остается т.е. 2 копии никак... 2. Монитор пользователей работает некорректно. Запускаем 1С в режиме Монитора. Выводим список активных пользователей. Пользователи отображаются. Нажимаем кнопку обновить. Пользователи исчезают из списка. Для повторного вывода списка необходимо перезагрузить 1С. В режиме Предприятие Монитор ведет себя аналогично.
Проблема вызвана использованием для блокировок специального дескриптора. Скорее всего, дело в том, что получается одно общее смещение для разных хэндлов. Откатил хак для бага #7350, т.к. теперь работает и без него.
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
Проверь пожалуйста https://bugs.etersoft.ru/show_bug.cgi?id=5798#c46
результаты описаны в http://bugs.etersoft.ru/show_bug.cgi?id=5798#c59 после слов "если не использовать etercifs, то" - тут проверялось на локальной базе.
(В ответ на comment #60) > Проверь пожалуйста https://bugs.etersoft.ru/show_bug.cgi?id=5798#c46 Прошу прощения. проверь http://bugs.etersoft.ru/show_bug.cgi?id=5798#c57
бутылка 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С. В режиме > Предприятие Монитор ведет себя аналогично. Данная ошибка не воспроизвелась.
1с77,база "торговля и склад"-локальная.
> ошибка сохраняется: "каталог пользователя занят" Не получилось воспроизвести.
Всё правильно,не воспроизводится. Ошибка появляется,когда сначала запустишь конфигурацию от конкретного пользователя, а потом попытаешься запустить вторую копию этой конфигурации от этого пользователя.
(В ответ на comment #67) > Всё правильно,не воспроизводится. > Ошибка появляется,когда сначала запустишь конфигурацию от конкретного > пользователя, а потом попытаешься запустить вторую копию этой конфигурации от > этого пользователя. Это не является ошибкой. Ошибкой было "Общая файловая ошибка при доступе к c:\base\1Cv7.MD" По этой баге всё решено.
WINE 2.0 клиент жалуется на низкую скорость работы даже в однопользовательском режиме 1с v7.7. Надо протестировать.
на 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 Это действительно не сравнить с предыдущими результатами,слишком долго.
> на dragonfly,ALT Linux 6.0.1 KDesktop по ssh: Похоже, этой машины больше нет.
раньше: (В ответ на comment #59) > в сетевом: > Общее время 17 > Среднее время получения долга по клиенту 0.43589743589743589744 > в монопольном: > Общее время 15 > Среднее время получения долга по клиенту 0.38461538461538461538 потом: (В ответ на comment #70) > В бутылке eterhack bottle 1c77/5798 : > > Монопольно: > Общее время 116 > Среднее время получения долга по клиенту 2.07142857142857142857 > Сетевой режим: > Общее время 325 > Среднее время получения долга по клиенту 5.80357142857142857143 > Это действительно не сравнить с предыдущими результатами,слишком долго. Возможно,бутылки достаточно, разница в скорости существенная. Также добавила на Fltlinux 6 stand nx.
> Возможно,бутылки достаточно, разница в скорости существенная. > Также добавила на Аltlinux 6 stand nx. В vbox на Аltlinux скорость обработки примерно такая же,как в бутылке,выше,чем была на dragonfly. На asu: в сетевом режиме: Общее время 23936 Среднее время получения долга по клиенту 427.42857142857142857143 в монопольном: Общее время 116 Среднее время получения долга по клиенту 2.07142857142857142857 2.0.0-eter4.6/9 Везде 1с77, база ATCDemo.
На 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 #72) > раньше: > (В ответ на comment #59) > > в сетевом: > > Общее время 17 > > Среднее время получения долга по клиенту 0.43589743589743589744 > > > в монопольном: > > Общее время 15 > > Среднее время получения долга по клиенту 0.38461538461538461538 > потом: > (В ответ на comment #70) > > В бутылке eterhack bottle 1c77/5798 : > > > > Монопольно: > > Общее время 116 > > Среднее время получения долга по клиенту 2.07142857142857142857 > > > Сетевой режим: > > Общее время 325 > > Среднее время получения долга по клиенту 5.80357142857142857143 Если это не является существенной разницей,тогда закрываем?
(В ответ на comment #75) > Если это не является существенной разницей,тогда закрываем? Раз клиент жалуется, значит проблема-то есть, разве не так?
(В ответ на comment #76) > Раз клиент жалуется, значит проблема-то есть, разве не так? Мне сложно сказать. С клиентом общается техподдержка. Подождем ответа программиста.
> (В ответ на 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) > > Если это не является существенной разницей,тогда закрываем? > Раз клиент жалуется, значит проблема-то есть, разве не так? Проблема может быть не связана с данным багом.
Откладываю.
> Что касается разницы между раньше и позже - это измерения в > идентичных условиях с разными 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 в сетевом режиме!! - вот это интересный вопрос..
