@romsan

Доброго всем!
Наверняка, +100500 раз уже обсуждалось. То что, находил, прочел... не помогает
Прошу дать рекомендации для уменьшения времени тормоза работы 1С

Вводная:

Сервер на базе просто мощного ПК
AMD Phenom II x6 1075T (3GHz)
Озу: 12 Гиг
ОС: WinServ2008r2
HDD: SSD-256, Seagate ST2000DM001 (1CH164)
База 1С: 8 Гигов (выполняется ежедневное ТиИ БД по ночам) УТ 10.3 (Платформа 8.2.19.130)
15 терминальных юзеров и 5 сетевых

-------------------------------------------------------------------------------------
В последнее время стали пользователи часто жаловаться на тормоза базы 1С. Предположительно, началось все после подключения 5-ти он-лайн касс (для этого, на рабочих местах были установлены платформы и БД была привязана по сети)
Тормоза проявляются в виде молочно-белого экрана на выполнение любой операции в БД. Однако, по опросу пользователей, это не всегда, а временами происходит. Сервак работает 24/7 Пробовал настроить каждые 2 дня ночной ребут - не помогло. Прогнал хард диск на наличие ошибок - все в пределах норм. БД находится на HDD. (сегодня попробую перенести на SSD)

Что можете еще порекомендовать?

0

@Volexovich

Ну а вы что хотели, подцепив 5 сетевых вы все дружно их ждете(производительность у них ниже), когда они что то пишут, а тут уже многое зависит от сети и машин на которых работает 1с.

0

@romsan

ну не так уж и систематически они обращаются к базе - очередей на кассах нет. ПК не супер-пупер, но и не хлам. Сеть правда сотка... Ну неужели из-за сети? Тогда почему периодически тупизна? Потормозит пару часов.. отпустит...
Главное на серваке ничего не вижу, чтобы мешало работе.... тупо ничего не делается в момент "зависания" БД. Да, и, кстати, зависает БД и в терминале, и на рабочих станциях.
Документ - продажа одной позиции услуги чего то там. Жмет юзер "Провести на основании" и выбирает Ценообразование. Всё... приплыли.... молоко на экране около 2-х минут.... отвисло, можно работать. И главное, именно периодично. А вот с чем связана - у меня пока нет ответа.

0

@Volexovich

Что то логика непонятна. Создает реализацию, потом на основании нее что вводит и зачем?

0

@romsan

Volexovich, обсуждать работу юзеров в ПО давайте не будем. Это их проблемы.... (возможно я не так описал процесс). Суть в том, что 1С иногда тупит по черному.... при этом, спустя какое то время, перестает тупить

0

@Volexovich

0

@romsan

Добавлено через 16 секунд

0

@Volexovich

Нужно понимать в какой момент начинаются тормоза, самая частая причина появления тормазов это нарушение партионного учета. Прежде всего выясните включен ли у вас партионный учет.

0

@romsan

да.

0

@Volexovich

А точка актуальности партионного учета где находится? (Операции - Проведение документов, вкладка востановление последовательностей)

0

@romsan

0

@romsan

а при чем тут партионность? Я описал один из увиденных случаев при котором возникает торможенние. Бухи "плачут" что от обычного фильтра по контрагентам всё "белеет" и "не отвечает" по 1-2 минуты

0

@Volexovich

Это одна из причин. 1С при файловой БД блокиреут записи на уровне таблиц, а это значит, что один тормоз по сети повесит всех пока будет работать с таблицей, будь то журнал или регистр. Журнал документов отследить сложнее, нигде не логируется работа с ним, документ проще, можно проанализировать время формирования проводок в событиях.

0

@Dethmontt

romsan, файловая база по сетке при выполнении запросов, почти ВСЯ летает с клиента на файловый сервер и обратно ))) От этого никак не избавиться, это такая фишка у 1С )))

Добавлено через 42 секунды
Тормоза и сильные появляются уже при 3+ пользователей (особенно при 100мб сетке)

0

@romsan

я, возможно, с Вами соглашусь, но только если можно как то объяснить, что с 8:00 до 13:00 всё работает более ли менее сносно (терпимо в плане тормозов), потом примерно около часа всё "тупит по чёрному", потом всё начинает опять в пределах допустимых работать.
На сл. день с 8:00 до 10:00 всё тормозит, с 10:00 до 14:00 всё в допустимых пределах, с 14:00 до 15:00 тормоза, потом отпускает до конца раб дня.
Нет четкой зависимости. Торговые точки перевели с июля 2018. Претензии начали сыпаться примерно с февраля 2019.
На серваке что либо нового не делалось.
-------------------------------
Два главных вопроса: Кто виноват и что делать?
Кто виноват - предположим сетка.
А вот что делать? Естественно при минимальных затратах. Как улучшить ситуацию? Перенос БД на SSD поможет? (кстати SSD уже под 4 года - надо бы заменить) Заменить сетку на гигабит - очень проблематично (много 4-х жилок лежит. до меня ложили, экономисты хреновы ) Уже поставил Скуль... но опыта переноса и настройки всей этой системы не было, да и торговые как были по сети, так и останутся.
Прошу дать профессиональный взгляд на решение данной проблемы.

0

@Volexovich

1. Перенос на SQL временно может помочь, при условии использования тонких клиентов.
2. Замена диска бесполезна без замены сетки при такой работе с БД.
3. Сложностей с SQL не должно быть, главное разобраться с резервным копированием и обслуживанием БД.

Как и предполагал, у вас затык в партионном учете. Его надо восстанавливать что бы избавиться от тормозов, но это может привести к перевороту остатков.
Точка актуальности должна быть на последнем по времени документе двигающем партии.

Добавлено через 6 минут
Вылезти из 2007 это крайне тяжело, я как то вручную через 3 года пролазил при карт-бланше от бухов на остатки, это был ад длинной в месяц.

Добавлено через 2 минуты
Хотя БД у вас маленькая, оцениваю в 400к документов по партионному учету, так что ничего невозможного не вижу)

1