По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
УПП на какой попало машине быстро работать не будет.
Плюс если у пользователей тормозные машинки, загонять всех в терминал
У нас у клиентов сервак за 100 тысяч с копейками и все в терминале, не жалуются на тормоза почему то
Плюс если у пользователей тормозные машинки, загонять всех в терминал
У нас у клиентов сервак за 100 тысяч с копейками и все в терминале, не жалуются на тормоза почему то
для нормальной работы базы с размером 11 гигов я рекомендую тебе все таки засунуть ее в sql или в что то то подобное намного быстрее отрабатывает запросы
и если пользователей больше 10 то это вообще будет на много лучше
и если пользователей больше 10 то это вообще будет на много лучше
Pajer пишет:
для нормальной работы базы с размером 11 гигов я рекомендую тебе все таки засунуть ее в sql или в что то то подобное намного быстрее отрабатывает запросы
и если пользователей больше 10 то это вообще будет на много лучше
для нормальной работы базы с размером 11 гигов я рекомендую тебе все таки засунуть ее в sql или в что то то подобное намного быстрее отрабатывает запросы
и если пользователей больше 10 то это вообще будет на много лучше
полностью поддерживаю, ставтье 1С Сервер и sql.
Не помешает ещё проверить LAN сеть. У нас есть такая трудность, имеются IP телефоны GrandStream, подключены через Lan-порт ПК, в результате скорость сети для конечного ПК из-за такого подключения значительно падает.
Файловая версия рассчитана на работу одного пользователя с полными правами иначе полный тормоз. Как пример у нас зуп (4 организации) начинали с файлового варианта у админа отчет выполнялся ~1 минута у расчетчика 20 минут
redkiller3 пишет:
переиндексация + sql + сервер 1с
переиндексация + sql + сервер 1с
Применение SQL-сервера, как правило, не ускоряет работу в базе, лишь значительно повышает ее устойчивость к возможным падениям.
olgadogi пишет:
Выгрузка базы и ее загрузка не поможет, надо по максимум сократить количество объектов
Выгрузка базы и ее загрузка не поможет, надо по максимум сократить количество объектов
Что в Вашем понимании означает фраза "по максимум сократить количество объектов"? Судя по словам автора топика, у них типовая УПП. Предлагаете резать базу? Это если автору не нужны исторические сведения в одной базе.
Вообще автору. На этом сайте, да и на ряде других есть куча статей по оптимизации баз, начинающих выходить за предел маленьких. Попробуйте повнимательней почитать. Давать ссылки не буду, глядишь, что-то еще почитается. Но здесь в результате придется применить комплекс мер, какой-то одной обойтись не удастся. Рекомендую все же повнимательней посмотреть на инфостарте, для Вашего случая разжевано не один раз
anig99 пишет:
sql много чего делает кроме отказоустойчивости:
максимальный размер базы
сокращение блокировок
ускорение работы по сети крупных баз (без терминальных сессий)
клиент-серверный режим работы
это навскидку.
у пользователя с полными правами тормозов не будет.
sql много чего делает кроме отказоустойчивости:
максимальный размер базы
сокращение блокировок
ускорение работы по сети крупных баз (без терминальных сессий)
клиент-серверный режим работы
это навскидку.
у пользователя с полными правами тормозов не будет.
Это уже все проходили. Давайте вот так огульно тоже не заявлять.
1.Про максимальный размер базы здесь разговора не было. И про темпы роста базы тоже
2.Прежде чем говорить про сокращение блокировок, стоит разобраться сначала с железками, где все вертится
3.Ускорение работы по сети - это общие слова. Если я один работаю в базе размеров 10 гигов, ускориться ли в ней работа, если перевести с файлового на скульный режим? Да и вообще, определитесь, что такое "ускорится работа".
4.Клиент-серверный - ответ в 1.
В целом скажу - я за базы, особенно УППшные, на SQL. Только понимая, что делается и зачем, а не выдавая универсальных рецептов - "Переведите на SQL"!!!
(26) в файловом варианте есть ограничение на размер таблицы в базе. Т.е. сама база может быть больше 4 гб, но таблица в базе - нет.
При файловом варианте по сети гоняется вся таблица, а поэтому к скорости сети предъявляются повышенные требования (сам сталкивался с ситуацией, когда в базе тупо тормозил скроллинг по списку документов). Поэтому многие предпочитают работать с файловой базе под терминалом. На некрупных базах с небольшим числом (5-6) пользователей это незаметно. Перевод на sql замедляет проведение документов для одного пользователя, но при этом за счет более грамотной работы с данными работа нескольких пользователей в совокупности ускоряется за счет меньших требований к работе сети и сокращения блокировок.
Понятно, что при грамотном работе с железом, сетью и регулярном обслуживании базы можно нормально работать на базе около 10-15 Гб и 10 пользователями, но сверх этого начинается зона риска, когда всё может рухнуть в любой момент.
Ещё раз. У файловой версии 1с есть существенные ограничения, которые объективно сужают область её применение до небольшой бухгалтерии или торгового отдела. УПП само по себе относится к конфигурациям, использование которых подразумевает большое кол-во информации и пользователей. Если по каким-либо причинам необходимо нет возможности перевести УПП на SQL, то целесообразнее перевести учет на раздельное ведение бухгалтерия, УТ и специализированная производственная конфигурация с соответствующими обменами.
При файловом варианте по сети гоняется вся таблица, а поэтому к скорости сети предъявляются повышенные требования (сам сталкивался с ситуацией, когда в базе тупо тормозил скроллинг по списку документов). Поэтому многие предпочитают работать с файловой базе под терминалом. На некрупных базах с небольшим числом (5-6) пользователей это незаметно. Перевод на sql замедляет проведение документов для одного пользователя, но при этом за счет более грамотной работы с данными работа нескольких пользователей в совокупности ускоряется за счет меньших требований к работе сети и сокращения блокировок.
Понятно, что при грамотном работе с железом, сетью и регулярном обслуживании базы можно нормально работать на базе около 10-15 Гб и 10 пользователями, но сверх этого начинается зона риска, когда всё может рухнуть в любой момент.
Ещё раз. У файловой версии 1с есть существенные ограничения, которые объективно сужают область её применение до небольшой бухгалтерии или торгового отдела. УПП само по себе относится к конфигурациям, использование которых подразумевает большое кол-во информации и пользователей. Если по каким-либо причинам необходимо нет возможности перевести УПП на SQL, то целесообразнее перевести учет на раздельное ведение бухгалтерия, УТ и специализированная производственная конфигурация с соответствующими обменами.
Anya пишет:
Ужасно тормозит УПП, кто нибудь знает безопасные способы сворачивания базы и какой вообще критический ее размер. Сейчас размер базы около 11 Гигов, файловый режим
Ужасно тормозит УПП, кто нибудь знает безопасные способы сворачивания базы и какой вообще критический ее размер. Сейчас размер базы около 11 Гигов, файловый режим
А кто у вас обслуживает эту базу, она ведь не сама выросла до 11Гб?
Можно больше инфы : железо где стоит, сколько пользователей, пропускная способность и т.д. Зачем сразу базу резать.
Внесу и своих пять копеек. Многолетний опыт эксплуатации 1С в крупных и очень крупных масштабах (например 50 бухгалтеров разнесенных по трем - четырем зданиям) позволяет утверждать, что правильным является разнесение ресурсов и отказоустойчивость. Лучшей схемой является использование SQL сервера (на Ваш вкус и кошелек), ОТДЕЛЬНО от него сервера с установленным сервером Предприятия и, в зависимости от количества пользователей и необходимости отказоустойчивости один или несколько серверов на которых крутятся терминальные или Citrix сессии пользователей. Плюсы такой схемы, удобное управление сессиями клиентов. Возможность принудительного завершения и т.п. сессий. Бэкап транзакций средствами SQL и т.д. и т.п. В случае невозможности выделения нескольких физических серверов под эти задачи, можно воспользоватя виртуализацией HYPER-V. SQL на физической машине, сервер предприятия на ней же, а клиентский терминал на виртуалке. Но при этом должна быть весьма серьезная железка, на которой все это будет крутиться.
Может, кто знает? Сколько клиентов может достаточно комфортно работать в УПП (работа с текущими документами важна, отчеты, регламентные операции и время входа в программу не берём во внимание) в файловом варианте по сети (100 мегабит), если считаем, что ограничение на скорость работы оказывает только сеть (считаем, что компьютеры очень мощные)? Может, есть какие-то рекомендации самой 1С?
grey_chel пишет:
Сколько клиентов может достаточно комфортно работать в УПП
Сколько клиентов может достаточно комфортно работать в УПП
Ну это смотря с чем они работают. Проблема файлового варианта в том что блокировка накладывается на таблицу целиком и поэтому если два пользователя одновременно проводят один и тот же документ то начинаются проблемы.
Вообще из практики могу сказать что 5-7 человек работают нормально в КА при этом один из них кадровик 2 буха и 3 из них манагеры. Но нормально это означает что всё это дело работает... хотя и неприятно подтормаживает.
УПП конфигурация "тяжелая" поэтому я бы без сервера даже заморачиваться не стал... Хотя бывают такие жмоты... Но если жмотятся на сервер смысл вообще автоматизацию затевать.
higs пишет:
Применение SQL-сервера, как правило, не ускоряет работу в базе, лишь значительно повышает ее устойчивость к возможным падениям.
Применение SQL-сервера, как правило, не ускоряет работу в базе, лишь значительно повышает ее устойчивость к возможным падениям.
С этим я пожалуй соглашусь. Плюс еще стоимость SQL-сервера плюс стоимость по настройке. Работа в терминальном режиме обойдется гораздо дешевле и прирост скорости будет значительный. Еще конечно смотря на каком железе.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот