v7: Тормозит 1С 7.7 #749094


#0 by skyadmin
Есть база Торговля+Склад, свернутая на начало года. Работает на терминальном 30-35 пользователей, на сервере 2 ксеона (24 ядра) нагрузки нет рейд0 из 2х SSD дисков, нагрузки нет 32гб ОЗУ, свободной полно. Но база тормозит, иногда ожидание транзакции превышает 30 сек, может есть какая-то волшебная кнопка, быстро работать?
#1 by vladko
файловая или скуль?
#2 by skyadmin
Файловая
#3 by Ёпрст
Время ожидания в 0 всем, если тис/комплексная - период хранения останков 5 дней.
#4 by skyadmin
Ставил на SQL 2008 R2, скорость только падает. К тому же один из отчетов (отчет по прочим доходам и расходам) при выбранной группе в отборе, вылетает с ошибкой C++ Runtime и крашится 1С, на любой из SQL (2000, 2005 и 2008), поэтому SQL пока не годится.
#5 by dk
терминал спасет не 100% но 99%
#6 by Ёпрст
>>>Работает на терминальном 30-35 пользователей,
#7 by Mikeware
что говорит старый еврей Профайлер?
#8 by Господин ПЖ
у тебя проблемы не в быстроте а в параллельности работы
#9 by Ёпрст
ну, для дбф базы он его долго искать будет :)
#10 by Господин ПЖ
что он скажет в файловой?
#11 by dk
у меня еще аналитики умудрялись вешать терминал, когда EXCEL запускали с большой сводной или ВПР большим - EXCEL отлично умеет отжирать все процессоры не хуже 1с 7.7 в режиме захвата таблицы )
#12 by Mikeware
ну, его младший брат Дебаггер, исполняющий функции  Профайлера?
#13 by Злопчинский
Ликвидируйте работу задним числом Работа на обы ном офисном пне с елаом пользователей до 25 чел трудномтей не представляла
#14 by Garykom
а может им лучше "очередь проведения" наладить? чтобы транзакций блокирующих не было?
#16 by PRO100 NigGaZ
35 человек работало в терминале, проблем не было...
#17 by skyadmin
Запретить работу задним числом невозможно, неделю задним числом редактируют, делать исправления текущим числом никого не заставишь, а исправления делаются ежедневно и по много раз. Пока испробую . Есть подозрения,что часто пользуются внешней обработкой, с транзакцией. Надо наверное в ней прописать cmd /C msg * "Пользователь <User> запустил транзакцию, все ждем!". Тогда вопросов почему тормозит, станет поменьше :)
#18 by varelchik
Есть опыт перевода файло в sql и все в норме. А если вылетает с ошибкой на всех версиях sql надо искать проблему а не изврат. + переход на прямые запросы. с 1С++ скорость вырастает в разы, даже по сравнению с dbf. Пользователи даже не заметили разницы. А dbf и sql стандартными методами ох как отличаются в скорострельности.
#19 by varelchik
+ 30-35 пользователей это ерунда. у меня 150 работает правда в базе не ТИС а Документооборот а причем все активно внося документы и т.п. и тормозов никаких. правда узкое место это родной ЖР, но его мы обошли переводом в SQL хранение.
#20 by varelchik
так что ищите дырки в базе.
#21 by Mikeware
а как перевели?
#22 by varelchik
1C++ С помощью перехватчика. Захватили системные и пользовательские события по работе с журналом регистрации и перенаправили прямыми запросами в базу SQL.
#23 by Mikeware
понял. зря я, наверное, не стал этим заморачиваться...
#24 by Злопчинский
и чего это у вас исправлений денлают по много раз? реализаций..? сильно сомневаюсь. Скорее всего колбасят заявки. наладь работу с корректировочными заявками и вообщем все. Основные тормоза - это расчет временных итогов в модулях проведений
#25 by Ёпрст
ЖР, проще вообще отключить за ненадобностью в пофигураторе
#26 by Mikeware
дык надобен... таблица исправлений - самая большая в базе. а туда пишется далекол не все...
#27 by Mikeware
поделись классом?
#28 by skyadmin
Перевести не проблема, проблема с отчетами, переделывать которые на прямые запросы нет никакого желания и времени. Это для меня не основная база, есть еще розница и много магазинов. Делают исправления и в заявках и в реализация и в поступлениях, перемещениях, причем правкой занимаются куча народу и в разных офисах. Сам учет настроен кривовато, но переделывать уже поздно. Легче на 8 перевести, но опять же для меня это не приоритет. ЖР 1,2 Гб, но отключить его нельзя, там записывается все что кто исправлял, вплоть до каждого реквизита документа.
#29 by Ёпрст
дык архивируй ЖР периодически
#30 by Ёпрст
из-за него тормоза тоже не детские
#31 by Mikeware
кстати, вроде больше гига - ЖР начинает сильно тормозить.
#32 by Злопчинский
ну раз бардак и нет возможности/желания привести это внормальное состояние - тады ой... жуйте как есть ;-)
#33 by ЧеловекДуши
Похоже вы где-то злоупотребили Транзакцией или Обработкой по перепроведению документов. От транзакции лучше избавиться В обработку поместить "Паузу", но не через накручивание цикла :) Так же помогут Прямые запросы Оптимизация запросов Исправление ГУАНО кода Выпиливание "мертвых душ" из объектов Метаданных. Переписать Периодические реквизиты справочников на регистр "Оборотный" (нужны прямые запросы) Убрать проверку из Модуля документа, ибо проверка в транзакции, это Пауза для всей БД. Убрать черные запросы из процедуры проведения документа ... и т.д... Оптимизировать можно долго, в зависимости Хауса в учете :)
#34 by ifso
а чего там с партийными списками?
#35 by skyadmin
База типовая, не переписанная. Есть только несколько внешних обработок, некоторые содержат транзакции, я просто пока не в курсе периодичности их запуска. Просто интересно, даже если 1с  что-то там делает, почему не использует на 100% ни одного ядра, ни диск, ни память. Ведь все это можно делать, очевидно быстрее, но нет...
#36 by ЧеловекДуши
Периодические элементы, типо "Цена" пишутся в одну таблицу "Константы", это Фишка платформы - "Привет разработчикам СУБД от 1С" Транзакции у 1С 7.7, захватывают ВСЮ БД, и чем дольше ты держишь, тем сильнее все курят бамбук :)
#37 by ЧеловекДуши
+ 1С 7.7 Одно-ядерное приложение. Примерно, если будете Использовать на терминале Win x64, то Сама Ось будет делить на ресурсы :) + Насчет паузы, у 1С 7.7, как и у 1С 8.ххх... Больное игнорирование пауз. Народ обычно пишет на Джаве или на ВК или еще как... Что бы Процессор в цикле не Грузить на 100% :)
#38 by ЧеловекДуши
+ Если типовая Торговля с Партийным учетом, то тот еще тормоз. Если еще и фаловая, то это копец. Все запросы от 1С, ориентированы на работу в DBF БД, а следовательно, Каждый "Сложный" запрос сперва Копируют "Простую" структуру выбранных данных во временные файлы и после начинает работать с Группировками, Итогами и т.д.... ... Даже SQL запрос не спасет от копирования БД во временные файлы, так работают Черные запросы от 1С. ... На SQL обычно спасают прямые запросы...
#39 by Злопчинский
"Транзакции у 1С 7.7, захватывают ВСЮ БД" . бред укурившегося... ;-)
#40 by Андрей_Андреич
Да ладно - у меня бывает и соседние захватывает
#41 by Злопчинский
Еще раз: избавьтесь от проведений задним числом. Или по крайней мере расчетом временных итогов при проведении. Получите ускорение на порядок. Период базы поставьте = 5 дней. Получите существенное ускорение. Как вариант - все запросы на проведение - в одну очередь. Юзверям - сообщать о результатах проведения.
#42 by Злопчинский
Уанс море эгейн . "Транзакции у 1С 7.7, захватывают ВСЮ БД" бред укурившегося... ;-) . Сделай обработку НачатьТранзакцию; Предупреждение("Ждем когда выкурят..."); Нигде ничего не заблокируется. Вообще ничего.
#43 by varelchik
стучись в аську. разберемся.
#44 by dmrjan
Скорость работы винтов не замерял? Может дегрейд производительности пошел? SSD корпоративные? Если нет, то будут проблемы с многопользовательским режимом.
#45 by kudlach
В лохматых 2005 годах romix делал свои первые гениальные шаги :) Там и перехват запроса, и подмена, и выключение блокировок таблиц, и масса интересного. Много интересного тогда на 7.7 сделали - раскачали базу до 150 пользователей. Комплексная, SQL, 1с++, с парой тысяч документов в сутки.
#46 by fbear
А какая ОС на сервере?
#47 by skyadmin
ОС Server 2008R2, сама стоит на зеркальном рейде из 4х HITACHI HUS156030VLS600, скорость 300 мб/сек. База перенесена на SSD OCZ VTX3-25SAT3-60G скорость > 350 мб/сек. Состояние всех дисков отличное (HDSentinel), среднее использование SSD диска на 0,2%.
#48 by Ёпрст
для начала, заархивировать жР или прибить его совсем.
#49 by Mikeware
#50 by Ёпрст
потом, огласить че за база хоть - тис/бухня/компл
#51 by Ёпрст
у него же дбф
#52 by Ёпрст
там всё летать должно и так.
#53 by skyadmin
У меня давно возник один вопрос по поводу использования SSD, сразу тут поднимаю... Если на жестких дисках есть кэш (который работает со скоростью ОЗУ), а на SSD такого кеша нет (или я ошибаюсь), то не теряется ли производительность при частых и однотипных мелких операциях чтения/записи?
#54 by Mikeware
обсыпаюсь пеплом.....
#55 by вовочка
в написано Есть база Торговля+Склад, свернутая на начало года.
#56 by Mikeware
чтоб ветки не плодить... секрелиз стоит 7-й, а на обращениях к подчиненным - тормозит незнамо как (ну и на отборах в общем журнале иногда). ЧЯНТД?
#57 by Ёпрст
хз, вроде как солюшен 7 поставил и тормоза посчезли.
#58 by Ёпрст
Для ТиСа.. проверить наличие пустых дат в 1sjourn закрытие всех регистров, повырезать лишние - типа книжек покупок/продаж и заявок всяких (если по ним нет учета)
#59 by Ёпрст
сделать переиод останков 5 дней, в 0 обработку ожидания таблиц и темпы перенести на тот=же ссд  диск.
#60 by Злопчинский
возможно ТА загнана далеко вперед - есть такие любители.
#61 by вовочка
+100500
#62 by Vladal
Манаге5ры ставят резервы, корректируют заявки,Э потом друг у друга (ха, какая ж это дружба?) тырют товары в заявках. Вот и дёргается у вас всё. С таким бардаком трудно бороться даже административно. Я сделал логирование изменений документа и потом на дикие вопли "куда делся товар из моей заявки" показывал список изменивших его документ, где записаны все действия - изменение реквизита, колонки ТЧ, строки ТЧ, удаление строки и т.д.
#63 by Vladal
Кстати, да. Еще во времена Win98, до WinXP, я вырезал лишние сущности в базе - справочник проводок в ТиС, платежные поручения (работали только по кассе) и т.д. Смог запустить 5 или 6 пользователей. Потом купили WinXP, легализовали 1С и проблема исчезла.
#64 by Vladal
А в чём смысл? Некоторые в бухне ставяь расчет бухитогов вперед, типа чтобы в начале квартала не мучаться. А если ТА вперёд, то по сути все операции "задним числом" и от того дикие тормоза.
#65 by Mikeware
зато документы делают "по времени совершения операций"... мне сказали - я аж присел. документы за месяц вперед - я их спрашиваю - "и это по времени совершения?" А мне отвечют: конечно. мы им в августе точноотгрузим...
#66 by dmrjan
Для сервера подойдет такое решение - Intel SSDSC2BA100G301 объем 100гб.
#67 by Mikeware
да для такой базы и офисного компа хватит....
#68 by ЧеловекДуши
Да ты шо... Правда, нет шоль? А Журнал документов у 1С 7.7, не одна и таблица на все документы? Вот пока человечек играется с проведением документа, все курят и ждут, что бы провести свой документ. ... Согласен, насчет справочников я погорячился, при проведении блокируется только Документы, все документы Конфигурации. ... Но вот если будет вызван код "НачатьТранзакцию", то блокируется вся БД, на запись :)
#69 by ЧеловекДуши
Вы свой мопед без тормозов, убранный вами же и забыт как страшный сон, не подсовывайте :) В типовой, транзакция, это дурной тон :)
#70 by Злопчинский
я сделал еще тупее: проведенные заявки корректировке не подлежат. только корректировочной заявкой. и нормуль. плюс к этому тупо поставить запрет открытия документа если открывает чужой менеджер.
#71 by Злопчинский
Пипидастры, что с них возьмешь.. ;-)
#73 by Злопчинский
Согласен, погорячился...
#74 by Злопчинский
Неверно. Запусти простую обработку с кодом В соседнем сеансе - совершенно спокойно редактируются справочники и даже проводятся доки. В Транзакции блокируются только те объекты(таблицвы), к которым проводится обращение. Как-то вот так...
#75 by Злопчинский
Неверно согласился с погорячится. в я вообщем верно написал про бред укурившегося.. ;-)
#76 by Андрей_Андреич
Ты такой непостоянный...
#77 by Злопчинский
угу, я такой.. весь.. неожиданный...
#78 by ДенисЧ
Корнет, вы женщина?! )
#79 by Злопчинский
"А по сусалам..?" ;-)
Тэги: 1С 7.7 и ранее
Ответить:
Комментарии доступны только авторизированным пользователям

В этой группе 1С