Укажите отработанное время

Отработанное время:
Продуктивное время:
Bug 3032 - 1C77: Долгая прорисовка списка номенклатуры при работе через CIFS   Make a simular bug
Summary: 1C77: Долгая прорисовка списка номенклатуры при работе через CIFS
Status: CLOSED FIXED
Alias: None
Product: WINE@Etersoft
Classification: Продукты (Products)
Component: Сетевые файловые системы (show other bugs)
Version: 1.0.10
Hardware: PC All
: P2 normal
Target Milestone: ---
Deadline: 2011-04-01
Assignee: Pavel Shilovsky
QA Contact:
URL:
Whiteboard:
Keywords:
: 570 (view as bug list)
Depends on: 3725 5442 6227 6773
Blocks: 42 3044 6765
  Show dependency treegraph
 
In work:
Reported: 2008-11-28 21:32 MSK by Денис Баранов
Modified: 2011-10-26 12:46 MSK (History)
9 users (show)

See Also:
Заявки RT: 14972
Связано с:
Дата напоминания:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Денис Баранов 2008-11-28 21:32:29 MSK
При работе через CIFS, список номенклатуры прорисовывается оч долго.
При чем: 1) если входить монопольно, то прорисовка идет быстро без задержек
2)если войти только 1 пользователем (т.е. по идее как монопольный режим должен быть) то прорисовка все равно долгая.

3)если заходить с винды, то прорисовка нормальная во всех случаях.
Comment 1 Денис Баранов 2008-11-28 21:33:39 MSK
Примером может служить тестовая база Альфа Авто:
ftp/pvt/Windows/1C/1Cv77_configs/Alfa Auto/Avtosalon_work.7z или на cellar в sharewine
Comment 2 Andrey Vusik 2008-12-06 12:53:46 MSK
Предложение из заявки:
"Проделайте следующее - включите в отладчике замер производительности, попрокручивайте список номенклатуры секунд 10-20, и затем посмотрите, какие строчки выполняются дольше всего в модуле Номенклатура"
Comment 3 Vitaly Lipatov 2008-12-06 14:48:36 MSK
У нас воспроизводится?
Comment 4 Денис Баранов 2008-12-09 11:00:01 MSK
При перемещении по номенклатуре дольше всего выполняются след функции:
Функция ПолучитьОстаток()
	Если флОстатки=0 Тогда Возврат ""; КонецЕсли;
	Возврат ?(ТекущийЭлемент().ЭтоГруппа()=1, "", 
			  ?(ПустоеЗначение(ВыбПодразделение)=0, РегОТ.СводныйОстаток(ВыбПодразделение,ТекущийЭлемент(),,"Количество"),
			  										РегОТ.СводныйОстаток(,ТекущийЭлемент(),,"Количество")));
КонецФункции	// ПолучитьОстаткок

//-----------------------------------------------
Функция ПолучитьРезерв()
	Если флОстатки=0 Тогда Возврат ""; КонецЕсли;
	Возврат ?(ТекущийЭлемент().ЭтоГруппа()=1, "", 
			  ?(ПустоеЗначение(ВыбПодразделение)=0, РегРез.СводныйОстаток(ВыбПодразделение,ТекущийЭлемент(),,"Количество"),
			  										РегРез.СводныйОстаток(,ТекущийЭлемент(),,"Количество")));
КонецФункции	// ПолучитьРезерв
Comment 5 Денис Баранов 2009-03-22 17:05:01 MSK
(In reply to comment #3)
> У нас воспроизводится?
> 
Да, воспроизводится.
Проверял на базе Альфа Авто расшаренной на //cellar/sharewine
etercifs-4.2.1-alt1
Comment 6 Виталий Перов 2009-04-03 14:36:06 MSD
Возможно есть какая-то корелляция с багой #3725
Comment 7 Виталий Перов 2009-04-03 14:52:51 MSD
Вообще, не понимаю, при чём здесь я.
Но раз повесили буду делать.

Как я вижу для себя ход решения проблемы:
1) трейс по каналу file
2) Выяснение примерного списка функций, вызывамых в момент прокрутки списка номенклатуры
3) Создание тестов по замеру времени и уточнение списка "медленных" функций
4) Исправление
Comment 8 Боренко Денис 2009-04-18 13:38:14 MSD
Мне кажется, что есть кореляция с 3759. 
Функция Регистр.СводныйОстаток производит чтение из разных областей файла регистра. Вполне возможно (попробую на досуге проверить), что в момент чтения устанавливается блокировка на весь файл, что, как известно, делается установкой блокировки на запись в байт лежащий за концом файла. Большие тайминги (см. 3759) при попытке получить блокировку могут быть причиной медленной работы.
Кроме того, пока цифс ждет ответный пакет, полностью блокируется исполнение 1с (она мертво висит), это хорошо объясняет накопление событий в буфере клавиатуры (у вашего клиента это проявляется большой инерционностью при отпускании клавиши).
Comment 9 Денис Баранов 2009-05-05 16:41:36 MSD
Костя нашел интересную информацию по поводу отрисовки:
http://unixforum.org/index.php?showtopic=90639&view=findpost&p=851301 
Надо посмотреть на отрисовку шрифтов.
Comment 10 Боренко Денис 2009-05-05 16:47:10 MSD
Да-да. Надо посмотреть. Правдо дело наверное не совсем в шрифтах.
http://bugs.etersoft.ru/show_bug.cgi?id=3911
Comment 11 Евгений Синельников 2009-05-05 17:00:58 MSD
(In reply to comment #9)
> Костя нашел интересную информацию по
> поводу отрисовки:

http://unixforum.org/index.php?showtopic=90639&pid=843994&mode=threaded&start=0#entry843994

Хм... Проблемы всё те же...
"Тормоза при работе через CIFS в не монопольном режиме. Через NFS и в монопольном всё летает"

http://unixforum.org/index.php?showtopic=90639&pid=843756&mode=threaded&start=0#entry843756
Comment 12 Vitaly Lipatov 2009-08-05 11:44:20 MSD
Нужно проверить ещё раз на 1.0.11
Возможно рассмотреть с Сашей причины замедления.
Comment 13 Pavel Shilovsky 2010-04-08 23:22:00 MSD
В общем ситуация следущая. База взята из поста #1.

Заходим одним Linux клиентом - тормозит.
Заходим одним Windows клиентом - не тормозит.
Заходим и Linux и Windows клиентом - тормозят оба.

Причина в следующем: При просмотре списка номенклатуры очень много происходит запросов на блокировки.

Странно, что поведение в одиночном случае отличается - у Linux они посылаются, e Windows - нет. Когда в базе оба клиента, то запросы на блокировки посылают и Linux, и Windows.
Comment 14 Vitaly Lipatov 2010-04-09 16:36:13 MSD
(In reply to comment #13)
...
> Причина в следующем: При просмотре списка
> номенклатуры очень много происходит
> запросов на блокировки.
У нас как-то замедленно работают блокировки? Была же какая-то эпопея с неким параметром и задержкой на блокировку, вроде даже в документации описана настройка Самбы.

> Странно, что поведение в одиночном случае
> отличается - у Linux они посылаются, e Windows -
> нет. Когда в базе оба клиента, то запросы на
> блокировки посылают и Linux, и Windows.
Это никак не связано с получением оплоков? По идее, в монопольном режиме клиент, получивший OPLOCK 2, то есть право на кэширование записи у себя, не должен хотеть посылать блокировки, это не имеет смысла. У нас всегда посылает?

Comment 15 Pavel Shilovsky 2010-04-09 23:06:52 MSD
(In reply to comment #14)
> (In reply to comment #13)
> ...
> У нас как-то замедленно работают
> блокировки? Была же какая-то эпопея с неким
> параметром и задержкой на блокировку,
> вроде даже в документации описана
> настройка Самбы.
Нет, у нас всё так же, как и у Windows клиента. Он тоже тормозит на этой базе.
> 
> Это никак не связано с получением оплоков?
> По идее, в монопольном режиме клиент,
> получивший OPLOCK 2, то есть право на
> кэширование записи у себя, не должен хотеть
> посылать блокировки, это не имеет смысла. У
> нас всегда посылает?
Да. По идеи, тогда, когда клиент получает oplock break сообщение, он должен все свои блокировки сбросить на сервер. Чтобы не нарушить логику работы.

Я имел ввиду не монопольный режим, а режим работы с одним пользователем в базе. Здесь поведение Windows и Linux клиента отличаются. Это проиходит, как мне кажется, по следующим причинам:
Windows клиент понимает, что он один держит файл, потому не посылает блокировки и не читает из него. Linux клиент тоже понимает это, но блокировки всё же выставляет, когда нужно. Так как у нас опция wine включает опцию direct, то получается, что мы всегда напрямую читаем с сервера - у нас кеш не работает. Если же убрать опцию direct, то запросы на чтение отправляться не будут, а только запросы на блокировки.

Если же рассмотреть работу двух клиентов в базе, то результаты Windows и Linux клиентов близки по производительности. С опцией direct поведение полностью индеитичное. Без опции direct, Linux вместо запросов на чтение отправляет дополнительные запросы на блокировки. Производительность по прокрутке списка не заметил, чтобы сильно отличалась.

Потому предлагаю убрать опцию direct из wine. Создал тестовую сборку для 31 и 32 ядер - 4.5.1-alt1 - на ftp.

to baraka: Нужно потестировать 31 или 32 ядра с 1С согласно обычной методике + замерить производительность по сравнению со старым вариантом. Старый вариант можно получить, просто монтируя с параметрами wine,direct.
Comment 16 Vitaly Lipatov 2010-04-10 04:09:06 MSD
(In reply to comment #15)
> Я имел ввиду не монопольный режим, а режим
> работы с одним пользователем в базе. Здесь
Думается мне, в данном случае совершенно не важно, монопольно открываются файлы или нет - при одном пользователе оплок всё равно выдаётся.

> поведение Windows и Linux клиента отличаются. Это
> проиходит, как мне кажется, по следующим
> причинам:
> Windows клиент понимает, что он один держит
> файл, потому не посылает блокировки и не
> читает из него. Linux клиент тоже понимает
> это, но блокировки всё же выставляет, когда
Интересно понять, на каком уровне это происходит.
Хотя в общем-то понятно, что не в userspace.

> нужно. Так как у нас опция wine включает опцию
> direct, то получается, что мы всегда напрямую
...

...
> Потому предлагаю убрать опцию direct из wine.
Так а уже исправлены все проблемы с оплоками? Мы же не зря direct вводили.

> Создал тестовую сборку для 31 и 32 ядер -
> 4.5.1-alt1 - на ftp.
Я пытался соединить со своими изменениями, но что-то не увидел в git изменений в HEAD.
 
Comment 17 Pavel Shilovsky 2010-04-10 09:42:15 MSD
(In reply to comment #16)
> (In reply to comment #15)
> ...
> Интересно понять, на каком уровне это
> происходит.
> Хотя в общем-то понятно, что не в userspace.

В cifs драйвере.

> ...
> > Потому предлагаю убрать опцию direct из wine.
> Так а уже исправлены все проблемы с
> оплоками? Мы же не зря direct вводили.

http://bugs.etersoft.ru/show_bug.cgi?id=5013
Вот тут показано, без direct основные аспекты работают. Наш патч с mandatory-reading это исправляет. Теперь, надо проверить ещё раз на новом etercifs.

> 
> Я пытался соединить со своими изменениями,
> но что-то не увидел в git изменений в HEAD.

Странно, вот, например:
http://git.etersoft.ru/people/piastry/packages/?p=etercifs.git;a=commitdiff;h=85ede0b62793c256b73f1505e77f5d5c2929d187
Comment 18 Vitaly Lipatov 2010-04-10 16:28:30 MSD
(In reply to comment #15)
...
> Потому предлагаю убрать опцию direct из wine.
Вообще вот с этого момента нужно было отдельную багу завести.
Тут сейчас столько дыма будет, что мы потом первоначальную задачу и не вспомним.

> Создал тестовую сборку для 31 и 32 ядер -
> 4.5.1-alt1 - на ftp.
> 
> to baraka: Нужно потестировать 31 или 32 ядра с 1С
> согласно обычной методике + замерить
> производительность по сравнению со старым
> вариантом. Старый вариант можно получить,
> просто монтируя с параметрами wine,direct.
> 

Comment 19 Денис Баранов 2010-04-11 17:18:44 MSD
(In reply to comment #18)
> (In reply to comment #15)
> ...
> > Потому предлагаю убрать опцию direct из wine.
> Вообще вот с этого момента нужно было
> отдельную багу завести.
> Тут сейчас столько дыма будет, что мы потом
> первоначальную задачу и не вспомним.

Создал багу: http://bugs.etersoft.ru/show_bug.cgi?id=5442

Comment 20 Andrey Vusik 2011-02-25 21:09:28 MSK
*** Bug 570 has been marked as a duplicate of this bug. ***
Comment 21 Pavel Shilovsky 2011-02-26 16:43:09 MSK
Сборка 4.7.7 продемонстрировала результаты практически идентичные показателям Windows-клиентов (см. результаты http://bugs.etersoft.ru/show_bug.cgi?id=6773).
Comment 22 Pavel Shilovsky 2011-02-28 19:54:37 MSK
По соглашению с amorozov@, убираю зависимость от 3031.
Comment 23 Pavel Shilovsky 2011-02-28 20:40:59 MSK
Выставляю "исправлена" по результату совещания с lav@. Код из сборки 4.7.7 войдёт в новую сборку 5.0.0.
Comment 24 Денис Баранов 2011-03-24 16:47:36 MSK
Принято.
Comment 25 Pavel Shilovsky 2011-10-26 12:46:38 MSK
(В ответ на comment #23)
> Выставляю "исправлена" по результату совещания с lav@. Код из сборки 4.7.7
> войдёт в новую сборку 5.0.0.

Решено было выпустить промежуточный релиз 4.8.0, то есть исправлено с версии etercifs-4.8.0.