Имеется следующая информация от Хронобуса по тестированию 1С:Хронограф 2.5: 1) база расположена локально - чуть меньше минуты; 2) база расположена на сетевом ресурсе, но на этой же станции - чуть больше 8-ми минут; 3) база расположена на сетевом ресурсе Windows Server 2003 - около 38-ми минут; 4) база расположена на сетевом ресурсе AltLinux Server 5.02 - примерно 48 минут. Все замеры выполнялись для одной и той же Демо-базы, на одной и той же рабочей станции AltLinux Master 5.01 (с последними обновлениями), подключенной через проводной сетевой интерфейс. Обновление выполняется путём запуска файла обновления, например /var/ftp/pvt/Windows/School/1C:Hronograf\ Sch\ 2.5/UpDate к обычной установленной конфигурации. Для начала нужно воспроизвести результаты, добавив пункт 5) про базу на сетевом ресурсе по NFS. Тестировать на etercifs 4.5.3 и 4.7.7
В 6711 мы уже тестировали обновление... Здесь нам будет важно именно Школьный Вайн проверить с разными CIFS. Есть информация, что на нём существенно тормозит, вот и будем ускорять.
Хочется заметить, что etercifs-4.7.7 содержит исправления, влияющие на скорость работы только для 37 ядра. Таким образом тестировать на других ядрах его не имеет особого смысла (на них он практически идентичен 4.5.3).
(В ответ на comment #2) > Хочется заметить, что etercifs-4.7.7 содержит исправления, влияющие на скорость > работы только для 37 ядра. Таким образом тестировать на других ядрах его не > имеет особого смысла (на них он практически идентичен 4.5.3). 1. Хорошее замечание. В случае успеха эти исправления могут быть перенесены на младшие ядра? 2. То есть на ALT Linux потестить не получится (есть только 2.6.36)
Машина в vbox AltLinux 5.0.2 school-master etercifs 4.5.3 Подтверждаю заявленные результаты. (У меня все было чуть быстрее)
(В ответ на comment #4) > Машина в vbox AltLinux 5.0.2 school-master > etercifs 4.5.3 > Подтверждаю заявленные результаты. (У меня все было чуть быстрее) Отлично. Как ты теперь проверишь с etercifs 4.7.7 ?
(В ответ на comment #3) > (В ответ на comment #2) > > Хочется заметить, что etercifs-4.7.7 содержит исправления, влияющие на скорость > > работы только для 37 ядра. Таким образом тестировать на других ядрах его не > > имеет особого смысла (на них он практически идентичен 4.5.3). > 1. Хорошее замечание. В случае успеха эти исправления могут быть перенесены на > младшие ядра? Да. > 2. То есть на ALT Linux потестить не получится (есть только 2.6.36) Я уже портировал эти исправления для 35 ядра, но в сборки etercifs пока не включал. Включить их в новую сборку 4.7.8 недолго. Если же нужно всё-таки именно 32 ядро, могу портировать и под него, но времени уже больше потребуется. night@, тебе как удобнее тестировать будет?
Проверять теперь надо на сборке 4.7.9, там поддержка ядра 2.6.35
(В ответ на comment #7) > Проверять теперь надо на сборке 4.7.9, там поддержка ядра 2.6.35 а также ядра 2.6.32.
(В ответ на comment #7) > Проверять теперь надо на сборке 4.7.9, там поддержка ядра 2.6.35 Улучшений не увидел. И опять же. Правильные ли параметры на сервере? (level2 oplocks = no выключен, и включен strict locking = yes)
(В ответ на comment #9) > Улучшений не увидел. А известны ли результаты данного теста на Windows клиентах? Если там быстрее, то имеет смысл снять траффик выполнения теста и там и там и потом сравнить, каких комманд cifs клиент посылает больше. > И опять же. Правильные ли параметры на сервере? > (level2 oplocks = no выключен, и включен strict locking = yes) Первый правильно, второй лучше убрать (подробности см в http://bugs.etersoft.ru/show_bug.cgi?id=6766#c24). А что по поводу результатов для NFS?
На windows все происходит за 2 минуты. Через nfs пока не удаётся настроить. Пробовал строки: /var/local/share 192.168.0.0/16(rw,no_subtree_check) /var/local/share 192.168.0.0/16(rw,no_subtree_check,sync,no_root_squash,anonuid=500,anongid=500,fsid=7) Монтирую как в документации: mount -t nfs -o rw,soft,nointr При входе в базу - вылетает.
Были неправильные права. На nfs обновление длится минуты 3.
(В ответ на comment #11) > На windows все происходит за 2 минуты. имеется ввиду при работе с базой на удалённом ресурсе или на локальном?
> имеется ввиду при работе с базой на удалённом ресурсе или на локальном? все проверялось с базой на удаленном сервере cellar
Таким образом, на лицо видно замедление работы при использовании etercifs. Для выявления критического участка, просьба снять следующие показатели: 1) tcpdump -i <interface> -s 65535 -w windows.pcap на сервере при работе windows клиента. 2) tcpdump -i <interface> -s 65535 -w linux.pcap на сервере при работе linux клиента. 3) для linux клиента так же сделать 'echo 1 > /proc/fs/cifs/cifsFYI' и привести кусочек dmesg вывода (10^5 строк).
(В ответ на comment #15) > Таким образом, на лицо видно замедление работы при использовании etercifs. Для > выявления критического участка, просьба снять следующие показатели: > 1) tcpdump -i <interface> -s 65535 -w windows.pcap на сервере при работе > windows клиента. > 2) tcpdump -i <interface> -s 65535 -w linux.pcap на сервере при работе linux > клиента. > 3) для linux клиента так же сделать 'echo 1 > /proc/fs/cifs/cifsFYI' и привести > кусочек dmesg вывода (10^5 строк). Кое как сделал. Но пока только для linux (В Windows через vbox это сделать проблематично - сделаю в офисе). Лежат в /var/ftp/pvt/Windows/Testing/Bugs/6967
Исследовал проблему и обнаружил, что забыл добавить strictcache режим в опцию wine. Исправил, протестировал с RECT и выложил на ftp новую сборку 4.7.10.
(В ответ на comment #17) > Исследовал проблему и обнаружил, что забыл добавить strictcache режим в опцию > wine. Исправил, протестировал с RECT и выложил на ftp новую сборку 4.7.10. Улучшений не увидел. Новые файлы теста в /var/ftp/pvt/Windows/Testing/Bugs/6967
(В ответ на comment #18) > Улучшений не увидел. Новые файлы теста в /var/ftp/pvt/Windows/Testing/Bugs/6967 Файлы не информативны - начинается с операций чтения/записи, а открытия файлов перед этим нет. Просьба снять траффик именно с самого начала обновления конфигурации. Так же интересует такой вопрос: я так понимаю, что обновление происходит с одного клиента, подключенного к базе или сразу с нескольких?
> Файлы не информативны - начинается с операций чтения/записи, а открытия файлов > перед этим нет. Просьба снять траффик именно с самого начала обновления > конфигурации. > Готово. И для win и для lin. Сначала и до конца. Трафик через cifs в 7 раз больше. > Так же интересует такой вопрос: я так понимаю, что обновление происходит с > одного клиента, подключенного к базе или сразу с нескольких? Нет. Работает только один клиент.
Спасибо, буду разбираться.
Способ воспроизведения: На машине ALTLinux 5.0.2 school-master в vbox есть ~/.wine На диске c: два exe файла с обновлениями. Я использовал первый. Там же база SchoolPrDemo. После каждого обновления для последующей проверки ее следует заливать на сервер. Собственно, для проверки запускаем этот первый exe с обновлением и выбираем нужную базу. Всё.
Исследовал проблему. Обновление шло медленно из-за невыставления оплоков для вновь созданных (и открытых) файлов. Вследствии этого, режим работы модуля не отличался от режима direct. Исправил в новой сборке 4.7.11 и выложил на ftp. Среднее время обновления стало чуть меньше 2 минут. night@, просьба проверить новую сборку на работу с обновлением, а также основные аспекты работы 1С.
Обнаружил данную ошибку и в 35 ядре. Исправил и поправил код для обоих ядер (32 и 35). Протестировал на локальных тестах и выложил ветки на git.eter. Далее займусь тестированием с Обновлением конфигурации. Сборку 4.7.11 пока лучше не тестировать - сразу потом попробовать новую 4.7.12, как я её выложу.
Собрал 4.7.12 - можно тестировать на скорость обновления и по обычной схеме. Исправления для 32 и 35 ядра.
(В ответ на comment #25) > Собрал 4.7.12 - можно тестировать на скорость обновления и по обычной схеме. > Исправления для 32 и 35 ядра. Обновляется за минуту. По обычной схеме гляну чуть позже.
Задача, поставленная в данной баге решена.
