Ситуация возникла на пустом месте, все работало нормально, потом что-то где то обновилось и через некоторое время выяснилось, что 1С стоить анализ субконто 30 минут, а баланс генерируется часами. Разборки заняли сутки и источник проблемы нашел абсолютно случайно.
Итак, для понимания, есть файловая база 1С, она лежит на samba (v3) под Free BSD. К ней доступ имеют 2 настоящие машины в локальной сети и одна виртуальная машина на том же сервере в VirtualBox с RDP доступом.
Действующие лица:
1) Ядро FreeBSD
2) Virtio драйвер FreeBSD
3) VirtualBox
4) Samba
5) Сама Windows 7
6) 1C 8.3
Проблема возникла именно с тормозами в 1С в виртуальной машине. На обычных компах все работало шустро.
Самое простое это было сразу обновить ядро с драйвером virtio и VirtualBox. Ничего не дало. Тормоза как были, так и остались. Причем иногда проскакивало, что начинало работать быстро, но потом опять утормаживалось.
Начались копания в конфигурации samba. В итоге samba была обновлена до Samba4. Эффект нулевой.
Мониторинг работы с сетью в виртуалке показывал нормальную скорость в 30-40 Мбит/сек.
По ходу разбирательств случайно (т.е. методом простого наблюдения, пока отрабатывались другие теории), выяснилось, что тормоза начинаются как только входит второй пользователь 1С. Выход второго пользователя скорость не повышает.
smbstatus показал, что пока клиент один, у него работает oplock EXCLUSIVE, но как только входит второй пользователь, то становится NONE. При выходе второго NONE так и остается. Изучаение работы oplock показало, что так и должно быть. Кроме того, полное выключение oplock в самбе не влияет на скорость работающих по сети реальных машин.
Включил логи в samba (level 3). Сразу выяснилось, что при работа с файлов базы 1С в виртуалке читает порциями по 4096 байт и для каждого чтения устанавливается flock. Кажется безумием. Но в начале, когда быстро, оно тоже так работает.
Отключил posix lock в samba. Блокировки пропали, но скорость так и падала после второго пользователя. Еще логии показали, что машины в сети работают с самбой по протоколу NT LM 0.12 (SMB1), а машина в виртуалке по SMB2_FF.
Редакции Windows 7 отличились. Прошла бессонная ночь, результат нулевой.
Перелил базу на Win7 машину, расшарил, попробовал – те же проблемы. Вернул все на самбу.
Решил на завтра сделать еще одну виртуалку под той же редакцией Win7 и посмотреть.
Настраиваю виртуалку, ставлю Win7, ставлю 1C, добавляю базу, открывают – все летает. Запускаю 1С на всех машинах – везде летает. Открывают лог самбы – новая виртуалка тоже по SMB2 работает. И тут меня посещает смутное сомнение.
Иду в оригинальную виртуалку и в базе 1С прописываю не пусть через смонтированный сетевой диск, а прямой сетевой путь \\... И ВСЁ! Все начинает летать еще и быстрее чем было (самбу-то я оптимизировал). Анализ субконто – 3 секунды, со всеми пользователями одновременно. Снова ставлю через букву диска – дикие тормоза.
Понятно, что видимо при подключении через смонтированный диск Windows начинает с ним работать как с локальным и видимо это совсем не совместимо с сетевой природой этого диска, но что именно – пусть уж другие копаются.
Было ли там такое подключение изначально или я потом его добавил сейчас уже не вспомню. Но знаю почему я так сделал.
Сделано через сетевой диск было из-за того, что Win7 отказывается запоминать реквизиты доступа к сетевому ресурсу, хоть ставка галку, хоть нет. При перезагрузке данные пропадают и базу подключить не выходит. А для диск реквизиты запоминаются .
Осталось загадкой, почему реальные машины ходят по SMB1, а виртуалки по SMB2. Дело, конечно не в реальности или виртуальности. Виртуальные машины вообще не обновляются, а на реальных машинах стоят почти все обновления. Есть подозрение, что какое-то из обновлений для Win7 отключает SMB2 по умолчанию. Но мне это уже тоже не важно.