Bug 2915

Дистрибутив ALT Linux 4.0 Lite (проблема замечана пока на 4.0.2)
Гетерогенная среда. Файловый сервер WindowsXP SP2.
Скорость обращения к файлам бд со станции Linux (1С v77 релиз 27,dbf) в разделенном доступе падает в 5 раз. Т.е. когда один пользователь уже вошел в 1С, вне зависимости откуда был произведен первый вход (Linux или Windows), вне зависимо от последовательности входа. Скорость доступа с WindowsXP не ухудшилась.
Etersoft Wine 1.0.9

Зависимость от оборудования не подтвердилась: пробовали разные комбинации на 2-х машинах, меняли сетевые карты.
Выявлена зависимость от дистрибутива: у нас ALT Linux 4.0.2 Lite, последнюю версию 4.0.3 только собираемся проверять.

Попробовали дистрибутив ASP Linux 12 - проблем с etercifs там нет

Дистрибутив ASP Linux 12, ядро: 2.6.22.9-91.012.0 ASP
Проблемный дистрибутив ALT Linux 4.0 Lite: ядро 2.6.18-std-smp-alt10 

Дистрибутив ALT Linux 4.0 Lite. Последние использованные с этим дистрибутивом пакеты:
    etercifs-3.8.0-alt0.M40.2.noarch.rpm
    libwine-1.0.9-alt0.M40.34.i586.rpm
    wine-1.0.9-alt0.M40.34.i586.rpm
    wine-etersoft-sql-1.0.9-alt0.M40.13.i586.rpm

Строка монтирования:
    mount –t cifs //192.168.8.185/astor /mnt/net/astor –o user=user,pass=111,uid=user,gid=user,file_mode=0660,dir_mode=02770,iocharset=utf8
Точка монтирования подключена в wine через symlink как каталог на диске D: (symlink /mnt/net/astor  -> ~/D:/astor)

Используем файловый сервер на Windows XP pro + SP2

Режим запуска 1С в wine устанавливаем: NT4.0, 
т.к. коммерческая компонента Торговый Дом Астор 5.0 (разработчик Астор ВЦ г. Москва) работает только в этом режиме. Режим подобран эксперементально 
в других режимах вообще не работает (1c прекращает работу при попытке подключения компоненты)
__________________________________________________

Взяли ALT Linux Desktop 4.1. Проблем с etercifs нет.
Значит проблема в дистрибутиве ALT Linux 4.0 Lite.

etercifs-3.8.0-alt0.M41.5.noarch.rpm
libwine-1.0.9-alt0.M41.35.i586.rpm
wine-1.0.9-alt0.M41.35.i586.rpm
wine-etersoft-sql-1.0.9-alt0.M41.13.i586.rpm

> __________________________________________________
> 
> Взяли ALT Linux Desktop 4.1. Проблем с etercifs нет.
> Значит проблема в дистрибутиве ALT Linux 4.0 Lite.
> 
> etercifs-3.8.0-alt0.M41.5.noarch.rpm
> libwine-1.0.9-alt0.M41.35.i586.rpm
> wine-1.0.9-alt0.M41.35.i586.rpm
> wine-etersoft-sql-1.0.9-alt0.M41.13.i586.rpm
> 

А может быть проблема проявляется для всех дистрибутивов линейки ALT Linux 4.0, в смысле не только Lite, но Desktop? Если это так, то проблема скорее всего в ядре...

Насколько эта проблема актуальна для ALT Linux 4.0, при вышедшем 4.1? Если актуальность имеет место быть, то я бы посоветовал установить более свежее ядро. Думаю, что для этого стоит брать 2.6.24 из архивов старого сизифа... Готов помочь в поиске нужного ядра, если это действительно сейчас требуется...

Если проблема с ядром подтвердится, то я думаю, что etercifs, в данном случае, либо устаревший (и нужно адаптировать новые исходники под старое ядро), или вообще здесь не причём (тогда нужно просто обновлять ядро)... Причём 2.6.18 ядрам ветки 4.0 я не очень доверю, поскольку баги там имеются неисправимые...

(In reply to comment #4)
> > __________________________________________________
> > 
> > Взяли ALT Linux Desktop 4.1. Проблем с etercifs нет.
> > Значит проблема в дистрибутиве ALT Linux 4.0 Lite.
> > 
> > etercifs-3.8.0-alt0.M41.5.noarch.rpm
> > libwine-1.0.9-alt0.M41.35.i586.rpm
> > wine-1.0.9-alt0.M41.35.i586.rpm
> > wine-etersoft-sql-1.0.9-alt0.M41.13.i586.rpm
> > 
> А может быть проблема проявляется для всех
> дистрибутивов линейки ALT Linux 4.0, в смысле не
> только Lite, но Desktop? Если это так, то проблема
> скорее всего в ядре...
> Насколько эта проблема актуальна для ALT Linux
> 4.0, при вышедшем 4.1? Если актуальность имеет
> место быть, то я бы посоветовал установить
> более свежее ядро. Думаю, что для этого
> стоит брать 2.6.24 из архивов старого сизифа...
> Готов помочь в поиске нужного ядра, если
> это действительно сейчас требуется...
> Если проблема с ядром подтвердится, то я
> думаю, что etercifs, в данном случае, либо
> устаревший (и нужно адаптировать новые
> исходники под старое ядро), или вообще
> здесь не причём (тогда нужно просто
> обновлять ядро)... Причём 2.6.18 ядрам ветки 4.0
> я не очень доверю, поскольку баги там
> имеются неисправимые...
Проверили работу ALT Desktop 4.1. Версия ядра: 2.6.25. Оставили в нем только XFCE (из-за чего и начинали с ALT 4.0 Lite) - вполне устраивает. Etercifs работает. 1С v77(DBF,net) в монопольном режиме даже быстрее, чем на WinXP. В сетевом режиме описанного в начале замедления нет, но присутствует другое:
в совместном режиме производительность на Linux приблизительно в 2 раза ниже, чем на WinXP (проверяли только на ряде самописных отчетов 1С)

По поводу медленного совместного режима - ждём решения по 3031.

Бага нам не дает перейти с виндов на wine.
Тормозят расчеты и отчеты.
Копирование с примаунченой шары файла из рабочей базы идет со скоростью 1 МБ/с, если же делать это в наутилусе через smb://, то 6-7 МБ/с.

Вход в систему (время от появления сплеша, до окна ввода имени пользователя) 1-25 сек прямо пропорционально количеству пользователей в 1С. Связь подтверждает tcpdump:
16:18:04.117143 [P.] на сервер
SMB PACKET: SMBlockingX (REQUEST)
Offset=10000002 (0x989693)
Length=1 (0x1)

16:18:04.117437 [.] с сервера
16:18:04.117485 [P.] с сервера
SMB PACKET: SMBlockingX (REPLY)
Error class   =  0x55
Error code    =  49152 (0xc000)
NTError = STATUS_LOCK_NOT_GRANTED

16:18:04.117546 [P] на сервер
SMB PACKET: SMBlockingX (REQUEST)
Offset=10000002 (0x989693)
Length=1 (0x1)

16:18:04.156992  [.] с сервера
!!! во какой тайминг! !!!
16:18:04.321642  [P.] с сервера
SMB PACKET: SMBlockingX (REPLY)
Error class   =  0x54
Error code    =  49152 (0xc000)
NTError = STATUS_FILE_LOCK_CONFLICT

16:18:04.321971 [P.] на сервер
SMB PACKET: SMBlockingX (REQUEST)
Offset=10000003 (0x989694)
Length=1 (0x1)

тоже самое при входе виндового клиента выглядит гораздо более вменяемо:
21:56:55.949302 [P.] на сервер
SMB PACKET: SMBlockingX (REQUEST)
SMB Command   =  0x24
Offset=10000002 (0x989682)
Length=1 (0x1)

21:56:55.949345 [P.] с сервера
SMB PACKET: SMBlockingX (REPLY)
SMB Command   =  0x24
Error class   =  0x55
Error code    =  49152 (0xc000)
NTError = STATUS_LOCK_NOT_GRANTED

21:56:55.949671 [P.] на сервер
SMB PACKET: SMBlockingX (REQUEST)
SMB Command   =  0x24
Offset=10000003 (0x989683)
Length=1 (0x1)

Т.е. основные тормоза происходят при попытке установить lock за концом файла для индикации занятости базы из-за повторного запроса на lock.
Когда и зачем посылается второй запрос при получении STATUS_LOCK_NOT_GRANTED
я в исходниках найти не смог. Но это очень-очень плохая бага! Поправте побыстрее плиз.

Скорость передачи через CIFS не должна значимо отличаться.
По поводу неоптимального порядка установки блокировок
заводить отдельную багу? Думаю, нужно оптимизировать
установку блокировки из Wine, возможно, добавлением
вызовов в fcntl с необходимой виндовой семантикой.

На версии 4.3.2 скорость по cifs нормальная, не отличается ни от smb:// ни от виндовых машин.
Бага отдельная по блокировкам уже есть (3759).
Вообще -- на 4.3.2 хорошо работает. Прям не нарадуюсь.

(In reply to comment #9)
> На версии 4.3.2 скорость по cifs нормальная, не
> отличается ни от smb:// ни от виндовых машин.
Ну отлично.
> Бага отдельная по блокировкам уже есть (3759).
> Вообще -- на 4.3.2 хорошо работает. Прям не
> нарадуюсь.
Это и ваша заслуга, огромное спасибо за тестирование! 

Ставлю исправлено.