Bug 3032

Примером может служить тестовая база Альфа Авто:
ftp/pvt/Windows/1C/1Cv77_configs/Alfa Auto/Avtosalon_work.7z или на cellar в sharewine

Предложение из заявки:
"Проделайте следующее - включите в отладчике замер производительности, попрокручивайте список номенклатуры секунд 10-20, и затем посмотрите, какие строчки выполняются дольше всего в модуле Номенклатура"

У нас воспроизводится?

При перемещении по номенклатуре дольше всего выполняются след функции:
Функция ПолучитьОстаток()
	Если флОстатки=0 Тогда Возврат ""; КонецЕсли;
	Возврат ?(ТекущийЭлемент().ЭтоГруппа()=1, "", 
			  ?(ПустоеЗначение(ВыбПодразделение)=0, РегОТ.СводныйОстаток(ВыбПодразделение,ТекущийЭлемент(),,"Количество"),
			  										РегОТ.СводныйОстаток(,ТекущийЭлемент(),,"Количество")));
КонецФункции	// ПолучитьОстаткок

//-----------------------------------------------
Функция ПолучитьРезерв()
	Если флОстатки=0 Тогда Возврат ""; КонецЕсли;
	Возврат ?(ТекущийЭлемент().ЭтоГруппа()=1, "", 
			  ?(ПустоеЗначение(ВыбПодразделение)=0, РегРез.СводныйОстаток(ВыбПодразделение,ТекущийЭлемент(),,"Количество"),
			  										РегРез.СводныйОстаток(,ТекущийЭлемент(),,"Количество")));
КонецФункции	// ПолучитьРезерв

(In reply to comment #3)
> У нас воспроизводится?
> 
Да, воспроизводится.
Проверял на базе Альфа Авто расшаренной на //cellar/sharewine
etercifs-4.2.1-alt1

Возможно есть какая-то корелляция с багой #3725

Вообще, не понимаю, при чём здесь я.
Но раз повесили буду делать.

Как я вижу для себя ход решения проблемы:
1) трейс по каналу file
2) Выяснение примерного списка функций, вызывамых в момент прокрутки списка номенклатуры
3) Создание тестов по замеру времени и уточнение списка "медленных" функций
4) Исправление

Мне кажется, что есть кореляция с 3759. 
Функция Регистр.СводныйОстаток производит чтение из разных областей файла регистра. Вполне возможно (попробую на досуге проверить), что в момент чтения устанавливается блокировка на весь файл, что, как известно, делается установкой блокировки на запись в байт лежащий за концом файла. Большие тайминги (см. 3759) при попытке получить блокировку могут быть причиной медленной работы.
Кроме того, пока цифс ждет ответный пакет, полностью блокируется исполнение 1с (она мертво висит), это хорошо объясняет накопление событий в буфере клавиатуры (у вашего клиента это проявляется большой инерционностью при отпускании клавиши).

Костя нашел интересную информацию по поводу отрисовки:
http://unixforum.org/index.php?showtopic=90639&view=findpost&p=851301 
Надо посмотреть на отрисовку шрифтов.

Да-да. Надо посмотреть. Правдо дело наверное не совсем в шрифтах.
http://bugs.etersoft.ru/show_bug.cgi?id=3911

(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

Нужно проверить ещё раз на 1.0.11
Возможно рассмотреть с Сашей причины замедления.

В общем ситуация следущая. База взята из поста #1.

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

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

Странно, что поведение в одиночном случае отличается - у Linux они посылаются, e Windows - нет. Когда в базе оба клиента, то запросы на блокировки посылают и Linux, и Windows.

(In reply to comment #13)
...
> Причина в следующем: При просмотре списка
> номенклатуры очень много происходит
> запросов на блокировки.
У нас как-то замедленно работают блокировки? Была же какая-то эпопея с неким параметром и задержкой на блокировку, вроде даже в документации описана настройка Самбы.

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

(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.

(In reply to comment #15)
> Я имел ввиду не монопольный режим, а режим
> работы с одним пользователем в базе. Здесь
Думается мне, в данном случае совершенно не важно, монопольно открываются файлы или нет - при одном пользователе оплок всё равно выдаётся.

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

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

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

> Создал тестовую сборку для 31 и 32 ядер -
> 4.5.1-alt1 - на ftp.
Я пытался соединить со своими изменениями, но что-то не увидел в git изменений в HEAD.
 

(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

(In reply to comment #15)
...
> Потому предлагаю убрать опцию direct из wine.
Вообще вот с этого момента нужно было отдельную багу завести.
Тут сейчас столько дыма будет, что мы потом первоначальную задачу и не вспомним.

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

(In reply to comment #18)
> (In reply to comment #15)
> ...
> > Потому предлагаю убрать опцию direct из wine.
> Вообще вот с этого момента нужно было
> отдельную багу завести.
> Тут сейчас столько дыма будет, что мы потом
> первоначальную задачу и не вспомним.

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

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

Сборка 4.7.7 продемонстрировала результаты практически идентичные показателям Windows-клиентов (см. результаты http://bugs.etersoft.ru/show_bug.cgi?id=6773).

По соглашению с amorozov@, убираю зависимость от 3031.

Выставляю "исправлена" по результату совещания с lav@. Код из сборки 4.7.7 войдёт в новую сборку 5.0.0.

Принято.

(В ответ на comment #23)
> Выставляю "исправлена" по результату совещания с lav@. Код из сборки 4.7.7
> войдёт в новую сборку 5.0.0.

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