Конфликт блокировок на Postgre поможет ли MS SQL? #569873

На данный момент жуткие тормоза. УТ 10.3.5 сильно модифицированная. win 2003 8 Гб ОЗУ 2.33 Гц Xeon E5345 (2 процессора) 25 Пользователей за август около 2000 документов реализаций с количеством строк средним 25 Все работают в терминале Рассматриваются варианты 1. Перевести на управляемые блокировки 2. Поменять железо 3. Поменять СУБД (купить MS SQL) 4. Выгнать всех с терминала, таким образом высвободив ОЗУ сервера Сразу скажу дуб в этом вопросе. Прошу помощи.

можно же просто попробовать. я думаю 80% - да, поможет.

"Сильно модифицированной" вряд ли уже чего поможет. Это ж надо теперь все доработки по очереди переписать под клиент-сервер чтобы выгнать народ с терминала, потом еще и на управляемые блокировки перевести... а автор даже диагностикой не удосужился. "У меня правая рука почернела, посоветуйте, что лучше - уринотеропия или грязевые ванны? Врач? Не, не знаю такого."

все доработки и так в соответствии с "клиент-серверной" логикой 8.1 мы ищем самый дешевый и действенный способ чтобы "жар сбить".

есть еще вариант - заменить всех программистов.... по сабжу 1. определитесь на каких таблицах идет блокировки 2. найти код в программе вызывающий блокировки 3. думать... перевод на SQL - вероятно поможет частично, но это не панацея

кстати сколько времени проводится один документ в МОНОПОЛЬНОМ режиме? замерь... если более 2х секунд - требуется оптимизация проведения

Не поможет, правильно пишет ковыряй переделки, Проведение, блокировки

Да ну? А чего ж тогда звери-то в терминале пасутся, м?

так повелось с тех пор когда база еще файловая была но сейчас-то на постгре.. вот как только на него перевели так головняк и схватили с переделками. Вот я и говорю, что точно переделали переделки.

У нас постгрес не пошел именно из-за блокировок. типовая УПП.

Поставь скуль пробный должно помочь. Ускорится в 2 раза. И винты ссд - и все будет летать. Только помни ссд слетают быстро.

аналогично. либо долго пилить блокировки

Во-первых,  выгнать всех из терминала или завести отдельный терминальный сервер. Это же звиздец 25 терминальных сессий, СУБД и сервер 1С на 8 гектар памяти О_о.... Такая помойка в принципе не может работать быстро. Хоть скуль от MS ставить, хоть DB2, хоть что.

Кстати так и не понял. В шапке "конфликт блокировок", а в об этом ни слова (только про тормоза). Так есть конфликты блокировок или нет?

Не удивлюсь, если на этом серваке еще и AD живет с почтовиком и интернет-шлюз...

долго-долго висит а потом сообщение про конфликт блокировок :)

только терминал :)

Короче однозначного ответа на ваши вопросы просто нет. Надо делать диагностику, искать узкие места. В любом случае терминал переносить на отдельный сервер. А если клиентские машины не совсем дохлые, то вообще от терминала отказаться. Пусть все работают на своих машинах. В любом случае добавить мозгов на сервер. 8Гб слишком мало даже если там только сервер СУБД с сервером 1С останутся. В любом случае посмотреть дисковую подсистему. Это узкое место любой СУБД. Ну а уже потом проводить повторное тестирование и анализировать результаты.

нет, переписывай алгоритмы по нормальному

кстати, 25 юзеров * 200-250 мБ = аж 6 гигов из 8 занято тупо юзерами

25 пользователей - это сжирает 5 гигов + сервер 1с это еще гиг + гиг на систему - бедному SQL остается гиг памяти. Но скорей всего он сжирает память и не дает памяти ни программе, ни серверу 1с. Терминал в топку - нафига он вообще нужен непонятно. постгри может и не тянуть без управляемых блокировок он блокирует всю таблицу. Если нету денег ставьте DB2 - он шустрый мало уступает MSSQL и бесплатный в вашем случае. И обязательно копаться в настройках чтоб SQL не сжирал всю память - нужно гиг оставить на сервер 1с и гиг на систему.

2000 доков за 8*20*3600 секнунд = 0,035 документа в секунду - объемы детские

ДБ2 экспресс на базах больше 50 ГБ - большой геморрой

Кстати, совсем не факт, что ТС настраивал ini-шники постгри под ресурсы сервера, а по умолчанию там настройки просто смешные. Естественно, что про анализ конфы и блокировок рулит, но и ПО и железо сервера требует настройки.

Насчет "8Гб слишком мало" - не стоит торопиться. У меня сервер 1С+PostgreSQL под OpenSuSE, УТ 10.3 на 10 юзеров(5 активных) работал на вирт.машине(VirtualBox), которой было отдано 1 ядро и 1,5 Гб RAM(больше не позволяло железо сервера - устаревшее, всего было 4 ядра и 4 Гб RAM). VirtualBox работал под 2003 сервером. Почему возникла такая связка - вопрос отдельный и не в моих силах было что-то изменить в железе и ПО. Важно другое - эти юзеры работали вполне нормально. Так что 25 юзеров на типовой(!) УТ 10.3 при прямых руках на указанном железе вполне могут работать. Естественно, что все посторонние функции с сервера надо убирать, код анализировать на предмет бутылочных горлышек и ПО настраивать по уму.

+ Не верю я в постгре собранный под винду

1)Реальность от твоей веры зависит очень мало. 2)Учись читать. Где я в сказал, что постгри под винду? Выдержки -"PostgreSQL под OpenSuSE ... на вирт.машине(VirtualBox)... VirtualBox работал под 2003 сервером".