Реализация инфраструктуры 1С на базе Linux тема древняя, но до сих пор актуальная. Мы недавно публиковали статью Сервер приложений 1С на Linux, но остался открытым вопрос реальной производительности в сравнении с решением под Windows. Тестирование проводилось и в ручном режиме, но для объективности результатов я опубликую итоги теста Гилева, прошедшего на одной и той же аппаратной платформе с использованием разных ОС: Linux CentOS 7 и MS Windows Server 2012.

В качестве сервера использовался стенд с двумя процессорами Intel Xeon E5-2670, 8х4Гб ОЗУ и SSD Intel.

Сводная таблица средних значений результатов теста Гилева.
Linux Windows
Файловая база 51,2 53,4
SQL база 15,8 16,9

Примеры результатов




Приемлемые результаты тестирования, простота развёртывания и низкие затраты на лицензирование, побудили нас создать законченный продукт: Сервер 1С на базе Linux из коробки.

На платформе Windows есть аналогичная продуктовая линейка.

Каждая модель имеет удобный конфигуратор, в котором можно подобрать конфигурацию оптимальную для своих задач. Вот об этом чуть подробнее.

Создание калькулятора вычислительной мощности сервера 1С — задача не тривиальная. А создание универсального конфигуратора 1С под все возможные случаи — практически невозможная.

Наверняка на хабре много админов, у которых своё представление о нагрузке и требованиям к вычислительной мощности серверов под 1С (Ваши комментарии повысят ценность этой статьи). Есть и официальные рекомендации 1С, в которых будет работать всё на всём…

Но всё таки есть основные параметры, которые можно просчитать, применимо к типовой схеме эксплуатации. Зная сколько ресурсов процессора и оперативной памяти отнимает терминальная сессия, какое количество IOPS затребует SQL при определённом количестве пользователей, и отталкиваясь от результатов многочисленных тестов — мы разработали конфигуратор типового решения под 1С.

Безусловно каждый случай уникален и требует детального пресейла, но для ориентировочного расчета достаточно указать количество пользователей, тип базы, объём текущей базы и выбрать необходимые лицензии.

Для сравнения стоимости готового решения на базе Linux и Windows, приведу пример из конфигуратора с розничными ценами.

Сервер на 20 пользователей с базой SQL до 80Гб, лицензией 1С: Бухгалтерия 8 ПРОФ, на базе Linux CentOS будет стоить 522 759,43 руб. Аналогичная конфигурация на базе Windows — 1 036 279,43 руб.

Модельный ряд серверов для 1С STSS Flagman состоит из 3 моделей как для Linux, так и для Windows.


1C113.5-020UL — сервер 1С начального уровня, поддержка до 20 пользователей с базой SQL. Объём дискового пространства рассчитывается с учётом роста базы на 20% в год в течение 3 лет. Массив RAID1 строится на основе Enterprise SSD Intel. Возможна установка двойного БП и дополнительных дисков под «холодные» данные. Доступен выбор программных сервисов: PostgreSQL, xrdp и httpd.

1C216.4-200UL — модель на базе 2-процессорной платформы обеспечивающая работу 1C-инфраструктуры до 200 одновременных подключений. Хранилище рассчитывается по такому же принципу — размер базы с учётом роста, но строится на основе массива RAID10 из 4хSSD необходимого объёма.

1C217.2-050UL-REF — это решение для заказчиков с ограниченным бюджетом, построено на базе сервера восстановленного на нашем производстве (после гарантийной замены, демо-фонд и пр.) Серверы проходят такие же нагрузочные тесты перед отгрузкой, как и новые модели, но имеют сокращённый срок гарантийного обслуживания (1 год). Сервер поддерживает до 50 подключений и, без учёта лицензий, стоит всего 203 705,00 руб., с массивом под базу 40Гб.


1C113.5-020UW — сервер 1С начального уровня, поддержка до 20 пользователей с базой SQL. Объём дискового пространства рассчитывается с учётом роста базы на 20% в год в течение 3 лет. Массив RAID1 строится на основе Enterprise SSD Intel. Возможна установка двойного БП и дополнительных дисков под «холодные» данные.

1C216.4-200UW — модель на базе Windows с поддержкой до 200 пользователей. Хранилище строится на основе массива RAID10 из 4хSSD необходимого объёма.

1C217.2-050UW-REF — та же платформа, что и в решении на базе Linux. Бюджетный вариант на 50 подключений, гарантия 1 год.

В качестве платформы 1С во всех моделях можно выбрать следующие лицензии:
1С: Управление небольшой фирмой 8 ПРОФ
1С: Управление торговлей 8 ПРОФ
1С: Бухгалтерия 8 ПРОФ
1С: Бухгалтерия 8 КОРП
1С: Зарплата и управление персоналом 8 ПРОФ
1С: Зарплата и управление персоналом 8 КОРП
1С: Документооборот 8 ПРОФ
1С: Документооборот 8 КОРП

Если заказчик обладает достаточной экспертизой для подбора сервера под 1С, он может воспользоваться классическими моделями серверного оборудования. Но если подобной экспертизы нет, то, надеюсь, наш конфигуратор серверов для 1С поможет Вам сделать оптимальный выбор системы.

Спасибо за внимание! Надеюсь, что хабра-пользователи близкие к этой теме поделятся своим опытом в подборе оборудования под 1С в комментариях.
Считаете ли Вы подбор сервера под 1С тривиальной задачей?

Проголосовало 158 человек. Воздержалось 157 человек.

Доверяете ли Вы решению 1С на базе Linux?

Проголосовало 211 человек. Воздержалось 162 человека.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Поделиться с друзьями
-->

Комментарии (89)


  1. xRay
    13.10.2016 16:56

    Какой сервер СУБД был использован в тестах? PostgreSQL или MS SQL?


    1. Usikoff
      13.10.2016 17:04
      +3

      Для Linux использовался PostgreSQL, а для Windows — MS SQL


      1. Nikobraz
        13.10.2016 17:16
        +9

        Т.е. сравнивали теплое и мягкое


        1. ildarz
          13.10.2016 18:20
          +10

          Предмет сравнения в данном случае — производительность полного решения (и это единственная производительность, которая интересует конечного заказчика). С учетом того, что сравниваются именно наиболее распространенные варианты развертывания, не очень понятно, к чему тут могут быть претензии.


        1. dadyjo
          13.10.2016 18:56
          +3

          И еще наверное Postgre не настраивали, у него по дефолту настройки под слабое железо указаны. У 1С есть рекомендации по тонкой настройке.

          Я сравнивал производительность оптимизированного на производительность PostgreSQL и MS SQL 2012 под windows7/64 20гб ОЗУ Core i5 3.1

          Обновление не типовой конфигурации стоящей на поддержке, процесс трехстороннего сравнения занял:

          POSTGRE 15 минут
          MS SQL 20 минут
          Файловый режим 21 минута.


          1. dedyshka
            14.10.2016 09:55

            «И еще наверное Postgre не настраивали»… а, вы сиквел настраивали на производительность?


            1. dadyjo
              14.10.2016 10:54

              У MS SQL таких тонких настроек не особо много. Можно установить модель восстановления базы данных в «Простая», задать фиксированный размер памяти сервера и поиграться с параллелизмом выполнения запросов.

              У 1С есть рекомендации по настройке MS SQL, но они в основном заключаются в создании job-ов по переиндексации, обновлении статистики и очистке кэша.

              Возможно еще, что на быстродействие PostgreSQL в положительную сторону, влияет то, что у него база данных раскидана по множеству файлов, на каждую таблицу свой файл. И на SSD это дает преимущество перед MS SQL, у которого по умолчанию вся база хранится в одном файле. Но это не более чем предположение.


              1. navion
                14.10.2016 12:20
                +1

                Вот рекомендации по настройке MSSQL:
                Настройки Microsoft SQL Server для работы с 1С: Предприятием

                Никому не попадалось аналогичного документа для PostgreSQL?



          1. mrobespierre
            14.10.2016 09:57
            -3

            POSTGRES POSTGRES POSTGRES POSTGRES POSTGRES POSTGRES (Post IngreS)


      1. gotch
        13.10.2016 17:35
        +3

        А почему не PostgreSQL для Windows?


  1. potan
    13.10.2016 17:17
    +8

    — Петька, приборы?!
    — 51,2
    — Чего 51,2?
    — А чего «приборы»?

    Можно указывать в чем измеряются результаты тестов? В транзакциях в секунду?
    Хотя бы что лучше — меньше или больше?


    1. navion
      13.10.2016 17:19
      +2

      В Гилёвых, там же написано.


      1. hdfan2
        14.10.2016 09:22
        +1

        «Чем больше сдадим, тем лучше».


      1. pewpew
        14.10.2016 10:28
        +1

        И всё же «Гилевых».
        Даже на официальном сайте не нашёл написания с буквой «ё».


    1. dadyjo
      14.10.2016 11:04
      +1

      Больше лучше.
      В тесте используется набор простых операций: создать 5 тыс элементов справочников, записей в регистр сведений, документов итп. Это счетчик определенного набора записей высокоуровневых операций в секунду. Чем он больше тем лучше.


  1. kolu4iy
    13.10.2016 17:26
    +1

    Какая FS была в линукс-тесте? Какая конфигурация массива в обоих тестах? Какой I/O scheduler? Как настроен swappiness в линукс и какой и где файл подкачки в windows? Долго ли прогревался системный кеш перед запуском теста?


    1. Tihon_V
      13.10.2016 18:04

      И postgres.conf пожалуйста в студию!


    1. neumeika
      13.10.2016 18:39
      +2

      прошу прощения, FS-то как влияет на постгре? (это я, как бывший интегратор сего поделия, спрашиваю)
      конфиги железа, я так подозреваю, одинаковые были. Файл подкачки на том же рейде, имхо. Ну, и гилёв, конечно, только IO показывает, в основном. А вот на конфиг постгре, я бы тоже взглянул, вакуум, синк, кэш в дефолте уж очень убоги, в отличие от MS SQL


      1. kolu4iy
        14.10.2016 12:40

        Ну он же не прямо в устройство пишет, а пользуется ОС, которая для размещения данных пользуется файловой системой. А у разных FS все-же немного разная производительность. Те же ext2 и ext4, например, сравнить — журналирование на уровне fs таки привносит дополнительные расходы. Более сложные случаи и не беру даже.
        Отсюда же и вопрос про scheduler — на нормальном аппаратном контроллере с 4 Гб памяти лично у меня лучше всего работает noop, а на более простых железках с различными БД — deadline. Почему? Потому что noop не мешает рейд-контроллеру делать свою работу, в отличии от других i/o scheduler-ов. Тут разница, конечно, уже заметно выше, чем на типе fs.


  1. gotch
    13.10.2016 17:28
    +2

    Сервер на 20 пользователей с базой SQL до 80Гб, лицензией 1С: Бухгалтерия 8 ПРОФ,
    — на базе Linux CentOS будет стоить 522 759,43 руб.
    — на базе Windows — 1 036 279,43 руб

    Могли бы вы привести ваши расчеты?


    1. Etherius
      13.10.2016 18:35
      +2

      Разницу составляет стоимость лицензий MS: Server 2012 Std + CAL + RDS CAL + SQL 2016 + SQL CAL.
      Расчет делался на 20 терминальных пользователей.
      Безусловно эту разницу можно уменьшить, использовании Essentials и Runtime, но не значительно — и получая при этом существенные ограничения. А еще можно и PostgreSQL использовать, еще дешевле будет…
      Я не претендовал на заявление типа «Linux сервер 1С в 2 раза дешевле Windows сервера 1С!», просто так вышло в этом конкретном примере. Но разумеется, чем больше пользователей — тем больше разница, даже если переходить к лицензированию по ядрам.


      1. gotch
        13.10.2016 18:57
        +1

        Еще и терминальные лицензии? Тогда понятно. Но зачем? И в Linux у вас тоже все в терминале будут работать?

        Давайте дальше. На сервер с 20 пользователями вы ставите 24 CPU Cores. Это норма?
        PostgreSQL и для Windows, и для Linux бесплатен, установка, конфигурирование. Но вы добавили MS SQL Server. Хорошо, что взяли Standard, а не Enterprise на 24 ядра в AlwaysOn кластере — эта парочка обошлась бы в 18 903 000 рублей.

        И да, вы правы, есть широкие возможности оптимизации — от Essentials до покупки 2012 R2 с лицензией per CPU.

        Платформа Microsoft, разумеется, не бесплатная, и даже весьма дорогая. Но вы выбрали достаточно пограничную ситуацию.

        Что же вы вместо CentOS не посчитали Red Hat Enterprise Linux Server с Premium поддержкой?
        А вместо PostgreSQL — EnterpriseDB Postgres Plus Advanced Server 9.3 с ценником 1 791 705,36 за 24 ядра.


        1. Usikoff
          13.10.2016 19:23
          +2

          Михаил, добрый день. А где написано про 24 CPU Cores на 20 пользователей? Нигде по тексту найти не могу…
          А по терминалке под Linux, там вроде написано в описании модели, что да — xrdp.


          1. gotch
            13.10.2016 19:39

            Наверно, я неправильно понял некоторые выкладки из вашей статьи —

            Сервер на 20 пользователей с базой SQL до 80Гб, лицензией 1С: Бухгалтерия 8 ПРОФ, на базе Linux CentOS будет стоить 522 759,43 руб. Аналогичная конфигурация на базе Windows — 1 036 279,43 руб.


            Но чтобы получить цену как у вас, исходил из 24 ядер.

            Позиция Цена Кол-во Итого
            Windows Server 2016 5844 24 140256

            Windows Server CAL 2016 1549 20 30980

            Microsoft SQL Server 2014 Standard 47 556 1 5844

            Microsoft SQL Server CAL 11 068 20 221360

            Remote Desktop Services CAL 2016 5 809 20 116180

            Итого: 514620


            1. Usikoff
              13.10.2016 19:42
              +2

              Ясно, но по ценам ответ ниже уже был от автора — это не чистая стоимость лицензий, а разница между розничной стоимостью готового продукта.


  1. SyavaSyava
    13.10.2016 18:38

    Для интереса посчитал комплект SQL Server 2016 Std, WinServer 2016 Std, 20 пользовательских лицензий SQL, Server CAL, RDS CAL.
    Магазин — обычный с нормальными розничными ценами, лицензии на WinServer 2016 считались минимальные 16 ядер — вряд ли у вас больше в сервере начального уровня.

    Получилось 448 тыс. рублей, у вас разница Win/Lin — 514 тыс. рублей. Т.е. к рознице вы ещё накинули 66 тыс. рублей.
    Выше взяты обычные розничные цены на стандартное ПО, без ограничений.

    Если же брать SQL Server в комплекте с 1С, то даже по их рекомендуемым розничным ценам будет дешевле ещё на примерно 50 тыс. рублей. С учётом цен для «постоянных партнёров 1С» разница будет уже порядка 115 тыс. рублей.
    Понятно, что франчайзи не продаст вам лицензии по себестоимости, но у многих можно выторговать неплохую скидку.
    Ну и если брать пользовательские лицензии на устройства, а не на пользователя — то можно ещё сэкономить ещё тысяч 50 рублей.
    Итого минимально-возможная (условно) цена за WinServer + MS SQL + 20 users = 283 тыс. рублей.

    Вышеприведённые расчёты носят теоретический характер и не имеют целью задеть вашу систему ценообразования )))


    1. Etherius
      13.10.2016 18:53
      +2

      Я уже ответил на комментарий выше, но повторюсь. Этот расчет тоже не ставит цели задеть чью-либо систему ценообразования. Это разница в розничной стоимости готового изделия из коробки — с предустановкой и базовой преднастройкой. Разумеется, что есть система скидок, которая может существенно снизить стоимость в зависимости от ситуации. Не мне Вам объяснять зачем нужен розничный прайс. Правильно — для того чтобы делать хорошие партнёрские скидки.


      1. gotch
        13.10.2016 19:22

        Бизнес, конечно, есть бизнес, но внутренний голос говорит если уж и на Microsoft, то могли бы добавить в прайс и опцию PostgreSQL для Windows, получив вознаграждение за его настройку.


        1. Etherius
          13.10.2016 19:26
          +1

          Согласен с Вами. Справедливости ради надо добавить в конфигуратор и PostgreSQL и Runtime.


          1. gotch
            13.10.2016 19:41

            Крепко жмем вашу руку.


    1. navion
      13.10.2016 19:23
      +2

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

      Им уже разрешили давать скидки? ЕМНИП, 1С и Касперский запрещают партнёрам продавать ниже RRP.


      1. SyavaSyava
        13.10.2016 19:40

        Да, вы правы — уточнил у нашего партнёра-франчайзи, он говорит что 1С категорически «не одобрямс» такое. Конечно, при желании можно и обойти, но муторно и палевно (((


  1. akamap
    13.10.2016 19:31
    -3

    как у вас получилась разница между linux и windows решением в полмиллиона, если к примеру лицензия на mssql 2014 1c runtime на 20 пользователей и windows server essentials ~ 200 тыс…?


  1. ky0
    13.10.2016 19:31
    -1

    1. Берём постгрес, не настраивая (?) поднимаем над ним 1С
    2. Меряем производительность по сравнению с другой СУБД
    3.…
    4. 1С на линуксе оказался медленнее!


  1. a_shats
    13.10.2016 19:31
    +3

    Для начала — приветствую!
    И да, мне тоже интересны конкретные настройки — под Windows, Linux. Что как тестировали.
    И какие конкретно SSD от Intel — у разных моделей производительность (особенно на запись) — заметно разная.


  1. Sergey-S-Kovalev
    13.10.2016 21:08
    +3

    А я то наивно поверил, что от интегратора можно получить статью с полноценным тестированием. С описанием методологии, настроек оборудования и ПО.

    А тут пол статьи реклама «коробочных» решений.


    1. Usikoff
      13.10.2016 21:36

      Сергей, у нас есть все ресурсы для этого. Напишите конкретней, что надо досконально протестировать и описать — и такой статье быть!


      1. Sergey-S-Kovalev
        14.10.2016 06:52
        +1

        Вот смотрите.
        Берете три конфигурации. CentOS + PostgreSQL, Windows Server + PostrgreSQL, Windows Server + MS SQL

        Расписываете что вы там твикаете в каждой конфигурации. Потом как тестируете, акромя теста Гилева берете какую нибудь базу размером влазиющим в ваш самый дешевый пакетный тариф и делаете перепроведение документов, скажем за год. Это вполне типичная операция в 1С, когда при массовом перепроведении всех из базы выгоняют и кто то один делает эту работу. Потом говорите, что мол каждый конфиг за такое то время переварил 10 тыщ документов.

        Поскольку всегда найдется китаец который делает это лучше чем ты (с), в комментах к статье получаете кучу советов по оптимальному конфигурированию ОС и СУБД. Тестируете уже внутри конторы, улучшаете предоставляемые вами решения.

        На хабре плюсы в карму, бесплатный опыт сообщества интегрируете в свои решения. Все счастливы и танцуют.


        1. a_shats
          14.10.2016 10:32

          Не очень хороший вариант.
          И сам-то тест Гилева не особо чтобы отражал многопользовательскую нагрузку, а на том, что Вы предлагаете — и вовсе любой современный ПК если и не уделает сервер, то будет очень близко к тому по вполне очевидным причинам. Что, как Вы понимаете, отражать будет реальную повседневную работу сервера с многопользовательской нагрузкой чуть менее, чем никак.


          1. Sergey-S-Kovalev
            14.10.2016 10:40

            От чего то всеравно нужно отталкиваться. Гилевым пользуются потому что нет распиаренной методики тестирования производительности доступной для не 1С специалистов. Вот умные люди ниже советуют «1С: КИП или другие многопоточные тесты», и я склонен и на такой вариант согласиться. Главное что бы можно было воспроизвести, если уж не в таком же железе, то уж по софтварной части точно так же и понять, на что твое железо способно.


        1. sarge74
          14.10.2016 13:27
          +2

          Сергей, в ближайшее время будет написана более подробная статья, с подробнейшим описанием методов тестирования, софта и железа.
          В качестве основы будут предложенные вами связки: CentOS + PostgreSQL, Windows Server + PostrgreSQL, Windows Server + MS SQL.


  1. xRay
    14.10.2016 00:41

    Под linux есть facebook flashcache интересно было с его применением тесты глянуть


    1. neumeika
      14.10.2016 01:26
      +2

      смысла нет, обычно (в инсталяциях чуть больше среднего) 1с пихают на ssd сразу, минимум в рейд 1, т.е. около 100 000 моих любимых iops'иков на чтение (дураки, типа меня, даже размещали базы в RAM на гилёвометр). На текущий момент в архитектуре «больших» серверов 1с совсем другие проблемы.


  1. vadamlyuk
    14.10.2016 10:02
    +3

    Я думаю, стоит упомянуть 2 факта:

    1. Тест Гилева однопоточный — т.е. он показывает, грубо говоря, как быстро будет работать связка БД<=>1с-сервер<=>1с-клиент для одного сферического клиента в вакуме.

    Этот тест предназначен для сравнения разного железа в одинаковых конфигурациях и не очень подходит для сравнения разных решений на одном железе.

    Простой пример: на файловой базе тест Гилева дает, в среднем, в 4 раза более высокие результаты, чем _любое_ решение с реляционной БД, но в реальных условиях, когда количество пользователей > 3, за счет более высоких накладных расходов на блокировки, решение с файловой базой очевидно проигрывает решению с реляционной БД

    2. К сожалению, 1с для PostgreSQL — несет так же более высокие накладные расходы на блокировки, чем решение 1c для MS SQL Конкретно: если с MS SQL, 1c-сервер как правило накладывает блокировки уровня строки или row range (как лучше сказать — набор строк?), то в случае с PostgreSQL 1c-сервер накладывает, как правило, блокировки на всю таблицу.

    По этому, в теории, решение 1с+MS SQL в многопользовательском режиме будет всегда более производительно, чем решение 1c+PostgreSQL (и это не проблема PostgreSQL, а проблема того, как 1с работает с PostgreSQL).

    Как жаль, что автор сравнивая разные решения на одинаковом железе решил использовать тест Гилева, а не тесты из 1с: КИП или другие многопоточные тесты, и, тем самым, не дал ответ на вопрос, на сколько сильно решение Linux+PostgreSQL+1c будет отставать от Win+MSSQL+1c в реальных конфигурациях для 5-20-50-100 пользователей


    1. dadyjo
      14.10.2016 11:27

      «в случае с PostgreSQL 1c-сервер накладывает, как правило, блокировки на всю таблицу.»

      В режиме управляемых блокировок в транзакции, PostgreSQL блокирует на уровне записей.

      «на сколько сильно решение Linux+PostgreSQL+1c будет отставать от Win+MSSQL+1c в реальных конфигурациях для 5-20-50-100 пользователей»

      Нужно так же понимать, что многопоточная производительность в конкретной конфигурации будет зависеть от того, как это самое решение спроектировано и написано. Тест Гилева как раз показывает «честную» скорость при сравнении различных ОС и БД.

      Для тестирования 1с в режиме многопоточности то же есть тест Многопоточный тест производительности 1с


      1. vadamlyuk
        14.10.2016 11:51

        Для тестирования 1с в режиме многопоточности то же есть тест Многопоточный тест производительности 1с


        Прикольно, попробую…

        Жаль, что в отличие от Гилева в таблице на сайте не приводятся конфигурации серверов, на которых проводились испытания.

        И вторая проблема — непонятно значение столбцов «Сумма одного потока» и «Сумма 96 потоков», точнее очень удивляет тот факт что эти значения не коррелируют между собой (при схожих значениях одного столбца большой разброс значений во втором столбце и наоборот)


        1. dadyjo
          14.10.2016 13:40

          Есть информация о железе в конкретных тестах внизу в самом Ссылка

          Корреляция отсутствует возможно из за того что запускали к примеру в тесте 16 потоков на 4 ядрах.


          1. neumeika
            14.10.2016 15:25

            «1С: КИП»
            Был у меня смешной опыт, когда Azure ещё только начинал заставлять себя не любить (сейчас ситуация исправилась), от 200 клиентов КИП, архитектура на 3-6 серверов, выдавали результаты аж в 2 раза различающиеся :)
            Но в целом «годный» тест, опять же, при количестве пользователей от 100 всё упирается в частоту проца и качество кода
            За «Многопоточный тест производительности 1с» спасибо, оно различную нагрузку умеет? или тупо параллельки процессов рожает?
            Самый правильный вариант — запускать тонну клиентов и смотреть, как погибают сервера.


            1. Fragster
              17.10.2016 10:53

              рождает кучу параллельных процессов по записи справочников, наборов регистров сведений, накопления, бухгалтерии и заполнения временных таблиц. Кстати, до недавнего времени в постгре наблюдалась печальная картина по временным таблицам относительно mssql. но то ли платформа научилась с ними работать, то ли конфиги по дефолту более правильные, то ли админы научились ее настраивать — ситуация с ними выправилась.

              вот печаль: http://fragster.ru/perfomanceTest/result.php?guid=f9353dd0-fb3b-11e5-960a-00151741bd35
              вот норма: http://fragster.ru/perfomanceTest/result.php?guid=96eeefe4-6017-11e6-509c-0025906a818a
              (абсолютные цифры не интересны, смотрите соотношение «физических» и «временных» таблиц, на mssql картины, как в «печаль» — нет. Для просмотра на графике надо ткнуть во «временные таблицы» в легенде графика).
              а вот как бывает проседает (при неправильной настройке?) постгре: http://fragster.ru/perfomanceTest/result.php?guid=aaa53aee-90bd-11e6-468a-000c29568094, опять же, у mssql подобной картины практически никогда не наблюдается. здесь нужно смотреть соотношение максимума к попугаям на максимальном количестве потоков.


        1. Fragster
          15.10.2016 17:48

          Потому что в один поток какой-нибудь i5 к-серии 4.2ггц будет быстрее зеона 2.6ггц. А 1с, она, сволочь такая, приспособлена как правило для многопользовательской работы.


  1. panvartan
    14.10.2016 10:04
    -2

    результаты тестов крайне низкие — 16-17 гилевых для sql и 50 для файла — это уровень e5430, если кто еще помнит такие камни. Видеть такие цифры от продавцов решения за миллион рублей как-то странно.


  1. serg_p
    01.02.2017 21:44

    У меня у входа в спальню — включатель + дубляж с каждой стороны кровати, лет 10 так.


  1. shadovv76
    02.02.2017 10:24
    +1

    решение преследовало цель никаких батареек в главном выключателе. Жена не приемлет не работающие выключатели даже временно (типа до прихода мужа).
    1. контроллер (nrf24le1) в тарелке люстры питается через емкостной делитель
    2. в выключатель подсовывается под одну сторону качели пружина (есть наверное и готовые) и он постоянно замкнут
    3. параллельно замкнутому выключателю стоит конденсатор по емкости равный тому же, что и в делителе.
    Работа:
    контроллер постоянно запитан
    при нажатии к емкостному делителю подключается последовательно конденсатор выключателя
    напряжение на контроллере снижется и его встроенная схема контроля напряжения формирует прерывание.
    время нажатия замеряется и далее програмная обработка до 5 сек инверсия нагрузки, 5-10 режим прошивки по воздуху, более 10 сек, перезапуск.
    Контроллер также управляется ИК пультом считывая с TSOP датчика код и может сохранить одну кнопку пульта ТВ (я использую цветную) и встраивается по принципу плаг и плэй в сеть 2,4Гц с выделенным аналогичным контроллером в качестве концентратора сети. далее мост NRF-ESP и прога на компе.

    Но ясно что Вы искали промышленное решение.


  1. rrrav
    14.10.2016 15:41

    Серверный SSD дороговато стоит, делать из него зеркало — умножать затраты. Можно сэкономить, используя возможность Streaming Replication PostgreSQL — вести резервную базу на обычных HDD (в RAID, конечно). WAL PostgreSQL можно тоже писать на обычный HDD — там последовательная запись.
    Streaming Replication не сильно грузит Master, зато всегда имеем актуальную копию. Есть некоторая проблема в том, что транзакции 1С не совпадают с транзакциями БД, но привести Slave базу в согласованное состояние можно.
    Серверный SSD весьма надежен и имеет предсказуемое время отказа, надо только время от времени прогонять smartctl, поэтому вероятность плохого сценария невысока.


    1. neumeika
      14.10.2016 17:43
      +1

      Весь вопрос, сколько стоит простой сервиса. Ибо скорость восстановления предложенного решения не моментальная, а если ещё в базе есть живые деньги, то необходимо восстановить всё до копейки/транзакции.
      Всё зависит от SLA :)
      В некоторых случаях оправданно держать «зеркальное оборудование» в кластере.


      1. shifttstas
        02.02.2017 15:37

        P.S. Ах да, кому совсем не лежа никак — делают второй включатель около кровати.

        Вот собственно этот кейс я и рассматривал.

        Плюс в дальнейшем я планирую продолжить замену выключателей на реле и последующую интеграцию с Apple Homekit


        1. neumeika
          14.10.2016 23:28
          +1

          так, а потупить можно? видимо я не догоняю, чем отличаются транзакции 1с от скулёвых?
          1с: — слышь скуль, ну к пихни мне документик
          sql: — окей, братуха, вот положительный ответ от инсерта
          Либо Вы имеете ввиду, что базу лучше бэкапить только средствами 1с? Типа надёжнее?
          Работая во франче, у меня были беды как раз с бэкапами средствами 1с, базам я доверяю больше :)


          1. rrrav
            15.10.2016 00:00

            1 транзакция 1с может составить несколько транзакций в БД, увы. То есть в терминах БД база будет находиться в согласованном состоянии после крэша (откатились незаконченные транзакции), но для 1с это не обязательно будет согласованным состоянием. Но средствами 1с можно восстановить согласованность.
            А бэкапить базу средствами 1с слишком дорогое удовольствие — надо всех из базы выгонять. (Ночью, само собой, надо бэкапить средствами 1с.)
            Standby slave забирает WAL в асинхронном режиме, поэтому не нагружает мастер, но из-за этого возможно небольшое отставание, хотя и гарантируется согласованность базы, но не в терминах 1с.


        1. neumeika
          14.10.2016 23:33
          +1

          Либо:
          1с: проведи документ
          sql: 1-ый update ok, 2-ой — нет?
          лечить только исправлением в 1с базы
          мы поняли друг друга?


  1. mgis
    14.10.2016 17:11
    -1

    Ребята, а правда что, RAID0 из 2-х SSD это зло?
    У меня уже год как на таком сервере вся 1С крутится. Бэкапы разумеется на внешний диск.


    1. neumeika
      14.10.2016 17:25

      который подключен к этому серверу? Завидую отваге любителей страйпа :)
      Данные за небекапнутый день сами набивать будете?


      1. dadyjo
        14.10.2016 17:53

        Можно раз в день полный бэкап и каждые X минут разностный делать в зависимости от интенсивности ввода данных.

        Вместо Raid0 можно купить PCI SSD. В рэйде не у всех дисков trim работает.


        1. a_shats
          17.10.2016 14:11

          В аппаратном RAID (в режиме именно RAID, а не HBA) ни у каких SSD Trim не работает — потому, что конкретно Trim там не нужен.
          Там выполняются команда SCSI UNMAP, и это делает сам контроллер.


      1. mgis
        15.10.2016 08:49

        Ну разумеется, который подключен к этому серверу, а как же ещё :).
        Изначально все с кем не советовался, умоляли не ставить RAID0 из SSD, причем никто из советовавших кроме аргумента про риски ничего конкретное сказать не мог. Решил разорвать шаблон и сделать по своему. И вы знаете, я доволен. Скорость просто космическая =)
        Ах да разностный бэкап, сегодня же попробую настроить.


    1. a_shats
      17.10.2016 14:12
      +1

      RAID0 для любых данных, которые надо хранить больше суток — зло.
      Как и «диск в ОЗУ» (ramdisk и иже с ним).

      Собственно, владельцы оных радуются производительности обычно ровно до первого серьезного падения.


      1. neumeika
        17.10.2016 19:18
        +1

        поклёпа на RAM диск не надо, никто в здравом уме его не будет на бой пихать. Я его использовал только для тестов, чтобы понять, где бутылочное горлышко.
        Я stripe`любовцев-то считаю людьми с ограниченным стратегическим мышлением :)


        1. a_shats
          18.10.2016 10:39

          В том-то и печаль, что мало того, что пихают в продакшн, так еще и людям рекомендуют.
          Как бы местами даже серьезные франчайзи.


          1. Fragster
            18.10.2016 10:42

            Ну, перемещение темпов, сеансовых данных, кэша конфигураций на рамдиск дает хороший приход по производительности. В общем всё то, с чем идет работа, но сохранять не надо.


            1. a_shats
              18.10.2016 13:59

              Это в сильно редких ситуациях, КМК, есть возможность использовать дорогой (за объем) и ограниченный ресурс ОЗУ гораздо более разумным образом.


  1. s_litvinov
    14.10.2016 18:16

    Судя по результатам теста на Windows, автор не поставил режим «Высокая производительность» в настройках электропитания. На этом процессоре результат должен быть выше. Зачем использовать для теста именно 2670? 1С и особенно тест Гилева чувствителен к частоте процессора.
    Автор умолчал, что результат теста в 15 это 3 по 5 бальной шкале теста. Для 2670 такой результат это слишком дорого.
    Тест Гилева измеряет еще однопоточную и многопоточную запись и выдает рекомендации по количеству пользователей. Почему их не привели?
    Зачем брать для теста камень 3к'14 года за $1593.00 (цены с сайта intel, 4й 2670 редакции не нашел на сайте) если можно использовать 2637 даже той же 3 редакции за $996.00 и результат в «попугаях» так и в реальной работе будет выше? Или даже однопроцессорный вариант последних редакций? Кстати, а какие процессоры в ваших конфигурациях? Нашел в описании «процессора Intel® Xeon® серии E5-2600 v4»? А ведь результаты тестов на разных моделях этого семейства совсем разные. В тех же попугаях разница между Intel® Xeon® Processor E5-2620 v4 (20M Cache, 2.10 GHz) и Intel® Xeon® Processor E5-2637 v4 (15M Cache, 3.50 GHz) в два раза. А по ощущениям работы пользователей, пока 2620 не поменял, работать активным пользователям в подборе было невозможно.
    Какие модели SSD используете? Зачем из них RAID делать? Исходя из каких тестов и и результатов вы решили, что нужен RAID 10?


    1. Etherius
      14.10.2016 18:18
      +1

      Дык задача стояла не тестировать железо, а тестировать разные платформы на одном и том же железе, и не важно каком.


      1. s_litvinov
        14.10.2016 18:31

        Тест некорректен. При выставленном правильном режиме производительности на MS SQL результат должен быть в районе 25-30 на этом процессоре. Это один переключатель, То что он стоит по дефолту это ошибка. И уже картина не такая радужная. Хотя может и в PostgreSQL и Linux есть такие же настройки, но знакомый линуксойд говорит, что только в винде додумались ставить этот признак по дефолту в режим экономии энергии.


        1. neumeika
          14.10.2016 18:39

          Смотрите дальше тестов. Есть альтернативы, выбор за Вами:
          1. win/lin
          2. Дешевле/дороже
          3. Сложнее/проще
          4. Ваше любимое: быстрее/медленнее
          Все нюансы не предусмотришь, когда у нас делали аналитику, можно было трактаты писать в сотню страниц и книги выпускать.


        1. a_shats
          17.10.2016 14:34

          >При выставленном правильном режиме производительности на MS SQL результат должен быть в районе 25-30 на этом процессоре. Это один переключатель,
          Будьте добры, аргументируйте пожалуйста вот это высказывание. Своими словами, если можно.


          1. s_litvinov
            17.10.2016 18:24

            Зачем своими? Вот статья с сайта того же Гилева. http://www.gilev.ru/systemperfomance/


            1. a_shats
              18.10.2016 11:27

              Я почему и предлагал своими словами.
              FYI: по умолчанию, в штатной схеме энергосбережения в Windows Server 2012 R2 TurboBoost включен.


    1. a_shats
      17.10.2016 14:33

      Вы исходите из целого ряда неверных предпосылок.
      Во-первых, брали что было под руками свободное, скорее всего- производительность процессоров и их ядер как таковую в данном тесте ни с чем не сравнивали.
      Сравнивали, если Вы не обратили внимание, варианты решения на разных программных платформах.
      Во-вторых, E5-2637V4 будет производительнее, чем Е5-2670 отнюдь не в любых ситуациях, по вполне понятным причинам.
      >Зачем из них RAID делать? Исходя из каких тестов и и результатов вы решили, что нужен RAID 10?
      Вот по этим вопросам очень странно выглядит Ваш наезд. Если Вы не знаете, зачем в сервере базы данных RAID, почему именно RAID10 нужен под 1С — может быть, сначала сами для себя уточните этот вопрос?
      Опять-таки, компания, представитель которой эту статью написал, не занимается массовой продажей тестовых стендов — а именно готовых решений.


      1. s_litvinov
        17.10.2016 18:47

        Не на всех SSD хорошо работает TRIM если использовать RAID. Если на диске плохо работает сборщик мусора, будут проблемы (особенно когда экономят и ставят пользовательские модели, а не серверные). Наблюдал картину, когда на сервере с RAID из SSD не был настроен бэкап журнала транзакций и стояла модель восстановления FULL. Диск был полностью забит журналом. После очистки диска от журнала транзакций, наблюдалась деградация производительности массива на запись. Raid 1 из 2 SSD выдавал скорость записи как одиночный HDD. Из практики, 200 активным пользователям не удается создать значимой очереди на диски при конфигурации из 3 SSD дисков (1.под систему, 1 под базу, 1 по журнал транзакций). Нужно только озаботиться настройкой бэкапа и резервного сервера. Система упирается в скорость процессора, а не в дисковую подсистему.
        Из практики, на E5-2637 1С будет быстрее отрабатывать транзакции, значит будет меньше шансов на блокировку. С учетом рекомендуемых настроек MS SQL max degree of parallelism=1 и настройками сервера 1С, ядер на 37 хватит за глаза, а транзакции будут проходить быстрее.Так что для задачи 1С+MS SQL 37 предпочтительнее. Если у вас действительно не будет хватать ядер, есть еще 2643.
        Вопрос по «Кстати, а какие процессоры в ваших конфигурациях? Нашел в описании «процессора Intel® Xeon® серии E5-2600 v4»? » относился к их конфигуратору, а не к текущему тесту. Для сервера под 1С и SQL ОЧЕНЬ важен процессор. Опять же сравнение 2620 и 2637 взято из практики. А у них в конфигураторе серверов, опции выбора таковой частоты нет. Ну получится картина, когда я имел меньше опыта, послушал «специалистов», и взяли платформу на 4 SSD но с 2620. Пользователи меня чуть не убили, потому что новый сервер работал тупо медленнее почти в 2 раза, чем старый у которого тактовая частота была просто выше. База одна и та же, дисковая подсистема в разы быстрее, а запись в регистры в 2 раза медленнее.


        1. a_shats
          18.10.2016 11:32

          >Не на всех SSD хорошо работает TRIM если использовать RAID
          В аппаратных RAID нет TRIM, там есть SCSI-команда UNMAP, она и используется. Уже писал в этой теме.
          >Из практики, на E5-2637 1С будет быстрее отрабатывать транзакции, значит будет меньше шансов на блокировку.
          Зависит от многих факторов, и в первую очередь — от количества активных пользовательских сессий.
          Всё же 8/16 (с двумя процессорами) логических ядер маловато бывает — при всей их замечательной производительности.
          >Если у вас действительно не будет хватать ядер, есть еще 2643.
          У него цена несколько… не щадящая.
          Но да, он разумнее.
          >Пользователи меня чуть не убили, потому что новый сервер работал тупо медленнее почти в 2 раза
          Ну, не в два. а в полтора :) Но да, есть такое дело.


  1. rrrav
    15.10.2016 12:22

    Кстати, не увидел (или проглядел) в статье, какая разрядность 1с использовалась. Разница в цене между 32 и 64 битными версиями помню приличная, но необходимости в х64 версии я пока не ощутил — процесс rphost редко добирается до 1Гб памяти, обычно 300-600 Мб. В тесте Гилева вообще потребление памяти небольшое.
    Есть ли вообще смысл в дорогой 64 битной версии?
    (Разумеется, про PostgreSQL такой вопрос не стоит, там однозначно 64.)


  1. neumeika
    15.10.2016 13:25

    в редакции на 32 бита ограничение на процесс 2 гига, вроде. Но, как вы сами сказали, вам это не нужно.
    Видимо и клиентов у вас мало, и база небольшая, и аналитики дикой нет (ну не сервер 1с же они оптимизировали :))
    у меня на паре проектов и 16 гигов кушать изволило


    1. rrrav
      15.10.2016 19:43

      16 G на один процесс rphost? Или общее потребление всеми rphost?


      1. neumeika
        15.10.2016 20:05
        +1

        Всеми. Но вот в конфиг я давно не глядел, в 8.2 делали их равным количеству процов, а вот в 8.3 оно само как-то на основании количества коннектов, или пожираемой памяти. В старых платформах начинались тупняки после того, как рабочий процес занимал более 2Гб, сейчас этого не наблюдаю. Но то, что 1 rphost бывал в районе 8 Гб точно помню.


        1. rrrav
          15.10.2016 20:14

          Кажется много можно запустить процессов rphost, издержки не велики. На 64х платформе и один rphost может утилизировать всю память, а на 32х запуск многих rphost вроде как позволяет масштабировать сервер.


          1. neumeika
            15.10.2016 20:24
            +1

            1 ИБ — 1 процесс, так выгоднее типа, если верить документации.
            В 8.3 у 32-ух битной редакции в парамах процесса поставить максимум 2Гб, оно и будет множится. Единственно, не обращал внимания, как оно это делает, рожает новый или child процесс.
            И я никогда не сталкивался, что будет, если 32-ух битному рабочему процессу не хватит 2Гб памяти на какое-нить перепроведение :)


            1. dadyjo
              15.10.2016 23:59
              +1

              На клиенте выскакивает ошибка обычно, для выполнения запроса недостаточно памяти

              «Ошибка SDBL. Недостаточно памяти для выполнения запроса» и две кнопки на выбор завершить или перезапустить.


      1. dadyjo
        15.10.2016 23:56
        +1

        Я видел где 1С порядка 160Гб использовала в результате утечки памяти. База упала по причине израсходования всей памяти на сервере с 256Гб ОЗУ :)


        1. rrrav
          16.10.2016 16:45

          А на 32х версии такого бы не случилось ;-). Ну и винтажно бы смотрелась 32х битная версия на сервере с 256Гб ОЗУ.