Считаете ли Вы, что если процессор и жесткие диски сервера не загружены на 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-и секундного ожидания - "а ведь в файловой версии все летало!"
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(9) zarucheisky, видел на скуле очереди к памяти (в активити мониторе тип ожиданий memory), конечно это "не самая популярная проблема", но мы ее "ловили", так что когда сверхинтенсивная перекачка данных в памяти из одного блока памяти в другой, это тоже при определенных ситуациях может стать проблемой
(1) Gilev.Vyacheslav, Если все делается медленно на мощном железе, то на "более мощном железе" будет прирост производительности, но не существенный, так как, по-моему, тут нужно лезть уже в саму базу: оптимизация запросов и смотреть блокировки данных и смотреть настройку SQL
Все-таки вопрос с каким-то подвохом. Зачем в (1) использовать 1С 8.2 х32? на счет (2) тут дело скорее всего в виртуальном сервере, так сам пробовал запихивать 1С и SQL в виртуальную машину, но работало жутко медленно (по-моему сами 1С говорили о потери производительности при использовании серверов 1С в виртуальных машинах). на счет (3) тут нужно смотреть настройки сетевых контроллеров, точнее использование IPv6 возможно тут кроется собака.
(1) я правильно понял, что речь идёт только про клиент-серверную версию 1С?
вообще, зависимостей слишком много, чтобы однозначно ответить. зависит от всего - начиная от железа (матери, памяти, дисковой подсистемы, их драйверов), продолжая системным софтом (версия ОС, SQL), и заканчивая самой учётной системой (конфигурацией, правильностью структур данных, качества запросов, количества пользователей и выполняемых ими задач)
вообще, зависимостей слишком много, чтобы однозначно ответить. зависит от всего - начиная от железа (матери, памяти, дисковой подсистемы, их драйверов), продолжая системным софтом (версия ОС, SQL), и заканчивая самой учётной системой (конфигурацией, правильностью структур данных, качества запросов, количества пользователей и выполняемых ими задач)
Да, Но существенной разницы в скорости можно не увидеть, т.к. в программе есть свой предел и выделение ей ресурсов тоже ограничено (не будем забывать о выделенных процессах для каждой задачи ну или программе и ее приоритету - я почему-то нигде в постах такого не видел, однако это существует и об этом мало кто знает и задумывается). На быстродействие влияют много параметров от самих программ их количества назначения приоритета,даже срок установленной Операционной Системы,пыль в компьютере температурный диапазон работы,наличие вирусов (вирус даже после удаления в некоторых случаях замедляет работу самой системы),ну и наконец объема самой базы и ее в ряде случаев неудачной модернизации.
А также локальная сеть (бывает вай фай - что не айс)
А также локальная сеть (бывает вай фай - что не айс)
(5) uriy, (13) zarucheisky, (8) mrdc, (7) Зеленоград, (6) cool.vlad4,
в вопросе о производительности часто ловушкой становится то, что куча различных проблем обозначается одним словом, для лучшего понимания надо рассмотреть различные ситуации:
Возьмем к примеру операцию выполняемую пользователем монопольно, да еще и с настройками, не предполагающими асинхронные фоновые расчеты или распараллеливание данных при обработке (maxdop=1 и не только, даже достаточно близок к однопоточности, если правильно параметры выставить).
Естественно, делая некоторую "работу" в один поток, с чего бы этому потоку создавать очереди. Очередь - это когда различные процессы конкурируют между собой за ресурсы. Если у нас "один поток", то сам с собой он не конкурируют.
Если мы возьмем один поток и запустим на сервере с процессором e5-2620 и на сервере с процессором e5-2690 (который с большой частотой), то за единицу времени второй процессор успеет выполнить больше операций, а очереди не будет в обоих потоках...
в вопросе о производительности часто ловушкой становится то, что куча различных проблем обозначается одним словом, для лучшего понимания надо рассмотреть различные ситуации:
Возьмем к примеру операцию выполняемую пользователем монопольно, да еще и с настройками, не предполагающими асинхронные фоновые расчеты или распараллеливание данных при обработке (maxdop=1 и не только, даже достаточно близок к однопоточности, если правильно параметры выставить).
Естественно, делая некоторую "работу" в один поток, с чего бы этому потоку создавать очереди. Очередь - это когда различные процессы конкурируют между собой за ресурсы. Если у нас "один поток", то сам с собой он не конкурируют.
Если мы возьмем один поток и запустим на сервере с процессором e5-2620 и на сервере с процессором e5-2690 (который с большой частотой), то за единицу времени второй процессор успеет выполнить больше операций, а очереди не будет в обоих потоках...
"Чувствую в этом вопросе подвох, но в чем именно сказать не могу".
Неоднократно видел, что эти параметры близки к нулю, но программа работает медленно. После малопонятных действий серверных и SQL-админов всё разбегается и носится. Считаю это шаманством и удачей, но контакты чудотворцев записал в мобилу.
Неоднократно видел, что эти параметры близки к нулю, но программа работает медленно. После малопонятных действий серверных и SQL-админов всё разбегается и носится. Считаю это шаманством и удачей, но контакты чудотворцев записал в мобилу.
(7) Зеленоград, просто они знают как это работает и знают, что можно сделать, а что нет.
(1) Вячеслав, большинство подобных вопросов возникает из-за мышления штампами-шаблонами, причем по
всем компонентам системы сразу(железо+ дисковая_система+ОС+СУБД+сервер_приложений+код_конфигурации) и, (как бы помягче выразиться), недостаточным пониманием того, как построить схему выявления проблемного элемента(или группы элементов), чтобы потом с ним работать. Про код - отдельная тема, никто не хочет признавать неоптимальные запросы, кривую работу с объектами и данными и т.д. и продолжают валить на железо, диски, ОС, СУБД...
Ну и, опять же, для кого-то и 30 минут на отчет - благо, а кто-то страдает от 5-и секундного ожидания - "а ведь в файловой версии все летало!"
(1) Вячеслав, большинство подобных вопросов возникает из-за мышления штампами-шаблонами, причем по
всем компонентам системы сразу(железо+ дисковая_система+ОС+СУБД+сервер_приложений+код_конфигурации) и, (как бы помягче выразиться), недостаточным пониманием того, как построить схему выявления проблемного элемента(или группы элементов), чтобы потом с ним работать. Про код - отдельная тема, никто не хочет признавать неоптимальные запросы, кривую работу с объектами и данными и т.д. и продолжают валить на железо, диски, ОС, СУБД...
Ну и, опять же, для кого-то и 30 минут на отчет - благо, а кто-то страдает от 5-и секундного ожидания - "а ведь в файловой версии все летало!"
В общем случае, более мощный сервер всегда дает преимущества по производительности. Если и не на самом деле, то кажущееся :-). Скажешь главбуху, что ему поставили сервер помощнее, а он в ответ, - да, стало всё работать быстрее.
А в частных случаях, всё зависит от множества факторов:
- размеры БД,
- количество юзеров,
- скоростей сетевых интерфейсов,
- оптимизированных или не оптимизированных конфигураций,
- и т.д. и т.п.
А в частных случаях, всё зависит от множества факторов:
- размеры БД,
- количество юзеров,
- скоростей сетевых интерфейсов,
- оптимизированных или не оптимизированных конфигураций,
- и т.д. и т.п.
Более мощный серверный даже при отсутствии очередей будет выполнять работу быстрее - согласна, но с оговоркой,что на сервере нормально настроен SQL и не кто-нибудь не загрузил сам сервер какими-нибудь регламентными заданиями и не поставил каспер..
У нас так было, купили сервер помощнее,оговорюсь,на сервере крутятся несколько различных баз типа ЗУП,Бухгалтерии и Сбыта,так вот после того,как перекинули все на новый сервер вдруг начались дикие тормоза при распроведении дока Начисление зп,точнее пользователь подвисал сам и тормозил остальных.Начали разбираться,оказалось кто-то из админов позаботился о сервере и установил каспер,и к этому настроили ежечасные бекапы и очистку логов. Убрали каспер,убрали задание по ежечасному копированию и тьфу-тьфу,все более менее
У нас так было, купили сервер помощнее,оговорюсь,на сервере крутятся несколько различных баз типа ЗУП,Бухгалтерии и Сбыта,так вот после того,как перекинули все на новый сервер вдруг начались дикие тормоза при распроведении дока Начисление зп,точнее пользователь подвисал сам и тормозил остальных.Начали разбираться,оказалось кто-то из админов позаботился о сервере и установил каспер,и к этому настроили ежечасные бекапы и очистку логов. Убрали каспер,убрали задание по ежечасному копированию и тьфу-тьфу,все более менее
Если на терминальном сервере полностью загружена очередь процессора браузерами а не 1С.
Поможет установка службы wsrm (Windows System Resource Manager), с помощью него во первых
произойдет балансировка нагрузки всех процессов, во вторых можно "порезать" ресурсов "отъедателям".
Поможет установка службы wsrm (Windows System Resource Manager), с помощью него во первых
произойдет балансировка нагрузки всех процессов, во вторых можно "порезать" ресурсов "отъедателям".
Момент, который часто ускользает от внимание, что очереди к дискам и процессорам это далеко не единственные показатели, по которым можно констатировать наличие ожиданий при выполнении операций 1С. Очереди могут быть К ЛЮБЫМ КОМПОНЕНТАМ. Даже нет смысла перечислять все. Если кто скажет что надо смотреть за очередями к сетевым интерфейсам, то это все равно не гарантирует, что нет "других секретных счетчиков" :)
Есть также разница между "должно работать быстрее" и "по факту работает быстрее".
Очень часто суждения строятся по принципу "ну раз на сайте вендора написано так, то не умничайте, вендор ошибаться не может".
Но на деле может оказаться "по разному", особенно при коллективной работе:
Есть не только ожидания в виде очередей к дискам, но в виде блокировок. При чем не только блокировок логических на субд, но "невидимых" - блокировки могут быть между процессами rphost при исполнении кода конфигураций 1с.
Какие то проблемы легко диагностируются, а какие то не тривиально.
Имхо по факту более мощный сервер дает большую Вероятность лучшей производительности и большую Возможность ее реализовать, но это конечно не гарантия.
Очень часто суждения строятся по принципу "ну раз на сайте вендора написано так, то не умничайте, вендор ошибаться не может".
Но на деле может оказаться "по разному", особенно при коллективной работе:
Есть не только ожидания в виде очередей к дискам, но в виде блокировок. При чем не только блокировок логических на субд, но "невидимых" - блокировки могут быть между процессами rphost при исполнении кода конфигураций 1с.
Какие то проблемы легко диагностируются, а какие то не тривиально.
Имхо по факту более мощный сервер дает большую Вероятность лучшей производительности и большую Возможность ее реализовать, но это конечно не гарантия.
(21) Имхо по факту более мощный сервер дает большую Вероятность лучшей производительности и большую Возможность ее реализовать, но это конечно не гарантия.
Даже если систему перенести с одного железа на другое полностью идентичное, то даже тут будет заметен прирост скорости - по одной простой причине: Новое железо "чистое" без мусора и правильно сконфигурировано и без лишнего мусора!
Даже если систему перенести с одного железа на другое полностью идентичное, то даже тут будет заметен прирост скорости - по одной простой причине: Новое железо "чистое" без мусора и правильно сконфигурировано и без лишнего мусора!
Думаю новый даст заметный прирост в скорости. Был у нас в конторе терминальный сервер, по железу неплохой, 4 ядра, куча памяти, raid, и т.д., хватало на 30 клиентов с запасом. Работали на нем и в 1С7 и 1С8. Но прошло 7 лет, клиентов прибавилось, пора ему на покой. Год назад поменяли на современное железо, прирост заметен, особенно благодаря SSD.
Вот имею жизненную ситуацию: УПП 1.2, включена совместимость с 8.1. Поменяли сервер на более мощный (оперативы 64, ксеоны, неоны и т.п.). Отключили совместимость с 8.1 и возникли сразу тормоза.
Видимо, к вопросу конкретного продукта (1С) мощности железа можно поставить на 2-ое место. Главное, как создана сама технология!
Видимо, к вопросу конкретного продукта (1С) мощности железа можно поставить на 2-ое место. Главное, как создана сама технология!
(31) DoctorRoza, Видать управляемые формы сами по себе не скоростные.
Вроде сервер - все быстрее должно летать.
Но у меня на работе работаю с крупной базой в файловом режиме, и опять: толстый клиент 2.0 летает быстрее чем та же база, переведенная в 3.0
Возьмём даже базу корпоративный университет, где обучается народ через веб клиент - даже та база на управояемых формах медленее, чем файловая толстого клиента.
Все таки в управляемом интерфейсе сервер больше перегружен, чем клиент. Главное что нет сильных тормозов. Но мне сдается, что это сам по себе такой механизм управляемых форм.Тихо не спеша летим мы чуть дыша))))
Вроде сервер - все быстрее должно летать.
Но у меня на работе работаю с крупной базой в файловом режиме, и опять: толстый клиент 2.0 летает быстрее чем та же база, переведенная в 3.0
Возьмём даже базу корпоративный университет, где обучается народ через веб клиент - даже та база на управояемых формах медленее, чем файловая толстого клиента.
Все таки в управляемом интерфейсе сервер больше перегружен, чем клиент. Главное что нет сильных тормозов. Но мне сдается, что это сам по себе такой механизм управляемых форм.Тихо не спеша летим мы чуть дыша))))
Конечно же новый сервер будет производительнее ибо улучшаются характеристики элементной базы. Да и любое железо со временем функционирует хуже ибо транзисторы имеют свойство со временем менять свои вольт амперные характеристики.
а жесткие диски вообще нужно целиком все менять максимум через 3 года работы ибо хитрыетараканы алгоритмы скрытия сбойных секторов являются рассадником системных ошибок.
И операционку переустанавливать раз в год, с нуля ибо системные ошибки накапливаются.
а жесткие диски вообще нужно целиком все менять максимум через 3 года работы ибо хитрые
И операционку переустанавливать раз в год, с нуля ибо системные ошибки накапливаются.
(34) транзисторы имеют свойство со временем менять свои вольт амперные характеристики
Не на уровне процессора.
а жесткие диски вообще нужно целиком все менять максимум через 3 года работы ибо хитрые тараканы алгоритмы скрытия сбойных секторов являются рассадником системных ошибок
Есть smart-параметры для этого и более/менее серьезные "балалайки" обладают системами самодиагностики.
Не на уровне процессора.
а жесткие диски вообще нужно целиком все менять максимум через 3 года работы ибо хитрые тараканы алгоритмы скрытия сбойных секторов являются рассадником системных ошибок
Есть smart-параметры для этого и более/менее серьезные "балалайки" обладают системами самодиагностики.
"Чуствую в этом вопросе подвох, но в чем именно сказать не могу"
Точнее могу: дело не только в "лошадиных силах" но и в настройке сервера:
- оптимизация ОС, количества сервисов и установленных программ;
- настройка SQL;
- настройка менеджеров и рабочих процессов Сервера 1С Предприятия;
- расположение баз и оптимизаци их размера и внутренней структуры;
Это в случае 1 сервера. При разнесении на кластер количество параметров еще более увеличивается.
Со-но говорить отдельно про голую мощь вообще не меет смысла.
Точнее могу: дело не только в "лошадиных силах" но и в настройке сервера:
- оптимизация ОС, количества сервисов и установленных программ;
- настройка SQL;
- настройка менеджеров и рабочих процессов Сервера 1С Предприятия;
- расположение баз и оптимизаци их размера и внутренней структуры;
Это в случае 1 сервера. При разнесении на кластер количество параметров еще более увеличивается.
Со-но говорить отдельно про голую мощь вообще не меет смысла.
(38) hogik, тогда с вопросу в заголовке должно быть уточнение: "На обоих серверах установлен один и тот же набор программ и сделаны одинаковые настройки." (без такого дополнения вопрос не корректен) Но! В жизни вы видели два таких идентичных по ПО и настройкам сервера? -Нет. Стало быть возвращаемся к началу - вопрос не имеет практического смысла.
(39)
"В жизни вы видели два таких идентичных по ПО и настройкам сервера?"(с)
Видел. :-)
Т.е., если надо сравнивать систему по железу, то это надо обеспечивать.
С одним допуском/оговоркой - драйверы считаем составной частью железа.
В противном случае вопросы в теме форума не имеют НИКАКОГО смысла.
Но, вопросы то заданы... :-)
"В жизни вы видели два таких идентичных по ПО и настройкам сервера?"(с)
Видел. :-)
Т.е., если надо сравнивать систему по железу, то это надо обеспечивать.
С одним допуском/оговоркой - драйверы считаем составной частью железа.
В противном случае вопросы в теме форума не имеют НИКАКОГО смысла.
Но, вопросы то заданы... :-)
Мощный сервере может и важно, но важна еще и грамотная настройка сети. Случай из практики. 2 Сервера - 1С, СУБД. Настроены по максимуму, но у пользователей все тормозит. Счетчики ничего не выявили:сервера просто не загружены. Обращаюсь к админам чтобы посмотрели сеть. Ответ: пропускная способность отличная, дело в 1С. Но такого ведь не бывает, что все отлично но все тормозит. Я опять к админам, чтобы проверили сеть, не много поднатужевшись проблема была успешна решена. Как мне сказали проблема была в настройках подсети, после чего все стало работать быстро и пользователи остались довольны.
(45) Gilev.Vyacheslav, Здесь может быть причиной либо платформа (был случай когда платформа в какой-то момент генерировала из одного фон.задания несколько десятков и работа превращалась в слайд шоу, пришлось откатится на релиз раньше), либо ошибка в проектировании, либо код конфигурации, но здесь надо подходит точечно, потому что как сказано в ответе (10) для кого то 30 минут норм, а для другого и 2 секунд мало.
Например на одном предприятии 35 региональных точек работают в терминале и 2-3 раза в неделю печатают большой объем данных на свои локальные компьютеры, когда отправляли на печать 2-3 пользователя в это время большинство точек не могли печатать данные. Проблема решилось переносом данной операции на тонкий клиент.
Но это исходим из того что сервера и сеть настроены оптимально и выполняются все регламентные процедуры.
Например на одном предприятии 35 региональных точек работают в терминале и 2-3 раза в неделю печатают большой объем данных на свои локальные компьютеры, когда отправляли на печать 2-3 пользователя в это время большинство точек не могли печатать данные. Проблема решилось переносом данной операции на тонкий клиент.
Но это исходим из того что сервера и сеть настроены оптимально и выполняются все регламентные процедуры.
(46) Serega456,
когда платформа в какой-то момент генерировала из одного фон.задания несколько десятков и работа превращалась в слайд шоу, пришлось откатится на релиз раньше)
ну генерируется много запросов с серверу, а почему сервер то был не загружен? по каким признакам это решили?
Если не планируется, расширение количества пользователей, добавление в конфигурацию кода требующих вычислительных ресурсов, и достаточно грамотное написание кода (с оптимизацией запросов и индексов). То смысла в новом более мощном сервере нет.
Я однажды игрался со всякими оверклокерскими настройками в BIOS на домашнем компе, и выявил прямую закономерность изменения производительности по известному тесту.
Например, задавал частоту шины FSB = 333, результат был 30 попугаев.
Увеличил на 20% FSB = 400, результат тоже увеличился на 20%, и стал = 36 попугаев.
Получается новый сервер может дать прирост производительности. Смотря что в нем нового.
Например, задавал частоту шины FSB = 333, результат был 30 попугаев.
Увеличил на 20% FSB = 400, результат тоже увеличился на 20%, и стал = 36 попугаев.
Получается новый сервер может дать прирост производительности. Смотря что в нем нового.
Мне думается, вы тут обсуждаете теоретические аспекты навигации подводных лодок в горах Памира. Объясняю, почему:
1) Симптоматика проблемы не раскрыта. Проблемы "тормозит 1С" не бывает, бывает проблема "тормозит 1С на определенных операциях в определенных условиях". А следовательно, не существует и универсального решения проблемы "тормозит 1С". Т.е. для начала следует определить и научиться воспроизводить проблему.
2) В общем случае производительность СУБД зависит не столько от железа, сколько от качества работы внутренних алгоритмов оптимизации. Postgre когда-нибудь ставили, сколько там shared memory по умолчанию? Заметку на users, в каждом релизе про расчет себестоимости видели?
3) Работа одного пользователя и работа нескольких пользователей - принципиально разные процессы. Также принципиально различаются обычное и управляемое приложение, автоматический и управляемый режим блокировок.
4) Случаются ситуации, когда разработчик неверно оценивает объем данных в динамике. Как следствие, изначально быстрый запрос становится тормозным. Наблюдал такое на УТ 10.
5) Даже для платформы конфигурация по умолчанию не всегда оптимальна. Пример: ставим сервер x64 в полной комплектации, клиента, IIS, публикуем базу. Открываем консоль IIS и видим, что используется x32 ISAPI-компонента, несмотря на наличие x64, и количество процессов пула приложения равно один. Совсем один.
А вы тут корень зла в железе ищете.
1) Симптоматика проблемы не раскрыта. Проблемы "тормозит 1С" не бывает, бывает проблема "тормозит 1С на определенных операциях в определенных условиях". А следовательно, не существует и универсального решения проблемы "тормозит 1С". Т.е. для начала следует определить и научиться воспроизводить проблему.
2) В общем случае производительность СУБД зависит не столько от железа, сколько от качества работы внутренних алгоритмов оптимизации. Postgre когда-нибудь ставили, сколько там shared memory по умолчанию? Заметку на users, в каждом релизе про расчет себестоимости видели?
3) Работа одного пользователя и работа нескольких пользователей - принципиально разные процессы. Также принципиально различаются обычное и управляемое приложение, автоматический и управляемый режим блокировок.
4) Случаются ситуации, когда разработчик неверно оценивает объем данных в динамике. Как следствие, изначально быстрый запрос становится тормозным. Наблюдал такое на УТ 10.
5) Даже для платформы конфигурация по умолчанию не всегда оптимальна. Пример: ставим сервер x64 в полной комплектации, клиента, IIS, публикуем базу. Открываем консоль IIS и видим, что используется x32 ISAPI-компонента, несмотря на наличие x64, и количество процессов пула приложения равно один. Совсем один.
А вы тут корень зла в железе ищете.
(50) asved.ru,
Случаются ситуации, когда разработчик неверно оценивает объем данных в динамике. Как следствие, изначально быстрый запрос становится тормозным. Наблюдал такое на УТ 10.
А по какой причине он становится "тормозным". Вы хотите сказать что сервера с разными мощностями дадут одинаковый результата или что?
(52) думаю, имеется в виду, что запрос изначально тормозной, а руки - кривые, но разраб, в силу, опять-таки, кривизны радиуса, не в состоянии этого осознать, а ограниченность тестовой БД, на которой он проверяет работоспособность запроса, также не раскрывает ему глаза
(52) Gilev.Vyacheslav,
А по какой причине он становится "тормозным"
По причине жестко определенного алгоритма выполнения и чересчур больших для этого алгоритма объемов аргументов. На абсолютно свежей статистике.
Вы хотите сказать что сервера с разными мощностями дадут одинаковый результата
Во всяком случае, принципиально не отличающиеся.
думаю, имеется в виду...
А это и есть первопричина в .
Я тут 2 копейки добавлю, ладно?
Вот взять, к примеру, фоновые задания, типа полнотекстового поиска. У нас на одном из серверов крутится более 50 баз (ЗУП, БП, БП3.0, УТ10.3), есть совсем мелкие, есть побольше (УТ на 23 ГБ). Процессор вроде бы не самый паршивый - E3-1240v2, 32 ГБ оперативки ECC, аппаратный рэйд, винты 10к и т.п. И во время обычной работы сервер по сути курит бамбук - нагрузка редко более 5%. А вот во время запуска фоновых заданий загруженность всех ядер подпрыгивает до 100% и держится так до 15 секунд и иногда даже более. Ясно дело, что в это время все прочие процессы "каменеют". Отсюда и потеря производительности. Выключаем регзадания на всех базах - и по тесту Вячеслава (кстати, хочу лично сказать ему большущее спасибо за этот замечательный инструмент) без какого-либо напряга 41-42 балла. И это во время активной работы пользователей. А стоит только включить все регламенты - все, 32-34 балла.
Понятно, что все регзадания я теперь перенес на позднюю ночь, когда нагрузки почти никакой.
А теперь основная мысль.
Вот у Вас в машине, скажем, 150 лошадок. Казалось бы, нафига: для обычной езды по городу или трассе достаточно и 50. Но ясно, что 150 и 50 дают совершенно разную разгонную динамику: следовательно, больше мощность, выше ускорение.
Поэтому средние показатели загрузки проца и IO - ерунда. Они могут быть вообще на уровне 1-2%. А вот моментальные вполне могут достигать 100%. И тут, например, чем выше тактовая частота, при прочих равных, тем лучше (Intel Turbo Boost - архиполезная штуковина!).
Или, например, при обычной вялотекущей работе IO может почти не лимитировать работу пользователей, а вот когда создается новая база - очень и очень заметно, насколько аппаратный рэйд лучше фэйка и 8 шпинделей 15к лучше 2-х на 7200.
И вот еще. Уже сто раз говорили:
1. если база втрое меньше ОЗУ - дисковая практически не влияет, ОЗУ можно тоже не добавлять, и прирост производительности дадут только гигагерцы и ядра процессора.
2. Если база равна ОЗУ или чуть меньше, надо увеличить объем ОЗУ и свести ситуацию к 1.
Правда, в процессе работы с базой это может произойти только со временем, и поначалу все отлично, а потом (спустя годик) - пипец. У наших клиентов была ситуация, когда они в УТ добавляли какие-то картинки, чуть не по паре МБ весом, ну и ясно, что база распухла до черт-те каких значений и еле шевелилась.
3. Если база многократно больше ОЗУ или достигнут предел (скажем, для E3-12xx это 32 ГБ) - ну, тогда надо думать об улучшении IO - гибридные RAID (кэш из SSD, сами диски обычные SAS), увеличение кол-ва шпинделей, замена 10к на 15к и т.п.
4. Мало кто пользуется возможностью разделения tablespaces по разным массивам, а ведь это дает приличный прирост производительности.
Вот взять, к примеру, фоновые задания, типа полнотекстового поиска. У нас на одном из серверов крутится более 50 баз (ЗУП, БП, БП3.0, УТ10.3), есть совсем мелкие, есть побольше (УТ на 23 ГБ). Процессор вроде бы не самый паршивый - E3-1240v2, 32 ГБ оперативки ECC, аппаратный рэйд, винты 10к и т.п. И во время обычной работы сервер по сути курит бамбук - нагрузка редко более 5%. А вот во время запуска фоновых заданий загруженность всех ядер подпрыгивает до 100% и держится так до 15 секунд и иногда даже более. Ясно дело, что в это время все прочие процессы "каменеют". Отсюда и потеря производительности. Выключаем регзадания на всех базах - и по тесту Вячеслава (кстати, хочу лично сказать ему большущее спасибо за этот замечательный инструмент) без какого-либо напряга 41-42 балла. И это во время активной работы пользователей. А стоит только включить все регламенты - все, 32-34 балла.
Понятно, что все регзадания я теперь перенес на позднюю ночь, когда нагрузки почти никакой.
А теперь основная мысль.
Вот у Вас в машине, скажем, 150 лошадок. Казалось бы, нафига: для обычной езды по городу или трассе достаточно и 50. Но ясно, что 150 и 50 дают совершенно разную разгонную динамику: следовательно, больше мощность, выше ускорение.
Поэтому средние показатели загрузки проца и IO - ерунда. Они могут быть вообще на уровне 1-2%. А вот моментальные вполне могут достигать 100%. И тут, например, чем выше тактовая частота, при прочих равных, тем лучше (Intel Turbo Boost - архиполезная штуковина!).
Или, например, при обычной вялотекущей работе IO может почти не лимитировать работу пользователей, а вот когда создается новая база - очень и очень заметно, насколько аппаратный рэйд лучше фэйка и 8 шпинделей 15к лучше 2-х на 7200.
И вот еще. Уже сто раз говорили:
1. если база втрое меньше ОЗУ - дисковая практически не влияет, ОЗУ можно тоже не добавлять, и прирост производительности дадут только гигагерцы и ядра процессора.
2. Если база равна ОЗУ или чуть меньше, надо увеличить объем ОЗУ и свести ситуацию к 1.
Правда, в процессе работы с базой это может произойти только со временем, и поначалу все отлично, а потом (спустя годик) - пипец. У наших клиентов была ситуация, когда они в УТ добавляли какие-то картинки, чуть не по паре МБ весом, ну и ясно, что база распухла до черт-те каких значений и еле шевелилась.
3. Если база многократно больше ОЗУ или достигнут предел (скажем, для E3-12xx это 32 ГБ) - ну, тогда надо думать об улучшении IO - гибридные RAID (кэш из SSD, сами диски обычные SAS), увеличение кол-ва шпинделей, замена 10к на 15к и т.п.
4. Мало кто пользуется возможностью разделения tablespaces по разным массивам, а ведь это дает приличный прирост производительности.
Gilev.Vyacheslav Поставил вопрос и сам на него же и ответил. Главное умелые ручки и правильно настроить ВСЕ! .На втором месте железо, ну и конечные пользователи. Кстати (58) пост очень полезен для новичков как впрочем и для профи тоже (все забывается в процессе работы, хоть и возможно поначалу было настроено правильно).
(58) Gilev.Vyacheslav, Отличный материал, многие вопросы однозначно снимает.
Что касается тестирования, тут, вообще-то все не так просто. Я обычно использую htop, iostat, glances - это из общеупотребительных программ. Запускаю, например, на сервере iostat -kx 5 и с клиента запускаю 1с в режиме, например, Предприятия, и строю большие отчеты или перепровожу документы за год, в другом окне консоли сервера при этом открыт htop или glances. Очень полезно, чтобы определить, чего не хватает - дисковой, процессора или ram. Разумеется, очень полезно наблюдать эти параметры во время Вашего теста.
Смешно, но даже такая простая штука, как pg_bench может очень существенно улучшить производительность.
Разумеется, это все относится к PostgreSQL и Linux.
Что касается настроек БИОСа относительно производительности, это вообще первое, что надо делать.
Т.е., зашли в БИОС, обновились до последней версии, поставили все настройки на Max. performance, затем обновили прошивку RAID-контроллера, если надо, то и дисков, и только тогда уже все остальное. Потому что потом, на уже работающей системе, гораздо сложнее найти время на отключение.
Еще вот один момент. Сравнения производительности Xeon E3-1240v2 и v3 однозначно свидетельствуют в пользу v3. Мы скоро будем делать систему на основе E3-1240v3, вот тогда и потестирую сам. Пока же вынужден руководствоваться чужими результатами.
Насчет свежих подходов, тут же вряд ли что-то новое можно придумать. Все уже разжевано в литературе.
Ждем, когда же, наконец, подешевеют (и станут надежнее) корпоративные SSD, тогда хоть про лаги IO можно будет забыть.
Что касается тестирования, тут, вообще-то все не так просто. Я обычно использую htop, iostat, glances - это из общеупотребительных программ. Запускаю, например, на сервере iostat -kx 5 и с клиента запускаю 1с в режиме, например, Предприятия, и строю большие отчеты или перепровожу документы за год, в другом окне консоли сервера при этом открыт htop или glances. Очень полезно, чтобы определить, чего не хватает - дисковой, процессора или ram. Разумеется, очень полезно наблюдать эти параметры во время Вашего теста.
Смешно, но даже такая простая штука, как pg_bench может очень существенно улучшить производительность.
Разумеется, это все относится к PostgreSQL и Linux.
Что касается настроек БИОСа относительно производительности, это вообще первое, что надо делать.
Т.е., зашли в БИОС, обновились до последней версии, поставили все настройки на Max. performance, затем обновили прошивку RAID-контроллера, если надо, то и дисков, и только тогда уже все остальное. Потому что потом, на уже работающей системе, гораздо сложнее найти время на отключение.
Еще вот один момент. Сравнения производительности Xeon E3-1240v2 и v3 однозначно свидетельствуют в пользу v3. Мы скоро будем делать систему на основе E3-1240v3, вот тогда и потестирую сам. Пока же вынужден руководствоваться чужими результатами.
Насчет свежих подходов, тут же вряд ли что-то новое можно придумать. Все уже разжевано в литературе.
Ждем, когда же, наконец, подешевеют (и станут надежнее) корпоративные SSD, тогда хоть про лаги IO можно будет забыть.
(76)
"Сравнения производительности Xeon E3-1240v2 и v3 однозначно свидетельствуют в пользу v3."(с)
Станислав (audion).
Я не нашел ни одного обзора подтверждающего Ваш оптимизм (применительно к НАШИМ задачам).
Дайте, пожалуйста, ссылку на обзор или результаты собственного сравнения.
"Сравнения производительности Xeon E3-1240v2 и v3 однозначно свидетельствуют в пользу v3."(с)
Станислав (audion).
Я не нашел ни одного обзора подтверждающего Ваш оптимизм (применительно к НАШИМ задачам).
Дайте, пожалуйста, ссылку на обзор или результаты собственного сравнения.
Отключите Сервис индексации на дисках, разнесите систему и диск с базой на разные массивы, желательно на разных шинах контролера.Лезьте в контроллер рейда, включите кеш. Подвигайте соотношение кеширования запись/чтение обычно 25/75 %. В вашей ситуации возможны другие варианты. Еще как бы не смешно звучало, не используйте менеджер базы в консоли самого сервера. В продакшене из-за этого тоже тормоза случались. По вопросу другой сервак не поможет, но тут есть нюансы. Модель рейд контроллера, тип мат. платы, сетевая инфраструктура?
Ну это ИМХО.
Ну это ИМХО.
Я ответил именно так как поставлен вопрос. Набор скрин шотов с совершенно разными условиями задач. В одном случае ESXI используется, в другом конфига нет. В третьем конфиг есть, мозгов дофига, а 1с 32 разрядная. Так что не надо сразу грязи.
На ваш вопрос можно ответить если ставить задачу конкретно.
Про там где 1с 32 разряда и так понятно что косяк.
Далее там где ESXi и все запущено на виртуалке как вы нагрузку на fs будите измерять. В винде что-ли?
Про разделение массивов нигде не указано. Предполагаю что не делили!!
Про менеджмент консоль, ваше право верить или нет. Давно это было, почитайте хотя бы здесь что такая проблема бывает
Точный конфиг дает хотя бы то, что мы не пытаемся получить золотые яблоки из какого-нибудь софтового рейда.
Так как вопрос закрыт, то в дальнейшей дискуссии не вижу смысла.
На ваш вопрос можно ответить если ставить задачу конкретно.
Про там где 1с 32 разряда и так понятно что косяк.
Далее там где ESXi и все запущено на виртуалке как вы нагрузку на fs будите измерять. В винде что-ли?
Про разделение массивов нигде не указано. Предполагаю что не делили!!
Про менеджмент консоль, ваше право верить или нет. Давно это было, почитайте хотя бы здесь что такая проблема бывает
Точный конфиг дает хотя бы то, что мы не пытаемся получить золотые яблоки из какого-нибудь софтового рейда.
Так как вопрос закрыт, то в дальнейшей дискуссии не вижу смысла.
(65)
"Я ответил именно так как поставлен вопрос"(с)
Это не вопрос. :-)
Это раздел - "Опрос на форуме". См. первую страницу раздела "Форум".
И подзаголовок соответствующий:
"Опрос мнения экспертов и практиков, всех кто программирует..."(с)
Думаю, автор темы знает как оптимизировать систему в части производительности.
И его интересует количество специалистов понимающих, что - "будет выполнять работу быстрее"(с). :-)
"Я ответил именно так как поставлен вопрос"(с)
Это не вопрос. :-)
Это раздел - "Опрос на форуме". См. первую страницу раздела "Форум".
И подзаголовок соответствующий:
"Опрос мнения экспертов и практиков, всех кто программирует..."(с)
Думаю, автор темы знает как оптимизировать систему в части производительности.
И его интересует количество специалистов понимающих, что - "будет выполнять работу быстрее"(с). :-)
Коллеги тестировали два сервера, отличие только в материнках и процессорах - в одном случае был E3-1240v2, в другом - v3, и по тесту Вячеслава разница была в 5-6 единиц. Мне самому это не совсем понятно. Теоретически, возможна еще одна причина: разные модули ОЗУ (хотя ребята говорят, что те же самые в обоих случаях).
Вот тест
и тут
Не очень существенно, конечно, но все же.
Вот тест
и тут
Не очень существенно, конечно, но все же.
(78)
Ничего не могу сказать про тесты от Гилёва. ;-)
Остальные тесты - различия на уровне погрешности.
И из-за "дополнений", которые не используются в НАШИХ задачах.
P.S.
Вот, думаю, пример погрешности в ИХ тестах:
Intel Xeon E3-1270 v3 @ 3.50GHz 10,124
Intel Xeon E3-1280 v3 @ 3.60GHz 10,110
Ничего не могу сказать про тесты от Гилёва. ;-)
Остальные тесты - различия на уровне погрешности.
И из-за "дополнений", которые не используются в НАШИХ задачах.
P.S.
Вот, думаю, пример погрешности в ИХ тестах:
Intel Xeon E3-1270 v3 @ 3.50GHz 10,124
Intel Xeon E3-1280 v3 @ 3.60GHz 10,110
(78)
Еще, очень странная оценка в ИХ тесте:
Intel Xeon E3-1240 V2 @ 3.40GHz 9,333
Intel Xeon E3-1265L v3 @ 2.50GHz 8,998
Intel Xeon E3-1245 V2 @ 3.40GHz 8,994
Т.е. они сравнивают с учетом VGA и на одном ядре? :-)
Нет. Такое сравнение НАМ не подходит.
Давайте искать другое...
(80)
"энергопотребление у v3 заметно больше, чем у v2 "(с)
Еще, очень странная оценка в ИХ тесте:
Intel Xeon E3-1240 V2 @ 3.40GHz 9,333
Intel Xeon E3-1265L v3 @ 2.50GHz 8,998
Intel Xeon E3-1245 V2 @ 3.40GHz 8,994
Т.е. они сравнивают с учетом VGA и на одном ядре? :-)
Нет. Такое сравнение НАМ не подходит.
Давайте искать другое...
(80)
"энергопотребление у v3 заметно больше, чем у v2 "(с)
(81) hogik, Вы пишете
Еще, очень странная оценка в ИХ тесте:
Intel Xeon E3-1240 V2 @ 3.40GHz 9,333
Intel Xeon E3-1265L v3 @ 2.50GHz 8,998
Intel Xeon E3-1245 V2 @ 3.40GHz 8,994
Это, скорее всего, объяснить не трудно: процессоры с индексом L - это модели с пониженным энергопотреблением, и смотрите, частота ядра у них 2,5 ГГц, против 3,5 у модели без L. Правда, есть TurboBoost до 3,5 ГГц, но это, конечно, лишь кратковременный режим.
Что касается меньшей производительности модели с графическим ядром, ну, тут, думаю, все понятно. Если взять тот же 1245 и подключить внешнюю видеокарту, то, думаю, можно было бы получить совершенно идентичные цифры с 1240.
Ставить процессоры с графическим ядром на серверы, конечно же, нонсенс, но есть материнки (Супермикро на чипсете C216), у которых нет встроенного видео, и видеовыходы работают только если установлен проц с графикой. Понятно, что занимать PCI-E видеокартой - чушь, их и так еле-еле хватает на RAID-контроллер и SAS-экспандер, так что тут без альтернатив - ставить процы только с графикой (нет, ну как вариант - PCI-видеокарту, есть у меня в загашнике древний PCI матрокс).
Вообще, мне все больше кажется, что все это - поиск блох. Радикальное улучшение может дать лишь переход на двухпроцессорные системы с той же или большей ТЧ ядра, увеличение объема ОЗУ для очень больших БД, или, если говорить об архитектуре E3-12xx, то об улучшении IO - например, за счет увеличения количества шпинделей.
Скажем, простейшее решение: RAID-контроллер типа того же RS2BL080 и экспандер на 24 диска. Или использование SAS 15k вместо 10k или (ужас) 7200.
За ссылку об архитектуре Haswell - спасибо, познавательно.
Еще, очень странная оценка в ИХ тесте:
Intel Xeon E3-1240 V2 @ 3.40GHz 9,333
Intel Xeon E3-1265L v3 @ 2.50GHz 8,998
Intel Xeon E3-1245 V2 @ 3.40GHz 8,994
Это, скорее всего, объяснить не трудно: процессоры с индексом L - это модели с пониженным энергопотреблением, и смотрите, частота ядра у них 2,5 ГГц, против 3,5 у модели без L. Правда, есть TurboBoost до 3,5 ГГц, но это, конечно, лишь кратковременный режим.
Что касается меньшей производительности модели с графическим ядром, ну, тут, думаю, все понятно. Если взять тот же 1245 и подключить внешнюю видеокарту, то, думаю, можно было бы получить совершенно идентичные цифры с 1240.
Ставить процессоры с графическим ядром на серверы, конечно же, нонсенс, но есть материнки (Супермикро на чипсете C216), у которых нет встроенного видео, и видеовыходы работают только если установлен проц с графикой. Понятно, что занимать PCI-E видеокартой - чушь, их и так еле-еле хватает на RAID-контроллер и SAS-экспандер, так что тут без альтернатив - ставить процы только с графикой (нет, ну как вариант - PCI-видеокарту, есть у меня в загашнике древний PCI матрокс).
Вообще, мне все больше кажется, что все это - поиск блох. Радикальное улучшение может дать лишь переход на двухпроцессорные системы с той же или большей ТЧ ядра, увеличение объема ОЗУ для очень больших БД, или, если говорить об архитектуре E3-12xx, то об улучшении IO - например, за счет увеличения количества шпинделей.
Скажем, простейшее решение: RAID-контроллер типа того же RS2BL080 и экспандер на 24 диска. Или использование SAS 15k вместо 10k или (ужас) 7200.
За ссылку об архитектуре Haswell - спасибо, познавательно.
(82)
"... все это - поиск блох. Радикальное улучшение может дать лишь переход на..."(с)
Именно это я и имел в виду по поводы Вашей фразы: "однозначно свидетельствуют в пользу"(с).
"Это, скорее всего, объяснить не трудно..."(с)
Почти ;-) согласен с Вашими объяснениями. Однако в (81) делал акцент на неприменимости ИХ сравнения для НАШИХ задач.
"... все это - поиск блох. Радикальное улучшение может дать лишь переход на..."(с)
Именно это я и имел в виду по поводы Вашей фразы: "однозначно свидетельствуют в пользу"(с).
"Это, скорее всего, объяснить не трудно..."(с)
Почти ;-) согласен с Вашими объяснениями. Однако в (81) делал акцент на неприменимости ИХ сравнения для НАШИХ задач.
(84) Gilev.Vyacheslav, а чего он сравнительное тестирование бенчмарками всякими не сделает, раз так уверен, что проблема в матчасти? Виртуалка в этом плане может оказаться зверьком весьма загадочным. К тому же не понятно, недостаток производительности дисковой подсистемы объективен или предположен на основании распространенного заблуждения...
(84) Gilev.Vyacheslav, Вячеслав Валерьевич, я только на Инфостарте успеваю отметиться, плюс рассылка PostgreSQL Performance тоже - день пропустил, сотни две сообщений не прочитал :-).
Тут я полностью с (85) согласен, виртуалки - вешь в себе. К тому же я по микрософтовским платформам отнюдь не спец. Вот Linux + PostgreSQL - другое дело, почти что конвейер.
Ставил на ProxMox сервер 1С + PostgreSQL, оба под CentOS (или Scientific), нормально все работало.
По теме.
Вот эта ошибка {Обработка.TCP_1C_GILV.Форма.Форма(656)}: Ошибка при вызове метода контекста (ConnectAgent): Произошла исключительная ситуация (V82.COMConnector.1): descr=Сервер недоступен (Не отвечает, завершается аварийно или порт занят другим приложением) line=557 file=Src\RemoteCreatorImpl.cpp
сервер недоступен, значит искать, почему так. Сначала это побороть, а потом уже говорить о низких показателях теста. Может, рабочих процессов не хватает, может с портами что-то напутано (например, 1641, а не 1541).
Тут я полностью с (85) согласен, виртуалки - вешь в себе. К тому же я по микрософтовским платформам отнюдь не спец. Вот Linux + PostgreSQL - другое дело, почти что конвейер.
Ставил на ProxMox сервер 1С + PostgreSQL, оба под CentOS (или Scientific), нормально все работало.
По теме.
Вот эта ошибка {Обработка.TCP_1C_GILV.Форма.Форма(656)}: Ошибка при вызове метода контекста (ConnectAgent): Произошла исключительная ситуация (V82.COMConnector.1): descr=Сервер недоступен (Не отвечает, завершается аварийно или порт занят другим приложением) line=557 file=Src\RemoteCreatorImpl.cpp
сервер недоступен, значит искать, почему так. Сначала это побороть, а потом уже говорить о низких показателях теста. Может, рабочих процессов не хватает, может с портами что-то напутано (например, 1641, а не 1541).
Вот потому-то и жду, когда сам смогу их потестировать. Пока вот двухпроцессорный аппарат "на стапеле", правда, не для 1С.
Еще вот не совсем понятно, почему энергопотребление у v3 заметно больше, чем у v2 (80 Вт против 60).
Еще вот не совсем понятно, почему энергопотребление у v3 заметно больше, чем у v2 (80 Вт против 60).
Хотел бы спросить у народа - слышал что частота работы оперативной памяти также влияет на работу 1С
Никто не проверял ?
например взять 16 Гиг DDR3 2200 MHz на сервере и провести замер производительности
а потом взять к примеру 16 Гиг DDR3 1600 MHz и также провести замер производительности
насколько система в первом случае будет быстрее работать ?
Никто не проверял ?
например взять 16 Гиг DDR3 2200 MHz на сервере и провести замер производительности
а потом взять к примеру 16 Гиг DDR3 1600 MHz и также провести замер производительности
насколько система в первом случае будет быстрее работать ?
Пример 2 базы УПП по 20Гб каждая, сервер 1C x64, sql x64 2008, озу 12Гб, массив SAS 15K RAID 5, и плюс виртуалка для обслуживания терминальных пользователей, на которой в добавок висит поисковый сервер sharepoint, обслуживает 10-12 пользователей 1С, тормоза проявляются не так часто, и пользователи практически не замечаются снижение производительности.
(94) alex_sh2008,
- это моя жизненная позиция))))
у меня домашний компьютер с 64 Гб оперативной памяти, он стоит меньше 100 0000 руб. Объясните мне, я один могу себе позволить такой компьютер, а организация с 50 сотрудниками нет - я богаче этой организации ?
Вы уверены что Вы знаете чем отличается сервер от рабочей станции
- это моя жизненная позиция))))
у меня домашний компьютер с 64 Гб оперативной памяти, он стоит меньше 100 0000 руб. Объясните мне, я один могу себе позволить такой компьютер, а организация с 50 сотрудниками нет - я богаче этой организации ?
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот