PSQL 9.1 1C8.3 Тормоза.

1. noven 20.07.15 12:53 Сейчас в теме
Ребята привет!
Стоит 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.
Ребята подскажите куда копать?
Ответы
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
8. AlexO 135 20.07.15 15:20 Сейчас в теме
(1) noven,
PSQL 9.1
Это вы что придумали такое-новое?
2. Зеленоград 20.07.15 13:31 Сейчас в теме
Отключить регламентные задания, перейти на 77.
3. noven 20.07.15 13:46 Сейчас в теме
С первым согласен, со вторым нет :-)
4. noven 20.07.15 13:59 Сейчас в теме
Кстати я уже отключил оказывается регламентные задания.
5. noven 20.07.15 14:13 Сейчас в теме
кажется немного удалось локализовать проблему.
За июнь посчитала за 10 минут, за июль 40 мин.
6. igel9780 171 20.07.15 14:33 Сейчас в теме
VACUUM ANALYZE FULL часто делается?
7. noven 20.07.15 14:41 Сейчас в теме
Раз в неделю. Запуская вручную.
9. noven 20.07.15 16:52 Сейчас в теме
24. Aleksey58 15.02.16 11:17 Сейчас в теме
(9) noven, PGSQL нужно обновить, хотя бы поставить 9.2 или 9.3, avtovacuum не нужно отключать и его правильно уметь настраивать.
10. noven 21.07.15 07:02 Сейчас в теме
Ребята я кажется понял из-за чего.
В июле у нас идут в отпуск 150 человек, у меня есть стойкое подозрение что из-за этого. Но не ужели из-за того может настолько сильно начать тормозить? К примеру в той же базе за июнь считает за 7 минут.
11. KontoraB 21.07.15 08:57 Сейчас в теме
А серверная ось какая ?
12. noven 21.07.15 09:47 Сейчас в теме
Win 2008 enterprise. Только не очень понимаю как может серверная ось влиять на расчет в разных месяцах. Щас бух утверждает что дело не в отпускниках. Проверяю. Но что то же случилось.
13. noven 21.07.15 10:49 Сейчас в теме
Только что замерил производительность тестом Гилева.
Судя про результатам теста то все гуд.
Прикрепленные файлы:
14. noven 22.07.15 09:04 Сейчас в теме
В ЖР обнаружил, что пишется 100 тысч записей в РС Доначисления сотрудникам. Хотя когда захожу в сам РС там нет записей что за прикол?
15. noven 22.07.15 14:40 Сейчас в теме
Ребята в чем же все таки разница в расчете ЗП в файловой, она у нас считает за 3 минуты и в клиент-серверном 40 минут???
23. ansh15 14.02.16 15:26 Сейчас в теме
(15) Платформа 8.3.8.1444, тестовая. Исправили ситуацию, теперь расчет зарплаты весьма быстр.
16. noven 23.07.15 10:56 Сейчас в теме
Ребята залез в код документа, вижу что львиная доля времени теряется на Записать() и Очистить() регистра. Как можно использовать эту информацию для решения проблемы? Она о чем нить может сказать?
17. Gilev.Vyacheslav 1911 23.07.15 15:57 Сейчас в теме
(16) noven,
если копия без нагрузки, то она будет быстрее

надо смотреть план запроса записи, возможно там сканирование всей таблицы, индекса не хватает (да-да, при записи), возможно эскалация так влияет, может по сети данные долго передаются
но 40 минут на 600 человек - это 4 секунды на человека не катастрофа

смотреть в план запроса
18. noven 24.07.15 10:59 Сейчас в теме
поставил MS SQL express. Развернул базу. И о чудо! Все считает за три минуты.
19. noven 24.07.15 11:34 Сейчас в теме
Ребята можно ли на на этом сервере Express пока полноценно поработать? Пока не раскошелимся на покупку нормального?
Размер базы 5 гб
21. starik-2005 3038 26.07.15 13:00 Сейчас в теме
(19) noven, экспресс до 10 гигов ограничение размера базы.

По поводу теста, то результат 4,14 - это очень плохо.

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

В принципе, постгрес может нормально работать. В свое время у яху была самая большая база данных в мире. и работало все это не постгре, и скайп до мелкомягких на нем работал - 20 тысяч запросов в секунду обрабатывались. Но то, что 1С сделала с ним - это [ВЦ]
22. noven 27.07.15 08:03 Сейчас в теме
(21) starik-2005, "Если кеш включить" может быть наоборот выключить?
Конечно нет, приоритет на целостность.
А в MSSQL express ограничения на колво одновременных подкючений нет?
20. ansh15 26.07.15 12:40 Сейчас в теме
Это давно тянется http://forum-1c.ru/index.php?topic=38958.0
Есть даже регистрация проблемы https://bugboard.v8.1c.ru/error/000002673.html
Но, как говорится, воз и ныне там. Отключение hashjoin (enable_hashjoin=off) улучшает ситуацию,
но на платформе 8.2 все равно будет намного быстрее. Сами с этим столкнулись, в итоге оставили ЗиК на 8.2
Оставьте свое сообщение

Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот