@zionkv
Системный администратор Windows\Linux

Как можно отследить узкое место файловой 1Сv8.1 по сети?

Имеется главный офис, удаленные филиалы и распределенная 1С v8.1 объемом >3GB. Обмен происходит по FTP за неимением других средств.



В удаленных филиалах стоит по две машины: PC1, PC2. На машинах стоят:



ОС: Windows XP со включенной SRP (т.е. антивирусов нет).

Сеть: PC1 и PC2 соединены через свич 100mbps и получают адреса DHCP от ADSL-модема.

Сетевые адаптеры: интегрированные realtek.

Процессоры: Celeron ~2gHz, Atom ~2x1.66gHz.

ОЗУ: ~1gB.

ЖД: обыкновенные барракуды 7200rpm

Логическая структура разделов ЖД: 2гБ — файл подкачки, 15гБ — раздел под базу, 40гБ — системный раздел, 25гБ — раздел под бэкапы. Раздел подкачки и БД имеют размер кластера = 64кБ.

Доступ к БД: Для PC1 путь к БД имеет вид: x:\base\, для PC2 имеет вид: \\PC1\base\



Все вышеперечисленное было сделано по наитию и дало прирост производительности на PC1 >200% относительно первоначального положения.



Основные задержки происходят при поиске в БД считанного сканером штрих-кода товара, либо дисконтной карты (30 -> 7 сек. после оптимизации)



На данный момент ситуация такова: PC — летает, никто не жалуется на пятисекундные задержки, но на PC2 задержки доходят до 30-40сек при создании нового чека, при поиске дисконтной карты. Самое обидное, что в момент подвисания я не вижу никакой нагрузки на сеть и процессоры. Хотелось бы узнать практические советы и ссылки на полезную информацию.



В интернете читал много, но там в основном про оптимизацию под SQL и RDP, что меня совершенно не уместно. Говорят, можно чистить логи каждый день, подумываю еще подключить сетевой диск, чтобы PC2 смотрел в путь x:\base — есть смысл?
  • Вопрос задан
  • 5396 просмотров
Решения вопроса 1
foxmuldercp
@foxmuldercp
Системный администратор, программист, фотограф
SQL? дорогостоящий? первая ссылка в гугле по ключевым словам «1c postgres» ведет на v8.1c.ru/overview/postgresql.htm

postgres, как и mysql бесплатны.

Да, перевести 1с на постгрес займет денег и времени, но уберёт все костыли в виде фтп, кривых шар, и тормозов
и добавит гибкости решению и централизованности хранения и резервных копий баз.
Ответ написан
Пригласить эксперта
Ответы на вопрос 9
@xrd
Чините сеть. На двух пользователях (к тому же таких) файловая база 1С не тупит, SQL не спасет.
Ответ написан
pythonchik
@pythonchik
в режиме отладки на «тормозной» машине сделать замер производительности. А потом посмотреть, на какое действие уходит много времени.
А уж потом можно будет понять, что проще сделать — код оптимизировать или железом заниматься
Ответ написан
Qwadrat
@Qwadrat
Если на PC1 закрыть 1С — тормозит ли PC2?
Посмотрите с помощью perfmon на PC1 очередь диска
Ответ написан
@DanXai
Поменять машины местами. Попробовать обращаться к по ip в пути к базе. Отключить теневое копирование. Проверить DNS. Пошаманить как-то…
Если решите проблему — отпишитесь, пожалуйста.
Ответ написан
@cepera_ang
Тупит, потому что файловая 1С по сети. Сделайте самый бюджетный вариант терминального сервера — патчем разблокируйте подключение по терминалу нескольких пользователей на win xp. Подключайтесь к PC1 с PC2 удаленным рабочим столом и будет так же быстро.
Ответ написан
SLIDERWEB
@SLIDERWEB
ИТ-Куроводитель
Я не гуру в 1С, но сдается мне что узкое место это ОЗУ: ~1gB + обращение к базе по сети да по 100 Мбит.
Интересно есть ли рейд на PC1. + 6 чувство мне подсказывает, что при обращении по UNC PC2 сначала разрешает сетевое имя, получает листинг шары, загружает в память файлы базы, соответсвующие области поиска, а уже потом осуществляет по ней поиск.
Как вариант можно попробовать подцепить \\PC1\base\ диском к PC2 и посмотреть что будет… иногда это спасает.

Вариант еще более правильный — разжиться высокопроизводительным сетевым хранилищем на SAS и дать доступ обеим машинам к базе по шине в 4-6 Гбит.
Ответ написан
beho1der
@beho1der
Самый правильынй вариант переходить на SQL, я сомневаюсь что тут затык в сети для эксперимента посмотрите на коммутаторе статистику или через какие-нибудь проги на локальных местах. И надо добавить еще памяти опредленно!
Ответ написан
rtzra
@rtzra
Почему не хотите использовать работу в терминальном режиме уж коли SQL вам не подходит? А вообще у вас всегда будут тормоза по той простой причине, что загрузка каналов у любого провайдера может быть разной. При этом вы по сети будете таскать все больший и больший объем данных.
Ответ написан
@dance000
И всеже поставтье на один из ПК вин2003 (если не хотите открывать терминал в винХР)
узкое место именно сеть.
Файловая работа предполагает постоянное таскание файлика базы (или его части) по сети.
3 гига - не много, но все зависит от того чем у вас забиты эти 3 Гига.
Возьмите ToolCD и посмотрите что у вас занимает больше места в базе.
Но это все мелочи. Повторюсь главное решение - терминал!
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы