Замедление работы проявляется и на 2-й Linux машине после открытия 1С на первой. Например: I Запускаем 1С на Linux1 - 30 сек. Запускаем 1С на Linux1 - 2,5 мин .... дальнейшие запуски также проходят по 2,5 мин II Запускаем 1С на Linux1 - 30 сек Запускаем 1С на Linux2 - 2,5 мин В то же время запуск 1С на станции WinXP (также по сети) проходит даже быстрее 30 сек III Запускаем 1С на Linux1 - 30 сек Запускаем 1С на WindowsXP - 25 сек Запускаем 1С на Linux1 - 2,5 мин .... дальнейшие запуски на Linux также проходят по 2,5 мин .... дальнейшие запуски на WindowsXP по-прежнему происходят быстро
Дистрибутив 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 хорошо работает. Прям не > нарадуюсь. Это и ваша заслуга, огромное спасибо за тестирование!
Ставлю исправлено.
