Считаете ли Вы, что если процессор и жесткие диски сервера не загружены на 100% и нет очередей к ним, то более мощный сервер не даст преимущества по производительности 1С?
Считаете ли Вы, что если процессор и жесткие диски сервера не загружены на 100% и нет очередей к ним, то более мощный сервер не даст преимущества по производительности 1С?
Если оборудование новое и очень мощное (памяти примерно 48-64 ГБ, хеоновые многоядерные двухпроцессорные, рейд 10), то быстрее не будет (24.49%, 60 голосов)
24.49%
Чуствую в этом вопросе подвох, но в чем именно сказать не могу (15.92%, 39 голосов)
15.92%
Не чего усложнять, чем дороже сервер, тем он мощние и значит будет быстрее работать (2.04%, 5 голосов)
2.04%
Я не знаю (9.39%, 23 голосов)
9.39%
Более мощный серверный даже при отсутствии очередей будет выполнять работу быстрее (39.59%, 97 голосов)
39.59%
Другое (напишу в комментариях) (8.57%, 21 голосов)
8.57%
Найденные решения
(7) Зеленоград, просто они знают как это работает и знают, что можно сделать, а что нет.
(1) Вячеслав, большинство подобных вопросов возникает из-за мышления штампами-шаблонами, причем по
всем компонентам системы сразу(железо+ дисковая_система+ОС+СУБД+сервер_приложений+код_конфигурации) и, (как бы помягче выразиться), недостаточным пониманием того, как построить схему выявления проблемного элемента(или группы элементов), чтобы потом с ним работать. Про код - отдельная тема, никто не хочет признавать неоптимальные запросы, кривую работу с объектами и данными и т.д. и продолжают валить на железо, диски, ОС, СУБД...
Ну и, опять же, для кого-то и 30 минут на отчет - благо, а кто-то страдает от 5-и секундного ожидания - "а ведь в файловой версии все летало!"
(1) Вячеслав, большинство подобных вопросов возникает из-за мышления штампами-шаблонами, причем по
всем компонентам системы сразу(железо+ дисковая_система+ОС+СУБД+сервер_приложений+код_конфигурации) и, (как бы помягче выразиться), недостаточным пониманием того, как построить схему выявления проблемного элемента(или группы элементов), чтобы потом с ним работать. Про код - отдельная тема, никто не хочет признавать неоптимальные запросы, кривую работу с объектами и данными и т.д. и продолжают валить на железо, диски, ОС, СУБД...
Ну и, опять же, для кого-то и 30 минут на отчет - благо, а кто-то страдает от 5-и секундного ожидания - "а ведь в файловой версии все летало!"
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Если дисквая очередь не превышает количество дисков в 0 массиве (с другими массивами еще жестче) а процессор загружен на 10% и программа тормозит.... то студенты программисты отчетов не виноваты это факт... виноваты либо админы и/или разработчики 1с и/или разработчики ОС... студенты программисты могут только крутить диски и проц сильнее чем это делают профи...
Покупаем более мощный сервер с 256Гб ОЗУ, и 4-мя 8-ядерными ксеонами, создаем RAM-диск гигов на 200, разворачиваем на нем виртуальную машину с сервером 1С и СУБД. Поражаемся производительности. :)
Ждем прогресса, пока дисковая подсистема догонит подсистему оперативной памяти по производительности... Ну а потом уже - оптимизируем код, запросы, бизнес-процессы :)
P.S. А в чем смысл опроса? Среди вариантов ответов есть неоспоримая истина?
P.P.S. Несмотря на обещанный от 1С рост производительности клиент-серверных конфигураций на управляемых формах - увы имеем обратный эффект. Переводить основные базы на УФ до сих пор не торопимся. Покупка хороших серверов проблемы их производительности не решила. Примитивно - оборотка в БП 2.0 формируется в два-три раза быстрее, чем в той же БП 3.0 после перехода.
Ждем прогресса, пока дисковая подсистема догонит подсистему оперативной памяти по производительности... Ну а потом уже - оптимизируем код, запросы, бизнес-процессы :)
P.S. А в чем смысл опроса? Среди вариантов ответов есть неоспоримая истина?
P.P.S. Несмотря на обещанный от 1С рост производительности клиент-серверных конфигураций на управляемых формах - увы имеем обратный эффект. Переводить основные базы на УФ до сих пор не торопимся. Покупка хороших серверов проблемы их производительности не решила. Примитивно - оборотка в БП 2.0 формируется в два-три раза быстрее, чем в той же БП 3.0 после перехода.
(99) insurgut, а потом пьяный дядя вася на подстанции передергивает фазы, бесперебойник выгорает, и ваша база с рамдиском валится напрочь.
Да и преувеличено мнение о влиянии производительности дисковой подсистемы на скорость работы 1С, в особенности в случае SQL. Поймите уже, скорость многопользовательской работы определяется не столько производительностью железа, сколько требованием изолированности транзакций, а все тесты, которые показывают обратное - синтетические и не отражают реальных условий работы.
Да и преувеличено мнение о влиянии производительности дисковой подсистемы на скорость работы 1С, в особенности в случае SQL. Поймите уже, скорость многопользовательской работы определяется не столько производительностью железа, сколько требованием изолированности транзакций, а все тесты, которые показывают обратное - синтетические и не отражают реальных условий работы.
P.P.S. Несмотря на обещанный от 1С рост производительности клиент-серверных конфигураций на управляемых формах - увы имеем обратный эффект. Переводить основные базы на УФ до сих пор не торопимся. Покупка хороших серверов проблемы их производительности не решила. Примитивно - оборотка в БП 2.0 формируется в два-три раза быстрее, чем в той же БП 3.0 после перехода.
(99) insurgut, а о том, что УФ той же оборотки нужно еще и на клиенте отрисовать, вы не забыли? Мы вообще о чем говорим - о производительности транзакционной или интерфейсной?
Замер производительности в отладке на той же оборотке сделайте с различных по железу клиентов и все поймете сами.
(101) asved.ru, а в обычном приложении её отрисовывать не надо на клиенте что-ли? Я говорю об общей производительности, конечный пользователь базы видит, что его работа стала менее комфортной и ему приходится ждать больше при выполнении тех же операций. Можно конечно с пеной у рта доказывать пользователю, что все на самом деле летает, только он этого не замечает, но ему не интересно внутреннее устройство, ему результат важен :)
УФ - сырые. Почему они в разы быстрее работают на Linux-клиенте, чем на Windows? Или программисты под Linux-клиенты у них более талантливы, чем под Windows, ведь под Linux есть уже 64-разрядный клиент, а под Win до сих пор нет.
УФ - сырые. Почему они в разы быстрее работают на Linux-клиенте, чем на Windows? Или программисты под Linux-клиенты у них более талантливы, чем под Windows, ведь под Linux есть уже 64-разрядный клиент, а под Win до сих пор нет.
УФ - сырые. Почему они в разы быстрее работают на Linux-клиенте, чем на Windows? Или программисты под Linux-клиенты у них более талантливы, чем под Windows, ведь под Linux есть уже 64-разрядный клиент, а под Win до сих пор нет.
(103) insurgut, потому, что GDI/Windows и X/Linux - принципиально разные архитектуры.
(193) alex_sh2008, природа не терпит "не сбалансированности"
если ты поставишь дохлый комп, то даже если проблема будет не в 1С, то в другом месте дискомфорт все равно вылезет
что же касается 1С, даже тонкий клиент многие вещи КЭШИРУЕТ и выполняет с клиента...
если ты поставишь дохлый комп, то даже если проблема будет не в 1С, то в другом месте дискомфорт все равно вылезет
что же касается 1С, даже тонкий клиент многие вещи КЭШИРУЕТ и выполняет с клиента...
(196) Gilev.Vyacheslav, Речь не об том какой компьютер стоит, а о том что 3-звенная технология не должна требовать от клиентского оборудования серьезной производительности.
Во всех приложениях тонкие клиенты обрабатывают только пользовательский интерфейс и часть бизнес-логики, не требующей запросов к базам данных. Есть четкое разделение: бизнес-логика, данные, представление. В 1С это разделение слабое отсюда и страдает общая производительности приложений (на кривом коде я не акцентируюсь). В 1С упрваляемые формы достаточно сложно оптимизированть по производительности из за отсутствия инструмента как "профалер", вовсех системах разработки такой давно существует интрумент.
Во всех приложениях тонкие клиенты обрабатывают только пользовательский интерфейс и часть бизнес-логики, не требующей запросов к базам данных. Есть четкое разделение: бизнес-логика, данные, представление. В 1С это разделение слабое отсюда и страдает общая производительности приложений (на кривом коде я не акцентируюсь). В 1С упрваляемые формы достаточно сложно оптимизированть по производительности из за отсутствия инструмента как "профалер", вовсех системах разработки такой давно существует интрумент.
(199) Gilev.Vyacheslav, На моих проектах не ставились первоочередные задачи производительности, а заставить УПП выдавать как можно больше полезной информации для бизнеса с минимальными затратами, при достижении в УПП охвата предприятия на 40% считалось хорошим показателем. Если я не понимаю смысла, разъясните мне этот самый смысл.
"Другое"
Производительность - дело тонкое. Здесь справедлив закон "узкого места". Если вы страдаете от медленной работы дисковой системы, то это ещё не значит, что более скоростные жесткие диски решат проблему. Возможно, ваша конфигурация запрашивает на чтение так много данных, что 50% ускорение чтения с дисков будет каплей в море. Любые выводы делать можно только сделав два шага: аппроксимация (предположение), эксперимент с другими исходными данными. Думаем, что может быть причиной, изменяем эту величину, делаем тесты и наблюдаем за результатом. Прямо таки научные методы. Можно построить график производительности по нескольким точкам, выяснив, в каком месте упираемся во второй ограничитель, и начинаем искать этот "второй" ограничитель. Таким образом можно графическим методом выявить точку равновесия, и максимально эффективно вложить деньги.
Производительность - дело тонкое. Здесь справедлив закон "узкого места". Если вы страдаете от медленной работы дисковой системы, то это ещё не значит, что более скоростные жесткие диски решат проблему. Возможно, ваша конфигурация запрашивает на чтение так много данных, что 50% ускорение чтения с дисков будет каплей в море. Любые выводы делать можно только сделав два шага: аппроксимация (предположение), эксперимент с другими исходными данными. Думаем, что может быть причиной, изменяем эту величину, делаем тесты и наблюдаем за результатом. Прямо таки научные методы. Можно построить график производительности по нескольким точкам, выяснив, в каком месте упираемся во второй ограничитель, и начинаем искать этот "второй" ограничитель. Таким образом можно графическим методом выявить точку равновесия, и максимально эффективно вложить деньги.
(106) chvitalya, все бы ничего, но когда основной обязанностью сервера становится одновременная работоспособность 5-10 различных информационных баз. Все говорят надо искать, вот только как искать?
Столкнулись в настоящий момент с проблемой - купили достаточно мощный (по сравнению со старым сервером) сервер. До ввода в эксплуатацию развернул тестовый виртуальный сервер на нем, загрузил основную базу УТ, запустил перепроведение по партиям за 3 года - он за сутки все перелопалил (на старом сервере - за сутки максимум месяц перепроводился). Воодушевлению нет предела. Настраиваем новый сервер. Переносим потихоньку все рабочие базы на него. Запускаем перепроведение партий на сервере на ночь. Всего ничего - месяц-два перепроводится может. Кто украл производительность? Куда копать? Конфигурация тестовой машины никак не изменялась, различие лишь в том, что нагрузка на него перешла полностью.
Столкнулись в настоящий момент с проблемой - купили достаточно мощный (по сравнению со старым сервером) сервер. До ввода в эксплуатацию развернул тестовый виртуальный сервер на нем, загрузил основную базу УТ, запустил перепроведение по партиям за 3 года - он за сутки все перелопалил (на старом сервере - за сутки максимум месяц перепроводился). Воодушевлению нет предела. Настраиваем новый сервер. Переносим потихоньку все рабочие базы на него. Запускаем перепроведение партий на сервере на ночь. Всего ничего - месяц-два перепроводится может. Кто украл производительность? Куда копать? Конфигурация тестовой машины никак не изменялась, различие лишь в том, что нагрузка на него перешла полностью.
(107) insurgut, ИБ на mssql, postgresql? Если да, то скорее всего виновата СУБД, нужна оптимизация или настройка. Если файловая, то скорее всего вы (или сис. админ, или Вася Самоделкин по совместительству суперджедай) изменили какие-то сетевые или локальные настройки на сервере, либо пассивные базы тоже что-то с собой делают по ночам (следят за координатами GPS у автомобилей). У меня тоже лежат около 15 баз в файловом варианте, но они почти все используются раз в месяц, только 5 рабочих. Ничего подобного не замечал..
(109) chvitalya, вот когда у вас появится хоть одна более-менее загруженная база (минимум 50 сеансов активных постоянно), да еще и не в файловом варианте, готов подискуссировать на тему тонких настроек SQL 2012 и планов оптимизации баз :)
Сценариев множество уже было проработано, от различных настроек самих виртуальных серверов Hyper-V (подключение баз на виртуальных SCSI-евых дисках, выделения большего количества процессоров, памяти, конвертации динамических дисков в фиксированные), установки различных ОС, вариаций установки 1С и SQL вместе и врозь, до настроек конечных планов оптимизации баз MSSQL на виртуальном сервере MSSQL для каждой базы.
В результате - работаем чуть быстрее, но не в разы. Все таки скорость работы холостого сервера и сервера с кучей различных баз - это две большие разницы. Идеальный вариант - использование отдельного сервера под каждую базу - из разряда фантастики конечно, не рассматриваем.
Сценариев множество уже было проработано, от различных настроек самих виртуальных серверов Hyper-V (подключение баз на виртуальных SCSI-евых дисках, выделения большего количества процессоров, памяти, конвертации динамических дисков в фиксированные), установки различных ОС, вариаций установки 1С и SQL вместе и врозь, до настроек конечных планов оптимизации баз MSSQL на виртуальном сервере MSSQL для каждой базы.
В результате - работаем чуть быстрее, но не в разы. Все таки скорость работы холостого сервера и сервера с кучей различных баз - это две большие разницы. Идеальный вариант - использование отдельного сервера под каждую базу - из разряда фантастики конечно, не рассматриваем.
(111) Восьмой, почти полностью согласен.
(110) insurgut, я не верю, что у вас все базы используются 50+ сеансов, ведь есть какой-то фаворит (фавориты)? Его можно вполне вынести на отдельный сервер, так? Руководство должно быть обеспокоено медленной работой, нужно предоставить ему жалобы пользователей + результаты тестов + предложить выход (в качестве финансовых вложений), если не нравится выход - пусть терпят и работают, ведь не нам (администраторам) проводки проводить и сверки делать?) Можно бесконечно ругаться на механика, что ломается запорожец, но всё имеет свойство устаревать. Тут только волшебство поможет.
(110) insurgut, я не верю, что у вас все базы используются 50+ сеансов, ведь есть какой-то фаворит (фавориты)? Его можно вполне вынести на отдельный сервер, так? Руководство должно быть обеспокоено медленной работой, нужно предоставить ему жалобы пользователей + результаты тестов + предложить выход (в качестве финансовых вложений), если не нравится выход - пусть терпят и работают, ведь не нам (администраторам) проводки проводить и сверки делать?) Можно бесконечно ругаться на механика, что ломается запорожец, но всё имеет свойство устаревать. Тут только волшебство поможет.
(113) chvitalya, понятно что не все, но отделять сервер под одну базу нереально :) Никто не говорит, что работать стало все медленнее, не так быстро как ожидалось изначально. О чем я и говорил выше - разница в тестах на незагруженном (холостом) сервере и на боевом с реально работающими пользователями - две большие разницы.
(119) Gilev.Vyacheslav, позвольте поинтересоваться :) Вы сравнивали производительность клиента 1С под Linux с клиентом под Windows? Нами было замечено, что управляемые формы под Linux - можно сказать летают в сравнении с клиентом под Winodws (к примеру в разы быстрее открывается база УТ11, списки документов и формы документов). Действительно ли "тормознутость" управляемых форм в Windows кроется именно в интерфейсной (если можно так назвать) части клиента?
P.S. Была бурная работа по подготовке к переходу на УТ11, переносили справочники, остатки, корректировали настройки... Но после того, как запуск конфигурации начал достигать 1 минуты (и заторможенное хождение по разделам, спискам документов), приостановились. Не поймет руководство новой программы, которая в разы медленнее старой. Для проверки как раз запустили клиента под Linux, с того же сервера конфигурация стартует секунд 5-10.
P.S. Была бурная работа по подготовке к переходу на УТ11, переносили справочники, остатки, корректировали настройки... Но после того, как запуск конфигурации начал достигать 1 минуты (и заторможенное хождение по разделам, спискам документов), приостановились. Не поймет руководство новой программы, которая в разы медленнее старой. Для проверки как раз запустили клиента под Linux, с того же сервера конфигурация стартует секунд 5-10.
(121) Gilev.Vyacheslav, Да я полностью с Вами согласен, однако производительность 1С напрямую зависит от реализации конфигурации которую она использует. Опыт моей практики показывает что приобретение сервера + 6 млн для "ускорения" работы типовой УПП (200 пользователей, 3 тыс док./день, V = 100 гБайт.) дает прирост по данным 1С КИП всего на 10%-15% (восстановление последовательности в партионном учете и расчет себестоимости производства по переделам), при этом вложение в КОД половины этой суммы сроком не более полугода дает прирост в решении той-же задачи от 80% без смены железа, однако такой подход накладывает определенные требования на сопровождение самой системы. Поэтому я сужу поднятый вопрос данного топика исходя из трудозатрат и конечного результата. Ведь рассматривать данный вопрос можно как глазами Франчей так и глазами штных ИТ специалистов. Если к примеру Вы Франч и речь идет о средних компаниях где пользователей от силы 70 то Вам проще убедить руководство этой компании купить новый сервер (около 1.5 млн) и не парится, но Мы работаем в рамках крупного холдинга использующего гетерогенную систему на базе 1С (Бух, Упп, Ут + Риб) и наличием целого штата ИТ, то здесь ведь уже можно будет использовать более значительные средства, если Вы будете решаеть задачи получения прироста в скорости данной системы и они скажем будут Вами вложенны в сервера (2 шт. + 5 млн) без вложения в КОД то такое решение однозначно даст незначительный прирост и Вам как специалисту оправдать такие трудозатраты руководству этой компании отговоркой что мол дело все в "сложной логикой типового решения" 1С у Вас просто не получится . В конце концов тот кто платит деньги тот и заказывает музыку - а наша задача сделать эту музыку красивой.
(125) Восьмой, в ближайшее время на сайте 1С в разделе ЦКТП планируем опубликовать проект на тысячи пользователей, вот на тех масштабах не железо подбирается под конфигурацию, а конфигурация пишется под КОНКРЕТНОЕ железо (на другом просто скорее всего работать не будет)
(130) Gilev.Vyacheslav, А что касается проектов на тысячи пользователей, то это абстрактная величина, из всех публикаций что я видел, это совокупное количество лицензий собранной со всех конфигураций, серверов и баз. А фактически максимальная нагрузка на одну базу не превышала 200 пользователей
Мне вот интересно, к чему все эти вопросы про производительность железо и тому подобное, если давно понятно что архитектура самой 1с не в какие ворота не лезет для высокопроизводительных задач. Одни циклы везде.Производительность значительно растет только там, где действительно было:
1) Старое железо
2) Студенты
3) Кривые руки
Код постоянно приходится переписывать для того чтобы работало хоть как-то на больших объемах и при выскоих нагрузках. Но это бред внедрять 1с для такого рода систем.
1с для мелкого бизнеса не более. Там где есть какие то нагрузки и объемы с 1с приходится @баться в полный рост днями и ночами, чтобы это @овно заработало более менее комфортно.
Особенно прикалывают франчи с их специалистами, которые не могут select написать, поэтому если им показать что такое план запроса и счетчики производительности, то они конечно @@уевают от такой умности.
Вообще золотое дно. Расплодить дилетантов, которые будут внедрять информационную систему, которая не предназначена для работы с большими объемами(хотя бы от 100 ГБ) с высокой нагрузкой.И стричь бабло за оптимизацию этой поделки.
PS: давно бы уже переписали ядро этого @овна, чтобы производительность была на уровне. Бизнес уже не понимает почему ему надо все время вкладывать деньги в какую-то херь.
1) Старое железо
2) Студенты
3) Кривые руки
Код постоянно приходится переписывать для того чтобы работало хоть как-то на больших объемах и при выскоих нагрузках. Но это бред внедрять 1с для такого рода систем.
1с для мелкого бизнеса не более. Там где есть какие то нагрузки и объемы с 1с приходится @баться в полный рост днями и ночами, чтобы это @овно заработало более менее комфортно.
Особенно прикалывают франчи с их специалистами, которые не могут select написать, поэтому если им показать что такое план запроса и счетчики производительности, то они конечно @@уевают от такой умности.
Вообще золотое дно. Расплодить дилетантов, которые будут внедрять информационную систему, которая не предназначена для работы с большими объемами(хотя бы от 100 ГБ) с высокой нагрузкой.И стричь бабло за оптимизацию этой поделки.
PS: давно бы уже переписали ядро этого @овна, чтобы производительность была на уровне. Бизнес уже не понимает почему ему надо все время вкладывать деньги в какую-то херь.
(117) pampage, Возьму за смелость Вас немного поправить - славо богу что до сих пор
Бизнес уже не понимает почему
- ведь пока с 1с приходится @баться в полный рост днями и ночами
а сама фирма 1С стремится Расплодить дилетантов
то для НАС специалистов знающих хотябы что такое план запроса и счетчики производительности
- такая работа будет Вообще золотое дно
.
При нагрузке сервака до 100 % надо бить в колокол. Пиковых нагрузок не должно быть на сервере 1С, да и не только 1С.
Конечно, более мощный сервер ускоряет работу в целом. Но и код бывает такой, что никакой сервак не поможет. Так что, и железо должно быть на уровне, и код оптимизированным.
Конечно, более мощный сервер ускоряет работу в целом. Но и код бывает такой, что никакой сервак не поможет. Так что, и железо должно быть на уровне, и код оптимизированным.
В контексте данной темы, я позволю себе задать вопрос. Какая наиболее оптимальная конфигурация фабрики серверов или кластеров для того что бы 1С смога безболезненно обслужить на одной базе одновременное подключение 5000 пользователей, и базе с размером 1Тб?
(140) alex_sh2008, все, что необходимо для одновременного подключения 5000 пользователей - это объем оперативки, достаточный для размещения информации о сеансах. Не знаю, сколько это для одного сеанса, но явно немного.
Другой разговор - что эти пользователи будут делать.
Другой разговор - что эти пользователи будут делать.
(146) alex_sh2008, я не специалист по кластеризованным решениям для SQL, соответственно в этой области ничего не скажу, разве что рекомендацию обеспечить максимально быструю по iops СХД.
1С кластеризуется прекрасно, а сервер выполняет исключительно вычислительные функции, так что имеет смысл ставить полку блейдов с 4-8GB на ядро CPU, с тем расчетом, чтобы на один процессор приходилось порядка 10-15 клиентов (на самом деле, зависит от работы пользоателей). Далее, при таком количестве пользователей наша система однозначно является территориально распределенной и, вероятно, будет иметь смысл перекладка задачи доставки приложения на веб-сервер. Соответственно, это опять же набор чисто вычислительных серверов доступа с распределением порядка 50-100 клиентов на ядро/процесс.
1С кластеризуется прекрасно, а сервер выполняет исключительно вычислительные функции, так что имеет смысл ставить полку блейдов с 4-8GB на ядро CPU, с тем расчетом, чтобы на один процессор приходилось порядка 10-15 клиентов (на самом деле, зависит от работы пользоателей). Далее, при таком количестве пользователей наша система однозначно является территориально распределенной и, вероятно, будет иметь смысл перекладка задачи доставки приложения на веб-сервер. Соответственно, это опять же набор чисто вычислительных серверов доступа с распределением порядка 50-100 клиентов на ядро/процесс.
(147) asved.ru, Перевод задачи на web, фактически мы отводим от себя задачи по выбору оборудования на клиенте, нам не важно какая система будет там, важно что бы наше приложение обладало достаточно маленьким откликом на запросы клиентов. То есть можно предположить, что мы должны отделить хранение конфигурации от данных, путем ручной пере конфигурации базы данных 1С в другую базу или хранилище - тем самым обеспечивая быстрый доступ серверов 1С к коду приложения. Но вопрос же все таки остается как организовать такое, где фактически будет две базы в пространстве SQL и одна база в пространстве сервера 1С.
ы должны отделить хранение конфигурации от данных, путем ручной пере конфигурации базы данных 1С в другую базу или хранилище - тем самым обеспечивая быстрый доступ серверов 1С к коду приложения
(148) alex_sh2008, Конфигурация полностью загружается в память процесса rphost при появлении у этого процесса первого клиента.
как организовать такое, где фактически будет две базы в пространстве SQL и одна база в пространстве сервера 1С.
Есть, к примеру,
(149) asved.ru, Если к примеру, всех пользователей обслуживает 20 серверов 1С, то сколько понадобится одному серверу загрузить эту базу к себе в память с SQL кластера, если при этом остальные сервера будут загружены на 50%, и соответственно кластер sql тоже будет загружен, разве это не станет слабым местом? И напротив база конфигурации будет размещена на отдельном сервере, в задачу которого будет входить только обслуживание этой базы?
(150) alex_sh2008, не станет. Точнее, с позиций здравого смысла, время запуска приложения по adpex не есть сильно критичный показатель. Ибо пользователь занимается не старт-стопами, а работой в рамках уже запущенного приложения.
В условиях ограниченной матчасти, безусловно, имеет смысл партиционирование таблиц. Грубо говоря, мы кладем редко используемые данные (к примеру, таблицу движений регистра за прошлые годы) на более медленный том, а регулярно требуемые (к примеру, таблицу итогов регистра) - на более быстрый.
Но изначально вопрос поставлен так, что бюджетом мы не ограничены и можем, к примеру, запилить RAID10-массив из пары десятков хайтоп-левел SSD на контроллере с десятком гигов кэша. :)
В условиях ограниченной матчасти, безусловно, имеет смысл партиционирование таблиц. Грубо говоря, мы кладем редко используемые данные (к примеру, таблицу движений регистра за прошлые годы) на более медленный том, а регулярно требуемые (к примеру, таблицу итогов регистра) - на более быстрый.
Но изначально вопрос поставлен так, что бюджетом мы не ограничены и можем, к примеру, запилить RAID10-массив из пары десятков хайтоп-левел SSD на контроллере с десятком гигов кэша. :)
(171) Gilev.Vyacheslav, сказки на то и сказки, чтобы передаваться от сказителя к сказителю: .
Чего ж тут сказочного? Enterprise SQL и нехватка быстрой дисковой подсистемы?
Или вы про мега-рейд?
(168) Gilev.Vyacheslav, имеются в виду сервисы менеджера, которые принципиально могут быть запущены только в единственном экземпляре?
Чего ж тут сказочного? Enterprise SQL и нехватка быстрой дисковой подсистемы?
Или вы про мега-рейд?
(168) Gilev.Vyacheslav, имеются в виду сервисы менеджера, которые принципиально могут быть запущены только в единственном экземпляре?
На самом деле при таких масштабах заказчик однозначно обладает средствами на полноценную разработку, а следовательно эффективнее будет не запускать типовую конфигурацию комплексного учета, а разработать или организовать набор специализированных, отвечающих каждая за свой раздел учета и направление обработки данных.
К примеру, если у нас 5000 торговых точек - нет смысла раздавать на каждую из них УТ, достаточно РТ. Предположим, мы хотим, чтобы продавец мог подсказать клиенту, на какой точке есть отсутствующий здесь товар. Сразу понимаем, что в другой город клиент за товаром не поедет, а следовательно базы можно сегментировать по городам...
Это все к тому, что задачу организации работы большого количества пользователей не следует решать тупо матчастью. Я вот не могу представить себе задачу, требующую активной работы пользователей именно в ОДНОЙ базе.
К примеру, если у нас 5000 торговых точек - нет смысла раздавать на каждую из них УТ, достаточно РТ. Предположим, мы хотим, чтобы продавец мог подсказать клиенту, на какой точке есть отсутствующий здесь товар. Сразу понимаем, что в другой город клиент за товаром не поедет, а следовательно базы можно сегментировать по городам...
Это все к тому, что задачу организации работы большого количества пользователей не следует решать тупо матчастью. Я вот не могу представить себе задачу, требующую активной работы пользователей именно в ОДНОЙ базе.
Коллеги, ради любопытсва, кто-то использует приведенные Выше схемы в реальной среде с 1С.
Я когда такой вижу, сне кажется проще отказаться от 1с и взять другое решение.которое будет больше заточено под масштабируемость как в производительности, так и по надежности.
Я когда такой вижу, сне кажется проще отказаться от 1с и взять другое решение.которое будет больше заточено под масштабируемость как в производительности, так и по надежности.
сервер не супер покупали года 4 назад.1С-рабочих баз (45(КА)+5(БП)+2(ЗУП)+7.7(КА),пользователей 10),заменили диски на скоростные(2шт)- распределили базы,увеличили память до 10ГБ,нормально настроили SQL(без терминалки),работоспособность увеличилась процентов на 40.
Из всех комментариев я понял следующее:
Любую даже хорошую программу можно испохабить до нельзя
Нельзя доверять программу новичку для ее оптимизации и обслуживания соответственно
Железо играет значительную роль в быстродействии и надежности системы
Залогом успеха является правильный выбор железа и соответственно программного обеспечения на стадии 0 этапа
Лучший специалист не штатный работник а работник ну или работники с спец организации
Себя профаном с 1с не считаю, но где-то с 140 поста потерял нить и понял что ничего не знаю , ну лили почти ничего. Хотя за сертифицированными специалистами приходилось ни раз подметать в программе.
Любую даже хорошую программу можно испохабить до нельзя
Нельзя доверять программу новичку для ее оптимизации и обслуживания соответственно
Железо играет значительную роль в быстродействии и надежности системы
Залогом успеха является правильный выбор железа и соответственно программного обеспечения на стадии 0 этапа
Лучший специалист не штатный работник а работник ну или работники с спец организации
Себя профаном с 1с не считаю, но где-то с 140 поста потерял нить и понял что ничего не знаю , ну лили почти ничего. Хотя за сертифицированными специалистами приходилось ни раз подметать в программе.
Лучший специалист не штатный работник а работник ну или работники с спец организации
(180) uriy, вот с этим поосторожнее - 95%
Результативность экспертизы зависит исключительно от эксперта, а эксперт без опыта (182) - ничто.
Все дело не только в мощности, но и в настройке сервера:
- оптимизация ОС, количества сервисов и установленных программ;
- настройка SQL;
- настройка менеджеров и рабочих процессов Сервера 1С Предприятия;
- расположение баз и оптимизаци их размера и внутренней структуры;
- оптимизация ОС, количества сервисов и установленных программ;
- настройка SQL;
- настройка менеджеров и рабочих процессов Сервера 1С Предприятия;
- расположение баз и оптимизаци их размера и внутренней структуры;
На sql.ru пару дней назад всплыла из небытия старая тема
Увлекательное чтение, чего только не советовали. Последний пост, вроде, прояснил моменты по кластеризации.
А ведь люди искренне надеялись, что приобретя железки и ПО на 4.5-5 млн. руб, у них все будет летать, "как семерка на компе у главбуха".
Увлекательное чтение, чего только не советовали. Последний пост, вроде, прояснил моменты по кластеризации.
А ведь люди искренне надеялись, что приобретя железки и ПО на 4.5-5 млн. руб, у них все будет летать, "как семерка на компе у главбуха".
и еще не мало важное это код оптимизирован??? а то я встречал такие вещи, в памяти засел 1 очень ярко
У кассира в журнале касса 1С 77 бух. поставить окно с текущим остатком в кассе, так там было просто вставлен чуть ли не весь код от ОСВ. хотя можно в 3 строчки было решить задачу :-)
У кассира в журнале касса 1С 77 бух. поставить окно с текущим остатком в кассе, так там было просто вставлен чуть ли не весь код от ОСВ. хотя можно в 3 строчки было решить задачу :-)
Соглашусь с оптимизацей кода. Один раз попалась база которая очень сильно тормозила. В итоге нашел кусок кода который зацикливал оформление строки. И выходило что то вроде рекурсии. Убрал зацикливание. И аллилуя все стало отлично работать.
Правильно настроенный SQL-сервер, и высокая скорость работы винтов - вот два необходимых условия быстрой работы 1с, и никакое колличество ядер не решит эту проблему потому как 1с так и не научилась загружать все ядра процессора на 100 процентов.... проверено уже на 1000 рядов. максимум то наблюдал я -по 50 процентов 4 ядра нагружались... а вот правильный настроенный рейд это даааа. скорость работы заметна очень...
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот