Ребята привет!
Стоит XEON E5 2-х процессорный по 4 ядра 2,5 Hz. 32 ОЗУ.
PSQL 9.1 1C 8.3 ЗКБУ типовая.
Расчетчица жаловалась что сильно долго считает зарплата за месяц на 600 чел. Где то 40 минут.
Все параметры в PSQL стояли по умолчанию. effective_cash_size увеличил и поставил 16 гб. Shared_buffers поставил 512 мб. Сделал копию рабочей зарплаты. Так вот в копии стала считаться за 10 минут, прирост производительности увеличился. Копия если че тоже PSQL. Но в рабочей базе так же все медленно. Даже после перезагрузки сервера и при работе одного пользователя. Базы абсолютно идентичны. Ничего не понимаю. Хотя в рабочей базе стала считать 30 минут вместо 40, все таки есть какой то сдвиг. Что еще сделал: в кластере сервера выставил: Интервал перезапуска 86400, допустимый объем памяти 20971520, интервал превышения допустимого объема памяти 30, выкл. процессы останаавливать через 60.
Ребята подскажите куда копать?
Ребята я кажется понял из-за чего.
В июле у нас идут в отпуск 150 человек, у меня есть стойкое подозрение что из-за этого. Но не ужели из-за того может настолько сильно начать тормозить? К примеру в той же базе за июнь считает за 7 минут.
Win 2008 enterprise. Только не очень понимаю как может серверная ось влиять на расчет в разных месяцах. Щас бух утверждает что дело не в отпускниках. Проверяю. Но что то же случилось.
Ребята залез в код документа, вижу что львиная доля времени теряется на Записать() и Очистить() регистра. Как можно использовать эту информацию для решения проблемы? Она о чем нить может сказать?
17.
Gilev.Vyacheslav
191123.07.15 15:57 Сейчас в теме
(16) noven,
если копия без нагрузки, то она будет быстрее
надо смотреть план запроса записи, возможно там сканирование всей таблицы, индекса не хватает (да-да, при записи), возможно эскалация так влияет, может по сети данные долго передаются
но 40 минут на 600 человек - это 4 секунды на человека не катастрофа
(19) noven, экспресс до 10 гигов ограничение размера базы.
По поводу теста, то результат 4,14 - это очень плохо.
По поводу тормозов на записи, то, полагаю, это связано с отключенным кешем в постгри. Если кеш включить, то могут быть проблемы с целостностью базы при сбоях питания, но ведь у вас скорее всего хороший бесперебойник стоит, да?
В принципе, постгрес может нормально работать. В свое время у яху была самая большая база данных в мире. и работало все это не постгре, и скайп до мелкомягких на нем работал - 20 тысяч запросов в секунду обрабатывались. Но то, что 1С сделала с ним - это [ВЦ]
(21) starik-2005, "Если кеш включить" может быть наоборот выключить?
Конечно нет, приоритет на целостность.
А в MSSQL express ограничения на колво одновременных подкючений нет?