Pull to refresh

Comments 93

Для Linux использовался PostgreSQL, а для Windows — MS SQL
Т.е. сравнивали теплое и мягкое
Предмет сравнения в данном случае — производительность полного решения (и это единственная производительность, которая интересует конечного заказчика). С учетом того, что сравниваются именно наиболее распространенные варианты развертывания, не очень понятно, к чему тут могут быть претензии.
Производительность полного решения очень сильно зависит от выбранного сервера СУБД и, как ни странно, от используемой конфигурации 1С. На разных конфигурациях 1С сервера СУБД дают весьма разные результаты. Я не тестировал сервер 1С под Linux, но под Windows столкнулся с тем, что конфигурация 1С ЗУП (корп) работала под Oracle гораздо медленнее, чем под MS SQL, в то время как 1С Бухгалтерия (корп) под Oracle была несколько быстрее, чем под MS SQL.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
POSTGRES POSTGRES POSTGRES POSTGRES POSTGRES POSTGRES (Post IngreS)
А почему не PostgreSQL для Windows?
— Петька, приборы?!
— 51,2
— Чего 51,2?
— А чего «приборы»?

Можно указывать в чем измеряются результаты тестов? В транзакциях в секунду?
Хотя бы что лучше — меньше или больше?
В Гилёвых, там же написано.
«Чем больше сдадим, тем лучше».
И всё же «Гилевых».
Даже на официальном сайте не нашёл написания с буквой «ё».
UFO just landed and posted this here
Скажите, я правильно понял, что линуксовая конфигурация чуть медленне, но почти вдвое дешевле?
Какая FS была в линукс-тесте? Какая конфигурация массива в обоих тестах? Какой I/O scheduler? Как настроен swappiness в линукс и какой и где файл подкачки в windows? Долго ли прогревался системный кеш перед запуском теста?
И postgres.conf пожалуйста в студию!
прошу прощения, FS-то как влияет на постгре? (это я, как бывший интегратор сего поделия, спрашиваю)
конфиги железа, я так подозреваю, одинаковые были. Файл подкачки на том же рейде, имхо. Ну, и гилёв, конечно, только IO показывает, в основном. А вот на конфиг постгре, я бы тоже взглянул, вакуум, синк, кэш в дефолте уж очень убоги, в отличие от MS SQL
Ну он же не прямо в устройство пишет, а пользуется ОС, которая для размещения данных пользуется файловой системой. А у разных FS все-же немного разная производительность. Те же ext2 и ext4, например, сравнить — журналирование на уровне fs таки привносит дополнительные расходы. Более сложные случаи и не беру даже.
Отсюда же и вопрос про scheduler — на нормальном аппаратном контроллере с 4 Гб памяти лично у меня лучше всего работает noop, а на более простых железках с различными БД — deadline. Почему? Потому что noop не мешает рейд-контроллеру делать свою работу, в отличии от других i/o scheduler-ов. Тут разница, конечно, уже заметно выше, чем на типе fs.
Сервер на 20 пользователей с базой SQL до 80Гб, лицензией 1С: Бухгалтерия 8 ПРОФ,
— на базе Linux CentOS будет стоить 522 759,43 руб.
— на базе Windows — 1 036 279,43 руб

Могли бы вы привести ваши расчеты?
Разницу составляет стоимость лицензий MS: Server 2012 Std + CAL + RDS CAL + SQL 2016 + SQL CAL.
Расчет делался на 20 терминальных пользователей.
Безусловно эту разницу можно уменьшить, использовании Essentials и Runtime, но не значительно — и получая при этом существенные ограничения. А еще можно и PostgreSQL использовать, еще дешевле будет…
Я не претендовал на заявление типа «Linux сервер 1С в 2 раза дешевле Windows сервера 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 ядра.
Михаил, добрый день. А где написано про 24 CPU Cores на 20 пользователей? Нигде по тексту найти не могу…
А по терминалке под Linux, там вроде написано в описании модели, что да — xrdp.
Наверно, я неправильно понял некоторые выкладки из вашей статьи —
Сервер на 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
Ясно, но по ценам ответ ниже уже был от автора — это не чистая стоимость лицензий, а разница между розничной стоимостью готового продукта.
А где разница в обслуживании?
А сложность найти линуксового админа, особенно в «глубинке» (города со 100к-500к населения)?

В общем «полное решение» рассчитывается несколько иначе обычно.
Считают не только цену закупки всего необходимого, но и цену обслуживания и поддержки за какой-то период. В год/день/… как удобно…
UFO just landed and posted this here
Я уже ответил на комментарий выше, но повторюсь. Этот расчет тоже не ставит цели задеть чью-либо систему ценообразования. Это разница в розничной стоимости готового изделия из коробки — с предустановкой и базовой преднастройкой. Разумеется, что есть система скидок, которая может существенно снизить стоимость в зависимости от ситуации. Не мне Вам объяснять зачем нужен розничный прайс. Правильно — для того чтобы делать хорошие партнёрские скидки.
Бизнес, конечно, есть бизнес, но внутренний голос говорит если уж и на Microsoft, то могли бы добавить в прайс и опцию PostgreSQL для Windows, получив вознаграждение за его настройку.
Согласен с Вами. Справедливости ради надо добавить в конфигуратор и PostgreSQL и Runtime.
Крепко жмем вашу руку.
Понятно, что франчайзи не продаст вам лицензии по себестоимости, но у многих можно выторговать неплохую скидку.

Им уже разрешили давать скидки? ЕМНИП, 1С и Касперский запрещают партнёрам продавать ниже RRP.
UFO just landed and posted this here
как у вас получилась разница между linux и windows решением в полмиллиона, если к примеру лицензия на mssql 2014 1c runtime на 20 пользователей и windows server essentials ~ 200 тыс…?
1. Берём постгрес, не настраивая (?) поднимаем над ним 1С
2. Меряем производительность по сравнению с другой СУБД
3.…
4. 1С на линуксе оказался медленнее!
Для начала — приветствую!
И да, мне тоже интересны конкретные настройки — под Windows, Linux. Что как тестировали.
И какие конкретно SSD от Intel — у разных моделей производительность (особенно на запись) — заметно разная.
А я то наивно поверил, что от интегратора можно получить статью с полноценным тестированием. С описанием методологии, настроек оборудования и ПО.

А тут пол статьи реклама «коробочных» решений.
Сергей, у нас есть все ресурсы для этого. Напишите конкретней, что надо досконально протестировать и описать — и такой статье быть!
Вот смотрите.
Берете три конфигурации. CentOS + PostgreSQL, Windows Server + PostrgreSQL, Windows Server + MS SQL

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

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

На хабре плюсы в карму, бесплатный опыт сообщества интегрируете в свои решения. Все счастливы и танцуют.
Не очень хороший вариант.
И сам-то тест Гилева не особо чтобы отражал многопользовательскую нагрузку, а на том, что Вы предлагаете — и вовсе любой современный ПК если и не уделает сервер, то будет очень близко к тому по вполне очевидным причинам. Что, как Вы понимаете, отражать будет реальную повседневную работу сервера с многопользовательской нагрузкой чуть менее, чем никак.
От чего то всеравно нужно отталкиваться. Гилевым пользуются потому что нет распиаренной методики тестирования производительности доступной для не 1С специалистов. Вот умные люди ниже советуют «1С: КИП или другие многопоточные тесты», и я склонен и на такой вариант согласиться. Главное что бы можно было воспроизвести, если уж не в таком же железе, то уж по софтварной части точно так же и понять, на что твое железо способно.
Сергей, в ближайшее время будет написана более подробная статья, с подробнейшим описанием методов тестирования, софта и железа.
В качестве основы будут предложенные вами связки: CentOS + PostgreSQL, Windows Server + PostrgreSQL, Windows Server + MS SQL.
Под linux есть facebook flashcache интересно было с его применением тесты глянуть
смысла нет, обычно (в инсталяциях чуть больше среднего) 1с пихают на ssd сразу, минимум в рейд 1, т.е. около 100 000 моих любимых iops'иков на чтение (дураки, типа меня, даже размещали базы в RAM на гилёвометр). На текущий момент в архитектуре «больших» серверов 1с совсем другие проблемы.
Я думаю, стоит упомянуть 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 пользователей
UFO just landed and posted this here
Для тестирования 1с в режиме многопоточности то же есть тест Многопоточный тест производительности 1с


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

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

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

UFO just landed and posted this here
«1С: КИП»
Был у меня смешной опыт, когда Azure ещё только начинал заставлять себя не любить (сейчас ситуация исправилась), от 200 клиентов КИП, архитектура на 3-6 серверов, выдавали результаты аж в 2 раза различающиеся :)
Но в целом «годный» тест, опять же, при количестве пользователей от 100 всё упирается в частоту проца и качество кода
За «Многопоточный тест производительности 1с» спасибо, оно различную нагрузку умеет? или тупо параллельки процессов рожает?
Самый правильный вариант — запускать тонну клиентов и смотреть, как погибают сервера.
рождает кучу параллельных процессов по записи справочников, наборов регистров сведений, накопления, бухгалтерии и заполнения временных таблиц. Кстати, до недавнего времени в постгре наблюдалась печальная картина по временным таблицам относительно 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 подобной картины практически никогда не наблюдается. здесь нужно смотреть соотношение максимума к попугаям на максимальном количестве потоков.
Потому что в один поток какой-нибудь i5 к-серии 4.2ггц будет быстрее зеона 2.6ггц. А 1с, она, сволочь такая, приспособлена как правило для многопользовательской работы.
результаты тестов крайне низкие — 16-17 гилевых для sql и 50 для файла — это уровень e5430, если кто еще помнит такие камни. Видеть такие цифры от продавцов решения за миллион рублей как-то странно.
Простите, а зарплату сисадмина не учитывается в расчетах? для windows сисадмин 30 к в месяц, а для linux 60 к в месяц, да еще попробуй найди толкового, который будет возиться с этой конфигурацией. Если все посчитать то разницы между этими решениями будет минимальная, а надежность работы сомнительна… потому что это мать его 1С!!!
Сравнение не верное в корень. Хороший win администратор стоит не дешевле никсового. Колхозников, способных как то поднять это на винде — действительно больше. Но это делает их администраторами.

Но основной Ваш посыл абсолютно верен. Стоимость и нюансы эксплуатации надо учитывать даже в большей степени, нежели цену продукта. Что очень часто не делается.
1С умеет СУБД использовать по-нормальному с учетом особенностей конкретной СУБД?

Зачем 1С требуется патченый (именно патченый) PostgreSQL? На сколько я помню они этими патчами засунули механизм блокировок в версионный PostgreSQL. Самая свежая версия PostgreSQL патченного под 1С сейчас 9.4.9 (в тесте 9.5.4). А последний релиз у PostgreSQL версии 9.6.
Серверный SSD дороговато стоит, делать из него зеркало — умножать затраты. Можно сэкономить, используя возможность Streaming Replication PostgreSQL — вести резервную базу на обычных HDD (в RAID, конечно). WAL PostgreSQL можно тоже писать на обычный HDD — там последовательная запись.
Streaming Replication не сильно грузит Master, зато всегда имеем актуальную копию. Есть некоторая проблема в том, что транзакции 1С не совпадают с транзакциями БД, но привести Slave базу в согласованное состояние можно.
Серверный SSD весьма надежен и имеет предсказуемое время отказа, надо только время от времени прогонять smartctl, поэтому вероятность плохого сценария невысока.
Весь вопрос, сколько стоит простой сервиса. Ибо скорость восстановления предложенного решения не моментальная, а если ещё в базе есть живые деньги, то необходимо восстановить всё до копейки/транзакции.
Всё зависит от SLA :)
В некоторых случаях оправданно держать «зеркальное оборудование» в кластере.
Все так, конечно, и сводится к стоимости простоя. Но в статье идет речь и о бюджетных решениях. Там, где час простоя не вызовет катастрофы, вполне сгодится и решение со standby сервером вместо зеркала на SSD.
Судя по обзорам, интеловские серверные SSD вполне себе надежные, вероятность отказа при невыработанном ресурсе резервных блоков пожалуй меньше, чем вероятность отказа контроллера или даже всего остального железа.
А если средств достаточно, то опять же схема с hot standby дает преимущества — можно сделать slave на отдельном хосте с близкими к мастеру параметрам, и в случае падения мастера практически мгновенно восстановить работоспособность. Ну с той печальной оговоркой, что транзакции 1с не совпадают с транзакциями базы, и есть шанс (небольшой), что придется восстанавливать целостность базы средствами 1с.
так, а потупить можно? видимо я не догоняю, чем отличаются транзакции 1с от скулёвых?
1с: — слышь скуль, ну к пихни мне документик
sql: — окей, братуха, вот положительный ответ от инсерта
Либо Вы имеете ввиду, что базу лучше бэкапить только средствами 1с? Типа надёжнее?
Работая во франче, у меня были беды как раз с бэкапами средствами 1с, базам я доверяю больше :)
1 транзакция 1с может составить несколько транзакций в БД, увы. То есть в терминах БД база будет находиться в согласованном состоянии после крэша (откатились незаконченные транзакции), но для 1с это не обязательно будет согласованным состоянием. Но средствами 1с можно восстановить согласованность.
А бэкапить базу средствами 1с слишком дорогое удовольствие — надо всех из базы выгонять. (Ночью, само собой, надо бэкапить средствами 1с.)
Standby slave забирает WAL в асинхронном режиме, поэтому не нагружает мастер, но из-за этого возможно небольшое отставание, хотя и гарантируется согласованность базы, но не в терминах 1с.
Либо:
1с: проведи документ
sql: 1-ый update ok, 2-ой — нет?
лечить только исправлением в 1с базы
мы поняли друг друга?
Ребята, а правда что, RAID0 из 2-х SSD это зло?
У меня уже год как на таком сервере вся 1С крутится. Бэкапы разумеется на внешний диск.
который подключен к этому серверу? Завидую отваге любителей страйпа :)
Данные за небекапнутый день сами набивать будете?
UFO just landed and posted this here
В аппаратном RAID (в режиме именно RAID, а не HBA) ни у каких SSD Trim не работает — потому, что конкретно Trim там не нужен.
Там выполняются команда SCSI UNMAP, и это делает сам контроллер.
Ну разумеется, который подключен к этому серверу, а как же ещё :).
Изначально все с кем не советовался, умоляли не ставить RAID0 из SSD, причем никто из советовавших кроме аргумента про риски ничего конкретное сказать не мог. Решил разорвать шаблон и сделать по своему. И вы знаете, я доволен. Скорость просто космическая =)
Ах да разностный бэкап, сегодня же попробую настроить.
RAID0 для любых данных, которые надо хранить больше суток — зло.
Как и «диск в ОЗУ» (ramdisk и иже с ним).

Собственно, владельцы оных радуются производительности обычно ровно до первого серьезного падения.
поклёпа на RAM диск не надо, никто в здравом уме его не будет на бой пихать. Я его использовал только для тестов, чтобы понять, где бутылочное горлышко.
Я stripe`любовцев-то считаю людьми с ограниченным стратегическим мышлением :)
В том-то и печаль, что мало того, что пихают в продакшн, так еще и людям рекомендуют.
Как бы местами даже серьезные франчайзи.
Ну, перемещение темпов, сеансовых данных, кэша конфигураций на рамдиск дает хороший приход по производительности. В общем всё то, с чем идет работа, но сохранять не надо.
Это в сильно редких ситуациях, КМК, есть возможность использовать дорогой (за объем) и ограниченный ресурс ОЗУ гораздо более разумным образом.
Судя по результатам теста на 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?
Дык задача стояла не тестировать железо, а тестировать разные платформы на одном и том же железе, и не важно каком.
Тест некорректен. При выставленном правильном режиме производительности на MS SQL результат должен быть в районе 25-30 на этом процессоре. Это один переключатель, То что он стоит по дефолту это ошибка. И уже картина не такая радужная. Хотя может и в PostgreSQL и Linux есть такие же настройки, но знакомый линуксойд говорит, что только в винде додумались ставить этот признак по дефолту в режим экономии энергии.
Смотрите дальше тестов. Есть альтернативы, выбор за Вами:
1. win/lin
2. Дешевле/дороже
3. Сложнее/проще
4. Ваше любимое: быстрее/медленнее
Все нюансы не предусмотришь, когда у нас делали аналитику, можно было трактаты писать в сотню страниц и книги выпускать.
>При выставленном правильном режиме производительности на MS SQL результат должен быть в районе 25-30 на этом процессоре. Это один переключатель,
Будьте добры, аргументируйте пожалуйста вот это высказывание. Своими словами, если можно.
Зачем своими? Вот статья с сайта того же Гилева. http://www.gilev.ru/systemperfomance/
Я почему и предлагал своими словами.
FYI: по умолчанию, в штатной схеме энергосбережения в Windows Server 2012 R2 TurboBoost включен.
Вы исходите из целого ряда неверных предпосылок.
Во-первых, брали что было под руками свободное, скорее всего- производительность процессоров и их ядер как таковую в данном тесте ни с чем не сравнивали.
Сравнивали, если Вы не обратили внимание, варианты решения на разных программных платформах.
Во-вторых, E5-2637V4 будет производительнее, чем Е5-2670 отнюдь не в любых ситуациях, по вполне понятным причинам.
>Зачем из них RAID делать? Исходя из каких тестов и и результатов вы решили, что нужен RAID 10?
Вот по этим вопросам очень странно выглядит Ваш наезд. Если Вы не знаете, зачем в сервере базы данных RAID, почему именно RAID10 нужен под 1С — может быть, сначала сами для себя уточните этот вопрос?
Опять-таки, компания, представитель которой эту статью написал, не занимается массовой продажей тестовых стендов — а именно готовых решений.
Не на всех 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 раза медленнее.
>Не на всех SSD хорошо работает TRIM если использовать RAID
В аппаратных RAID нет TRIM, там есть SCSI-команда UNMAP, она и используется. Уже писал в этой теме.
>Из практики, на E5-2637 1С будет быстрее отрабатывать транзакции, значит будет меньше шансов на блокировку.
Зависит от многих факторов, и в первую очередь — от количества активных пользовательских сессий.
Всё же 8/16 (с двумя процессорами) логических ядер маловато бывает — при всей их замечательной производительности.
>Если у вас действительно не будет хватать ядер, есть еще 2643.
У него цена несколько… не щадящая.
Но да, он разумнее.
>Пользователи меня чуть не убили, потому что новый сервер работал тупо медленнее почти в 2 раза
Ну, не в два. а в полтора :) Но да, есть такое дело.
Кстати, не увидел (или проглядел) в статье, какая разрядность 1с использовалась. Разница в цене между 32 и 64 битными версиями помню приличная, но необходимости в х64 версии я пока не ощутил — процесс rphost редко добирается до 1Гб памяти, обычно 300-600 Мб. В тесте Гилева вообще потребление памяти небольшое.
Есть ли вообще смысл в дорогой 64 битной версии?
(Разумеется, про PostgreSQL такой вопрос не стоит, там однозначно 64.)
в редакции на 32 бита ограничение на процесс 2 гига, вроде. Но, как вы сами сказали, вам это не нужно.
Видимо и клиентов у вас мало, и база небольшая, и аналитики дикой нет (ну не сервер 1с же они оптимизировали :))
у меня на паре проектов и 16 гигов кушать изволило
16 G на один процесс rphost? Или общее потребление всеми rphost?
Всеми. Но вот в конфиг я давно не глядел, в 8.2 делали их равным количеству процов, а вот в 8.3 оно само как-то на основании количества коннектов, или пожираемой памяти. В старых платформах начинались тупняки после того, как рабочий процес занимал более 2Гб, сейчас этого не наблюдаю. Но то, что 1 rphost бывал в районе 8 Гб точно помню.
Кажется много можно запустить процессов rphost, издержки не велики. На 64х платформе и один rphost может утилизировать всю память, а на 32х запуск многих rphost вроде как позволяет масштабировать сервер.
1 ИБ — 1 процесс, так выгоднее типа, если верить документации.
В 8.3 у 32-ух битной редакции в парамах процесса поставить максимум 2Гб, оно и будет множится. Единственно, не обращал внимания, как оно это делает, рожает новый или child процесс.
И я никогда не сталкивался, что будет, если 32-ух битному рабочему процессу не хватит 2Гб памяти на какое-нить перепроведение :)
UFO just landed and posted this here
UFO just landed and posted this here
А на 32х версии такого бы не случилось ;-). Ну и винтажно бы смотрелась 32х битная версия на сервере с 256Гб ОЗУ.
Sign up to leave a comment.