Как выбрать сервер для 1С, SQL и терминалов

Как выбрать сервер для 1С, SQL и терминалов
Блог компании Сервер Молл

Наверное, каждому сисадмину хоть раз в жизни приходилось решать задачи внедрения продуктов 1С, развёртывания SQL-баз и создания терминальных серверов. К нам регулярно обращаются заказчики с просьбой подобрать сервер под какую-нибудь из этих задач, а то и под все сразу. Здесь есть три возможных подхода, и мы хотим поделиться своим опытом в подборе оборудования, возможно, кому-то он сильно облегчит жизнь.
Основным критерием при выборе серверов для организации является набор сервисов, которые будут использоваться, и количество пользователей.
Сегодня мы рассмотрим выбор серверного «железа» для небольшой организации на 25-30 пользователей, с распределенной инфраструктурой (торговые точки, склад), которой требуются терминальный сервер и программа «1С: Предприятие». Этими сервисами будут пользоваться все сотрудники.
Большинство малых компаний, для удешевления стоимости оборудования, предпочитают минимизировать количество приобретаемой техники и просят администраторов «впихнуть» все запрошенные ими сервисы в один физический сервер. Желание понятное и простительное, но тут «есть нюансы».
Можно организовать терминальный сервер и использовать там файловую версию 1С, но при таком количестве пользователей компания-разработчик рекомендует переходить на клиент-серверный вариант. Поэтому нам потребуется еще сервер под «1С: Предприятие» и сервер баз данных. Уточним сразу, что организовать терминальный сервер, сервер SQL и сервер 1С на одной операционной системе возможно, но, с точки зрения безопасности и стабильности работы сервисов, это крайне не рекомендуется. А если всё-таки очень хочется использовать один физический сервер для всех трёх ролей, то рекомендуем использовать виртуализацию, например, VMWare ESXi или Hyper-V.
Таким образом, вырисовывается три варианта:

Для решения этих задач можно предложить следующую конфигурацию серверов:
В случае с одним физическим сервером мы остановили выбор на Dell R710, с двумя шестиядерными процессорами Xeon X5650, 64 Гб оперативной памяти и шестью дисками: два SSD в RAID 1 и четыре SAS-диска в RAID 10.
В случае с двумя физическими серверами мы остановили выбор на таких конфигурациях:
Почему мы выбрали именно такие конфигурации? Для ответа на этот вопрос давайте подсчитаем, что нам нужно для обеспечения комфортной работы пользователей в нашей небольшой организации на 25-30 сотрудников. Чтобы не было недопонимания: это лишь один из примеров недорогого внедрения 1С, и во многих случаях целесообразнее выбрать другие конфигурации.
- Процессор

С точки зрения процессорного времени терминальные сессии занимают не очень большую долю. По опыту внедрения терминальных решений в различных организациях, для поддержания комфортной работы 30-ти пользователей достаточно будет 4-6 физических ядер процессора, по одному ядру на 6-8 сессий. Для небольшой базы SQL-серверу понадобится одно ядро. Но мы будем ориентироваться на расширение базы в будущем (или увеличение количества баз) и возьмем два ядра на SQL. Для сервера «1С: Предприятие» важно не столько количество ядер, сколько их тактовая частота и частота шины. Поэтому заложим еще два ядра на сервер 1С. И не забудем, что в случае использовании виртуализации одно или два ядра нам пригодится для обеспечения работы хостовой операционной системы.
Итого у нас получается:
- Оперативная память
  - Сначала посмотрим, сколько нужно оперативной памяти под сервисы:Операционная система Windows Server только под себя требует 2 Гб ОЗУ.
  - Для SQL и небольшой базы 1С достаточно будет 4-6 Гб ОЗУ.
  - Сервер «1С: Предприятие» требует еще 2-3 Гб ОЗУ.
  - Рассчитываем, что каждому пользователю потребуется 700 Мб ОЗУ в терминальной сессии, тогда на 30 пользователей потребуется 21 Гб.
  - Теперь применим это к нашим вариантам.Для одного сервера с двумя виртуальными машинами нужно около 40 Гб ОЗУ.
  - Для терминального сервера достаточно будет 24 Гб или 32 Гб ОЗУ (возьмем с запасом, предполагая будущее расширение). Для сервера с базами данных нужно не менее 8 Гб, но это «впритык», поэтому 16 Гб с запасом. Память сейчас — один из самых дешевых компонентов сервера.
- Дисковая подсистема

Это традиционное бутылочное горлышко многих систем. Правильный выбор жестких дисков очень важен для обеспечения быстродействия серверов. При работе 1С с базой SQL происходит множество операций чтения/записи в секунду (IOPS). Если пользователи работают на терминальном сервере с тонких клиентов (т.е. полноценно используют терминальный сервер как рабочую среду), это сильно нагружает дисковую систему сервера. Например, 30 пользователей терминального сервера на RAID 1, SATA 3 Гбит/с, с дисками WD Velociraptor чувствуют себя некомфортно при работе с почтой и активном сёрфинге в интернете. Для терминальных серверов мы рекомендуем использовать SSD-накопители. Для серверов баз данных — SAS-диски, собранные в отказоустойчивые массивы. Помимо накопителей, следует уделить внимание и дисковому контроллеру. Современные серверы имеют на борту довольно хорошие контроллеры, например, HP SmartArray и DELL PERC. Однако некорректно будет использовать «набортные» решения при серьёзной нагрузке, когда требуется максимальная производительность. Немного сэкономив, вы легко можете получить мощный сервер, который совершенно не тянет нагрузку. Поэтому контроллер должен быть аппаратным, а не программным, со своей энергонезависимой памятью.
Рассмотрим варианты решения этой задачи.
- Один или несколько серверов

Как сказано выше, у небольших организаций довольно велико желание разместить все сервисы на одном сервере. К преимуществам использования одного сервера и виртуализации можно считать более низкое энергопотребление и более гибкое распределение ресурсов между виртуальными машинами. Ну и перенос виртуальных машин, в случае чего, гораздо удобнее, чем перенос физических ОС. Однако два сервера имеют более широкие возможности по апгрейду. Например, в нашем варианте недорогой IBM x3550 M3 с добавлением еще одного процессора и ОЗУ превращается в ~~элегантные шорты~~ терминальный сервер на 50 и даже более пользователей. Еще одно «узкое место» в нашем случае, которое необходимо учитывать при выборе двух физических серверов, это обмен данными между ними по сети. У виртуальных серверов обмен данными идёт через виртуальный коммутатор. Здесь же, для увеличения пропускной способности сети, можно установить в каждый сервер по сетевой карте с двумя гигабитными интерфейсами, которые можно агрегировать между собой и напрямую соединить оба сервера агрегированными 2-х гигабитными линками. Или же использовать сетевые карты с SPF+ 10GBASE, но это дорогое удовольствие.
- Запас по мощности
При расчетах и выборе сервера необходимо принимать во внимание пиковые нагрузки. Также обязательно нужно помнить, что база данных будет только «пухнуть», объёмы данных на терминальном сервере будут расти, а количество пользователей может увеличиться. Многие предприятия экономят на запасе мощности и через полгода-год сталкиваются с перебоями в работе и жалобами пользователей. Это тот случай, когда чрезмерная экономия приводит к новым затратам в будущем — скупой платит дважды. Выбранные нами варианты рассчитаны с запасом мощности и возможностью апгрейда. Учтено, что в DELL R710 можно будет добавить еще два жестких диска и ОЗУ, а также заменить процессоры на более производительные.
Так что, если вам потребуется расширение, или количество сервисов увеличится, то тут есть большие перспективы, а существующие серверы еще долгое время будут эффективно выполнять свои задачи. Возможно, через год нам неожиданно потребуется увеличить количество пользователей в два раза, до 60 человек? Пожалуйста.
Если вы использовали один сервер DELL R710, то можно докупить недорогой IBM x3550 M3, поднять на нём гипервизор, перенести туда виртуальную машину с БД и 1С-сервером, а на DELL-е все ресурсы отдать виртуальной машине с терминалом. Это будет быстро, и не потребуется «всё выкинуть и купить новое».
Если же вы использовали два сервера IBM, то x3550 M3 с добавлением второго процессора и небольшого количества ОЗУ превращается из середнячка в довольно мощную машину. А в x3250 M5 можно обновить процессор с E3-1220v3 до E3-1285v3.
- Заключение
Конечно, предложенные конфигурации — далеко не единственные варианты оборудования, например, для внедрения того же 1С. Тут очень многое зависит от текущей инфраструктуры, уровня нагрузки и её увеличения в будущем, а также бюджета. Поэтому всегда можно подобрать либо похожие модели серверов, либо более мощные и дорогие.
- терминальный сервер

23k
- Автор: @ArthurLeighAllen
- Похожие публикации
- Комментарии (50)
- А бэкапы? Или предполагается, что уже есть, куда их делать?
- Чем плох вариант с сервером на Xeon 2600 серии для двух виртуалок?
- В идеале, отдельные диски надо под систему и отдельно диски под профили терминальных пользователей, базы 1С и прочее добро. С нормальной политикой хранения документов где-нибудь на файловом сервере. Даже в относительно дешёвых вариантах такое доступно (при условии, что файловый сервер уже есть). А если файлового сервера нет — нет и бэкапов?
- А ещё, хотелось бы узнать у тех, кто это использует: RAID 1 на SSD стоит этого? Диски не умирают одновременно?
  - ArthurLeighAllen 19 июля 2016 в 10:57
- Конечно вариантов реализации сервиса 1С очень много. Мы рекомендуем делать бэкапы на отдельную железку, для удобства.
- Вариант на Xeon 2600 не плох, но он значительно дороже, а для данной задачи достаточно и Xeon 5600 серии.
- Про SSD диски наблюдали практику в дата центрах, когда диски ставили в Raid 1 из разных партий, но возможно это излишние предосторожности.
- В практике не встречали чтобы SSD умирали одновременно.
  - LoadRunner 19 июля 2016 в 11:05
- А в случае выхода из строя отдельных компонентов — не будет потом проблем с поиском замены при использовании устаревающего железа?
- Xeon 5600 уже лет 5 не производят же.
  - ArthurLeighAllen 19 июля 2016 в 11:08
    - Данное железо очень ходовое и проблем с ним не будет еще лет 10.
- xexex 19 июля 2016 в 10:57
- В основном используем Raid10, ещё не разу не умирали одновременно диски. Хотя стараемся ставить разных производителей (в основном samsung и intel) или разные модели одного производителя.
  - dronmaxman 20 июля 2016 в 13:58
  - Диск в таких масивах (Raid 5,10) чаще всего умирают при ребилде. Проверено практикой.
- speaktr 19 июля 2016 в 15:15
- Рассматривается выбор сервера. Для бэкапов можно использовать недорогой NAS, в данном частном случае. На небольшую компанию хватит Synology DS213j с двумя дисками WD RE или RED.
- mgis 19 июля 2016 в 16:24
- Год назад сделал RAID0 из 2-х SSD, сервер нормально крутится до сих пор. Насчет RAID1 из SSD ничего сказать не могу.
  - yosemity 19 июля 2016 в 16:51
    - А вы замеряли скорость по сравнению с одним ССД? Какие диски и контроллер используете?
- hamnsk 19 июля 2016 в 10:51
- Эм считаю что терминальный сервер это лишняя трата денег, если в качестве конечного сервиса это только 1С предприятие, гораздо дешевле и разумней поступить иначе:
- 1. Все на одном сервере, для доступа клиентов используем Apache под Windows
- 2. Два сервера, 1с ОС Linux для доступа клиентов к бд, второй это наш SQL + 1C Предприятие.
- Конкретизировать конфигурации я не буду, для доступа 50 человек в базу нам хватит сервера с 2 ГБ ОЗУ, самым медленным диском и тд, для этих целей можно вообще арендовать сервер в облаке за 500 рублей в среднем в месяц. При этом для масштабирования системы в будущем, фронтэдом вешаем Nginx настраивая его как балансировщик по 443 порту, а бакэндом апач на этом же сервере, в случае роста компании добавляем еще один сервер с апачем и строчку в конфигурацию Nginx.
- Если же все вешаем на 1 сервер то там просто виндовый апач, с опубликованной БД. И вот именно для БД я бы позаботился не только процессором а именно SSD причем желательно разнести данные логи и tempdb на разные диски.
- И не тратил бы деньги на сервер терминалов и терминальные лицензии и по 700 метров ОЗУ на каждого пользователя, мне кажется это в современных реалиях просто расточительство ресурсов и не достаточная глубина знаний предмета.
  - dmitry_ch 19 июля 2016 в 11:08
- Это при условии, что ваша конфигурация через веб работает как надо. Что, вообще говоря, не всегда правда (банально, сканер ШК подключить не получится, как и запустить конфигурацию, которая с «вебом» не другит).
  - hamnsk 19 июля 2016 в 13:10
- Современные конфигурации типовые уже поддерживают все из коробки. Ведь у нас идет речь о внедрении продукта, а не переноса существующей инфраструктуры.
  - dmitry_ch 19 июля 2016 в 13:12
- «Современные типовые конфигурации» — да, может и так (но надо тестировать), но только если вы под словом «внедрение» подразумеваете просто установить и отдать людям. Если в планах модификации — надо уже внимательно все планировать, чтобы веб работал.
- EgorLyutov 20 июля 2016 в 07:22
- speaktr 19 июля 2016 в 15:21 (комментарий был изменён)
  - Это возможно, как вариант. Однако надо понимать, что описывается задача создания именно терминального сервера. Когда у пользователей тонкие клиенты, а не случаи если публикуется база в WEB или настраивается RemoteApp. Например мы часто сталкивались с требованием клиентов — вынести всю работу в датацентр, чтобы в офисе был шлюз, и тонкие клиенты. Или есть клиенты, которые хотят контролировать все действия пользователей, чтобы они на локальных машинах ничего делать не могли. Таких задач много и в одной статье их не охватить. Были и гибридные варианты, когда офис работает в RemoteApp а филиалы с тонких клиентов.
- ArthurLeighAllen 19 июля 2016 в 11:06 (комментарий был изменён)
- Абсолютно верно, в том случае, если конечный сервис только 1С.
- Еще очень важный момент в нормальной работе 1С — это частота процессора на сервере 1С.
  - LoadRunner 19 июля 2016 в 11:11
- А с количеством ядер не промахнулись? Насколько я знаю, при выполнении ресурсоёмких операций, клиент 1С будет всё ядро вешать.
- Да и другие приложения при различных сбоях могут поступать аналогично.
  - ArthurLeighAllen 19 июля 2016 в 11:15
  - По практике для данной задачи достаточно с запасом. И конечно, есть различные «но»
- AMaxKaluga 19 июля 2016 в 12:37
- >Абсолютно верно, в том случае, если конечный сервис только 1С.
- Это то с чего и надо было начинать статью. Т.е. терминальный сервер вам нужен НЕ ДЛЯ 1С.
- * Для именно 1С теминальный сервер бесполезен (в случае использования тонкого клиента конечно), только лишние траты на лицензии MS
- * В случае экономии и размещения сервера 1С и MSSQL на одной машине появляется очень приятный бонус в виде подключения через SharedMemory с заметным ускорением.
- * Для 1С критична к частоте процессора (это действительно важно), т.к. не параллелит один процесс. Но многоядерность нужна в случае значительного числа активных пользователей. Так что для небольших групп очень выгодно выглядит серия Е3.
- * А вот MSSQL гораздо чаще может параллелить один запрос на несколько процессоров. Как итог не забываем про существование cpu affinity.
- * Не стоит забывать что в случае сложных отчётов на СКД идёт обработка локально во временных файлах на стороне сервера 1С. Поэтому желательно выносить данные кластера 1С на отдельный дисковый том (по умолчанию он на системном разделе).
- * Про оптимизацию самого mssql отдельные трактаты и очень важно их не игнорировать.
- *!*! Самое главное в производительности 1С — это сам код конфигураций. Никакие танцы вокруг потимизации «железа» не заменят голову программисту, который ВНЕЗАПНО решит выбрать по сотне тысяч записей из десятка таблиц потом их объединить (в экстремальных случаях без джойна даже) и только после этого наложить фильтры.
- PS: Советовать смотреть на серию 56** как-то очень странно в 2016 году
  - ArthurLeighAllen 19 июля 2016 в 12:47
    - Спасибо, за комментарий и важные уточнения.
    - Конечно, можно использовать более новое оборудование. А в некоторых компаниях это обязательное требование.
    - Сейчас достаточно много сторонников refurbished решений. И данное оборудование вполне справится с задачами.

xtelekom 19 июля 2016 в 13:36
Делал подобный проект на двух серверах dell r420 для отказоустойчивости, это было основное требование. Дополнительно там же работала IP АТС на базе elastix. Итого на 2х серверах 2*2640v2/32Гб/2*ssd 240Гб: домен, терминальный сервер, сервер 1С с базой mssql, ip атс. В случае отказа любого сервера работа останавливается максимум на минуту. Бекап на внешнее сетевое хранилище.
- LoadRunner 19 июля 2016 в 15:02
А Вам не страшно виртуалить DC и размещать на той же хостовой машине?
- xtelekom 19 июля 2016 в 15:35
Какие вы видите риски?
- LoadRunner 19 июля 2016 в 16:03
Невозможность решить проблему удалённо, если что не так с машиной DC. Да и по производительности — виртуализация медленнее.
Да и принцип «не класть все яйца в одну корзину» — увеличивать количество точек отказа, чтобы не накрылось сразу всё (хотя репликация на уровне виртуальных машин спасает, да).
- xtelekom 19 июля 2016 в 16:22
удаленное управление сервером есть, можно под локальной учеткой зайти если что. И серверов 2, контроллеров тоже 2 (не 1 на 2 виртуалках)
- LoadRunner 19 июля 2016 в 16:30
А с точки зрения безопасности это не кажется плохим решением — удалённый доступ к серверу под локальной учётной записью?
P. S. Если что, я не оспариваю решение, а просто любопытствую.
- xtelekom 20 июля 2016 в 08:26
navion 19 июля 2016 в 15:42
А что такого в КД на виртуалке? Виндовый кластер научился работать при их недоступности в 2012.
- yosemity 19 июля 2016 в 16:58
Нежелание КД в виртуалке — пережиток прошлого. Ну а если забыл отключить синхронизацию времени гостя с хостом через VM-tools, то ССЗО.
- navion 19 июля 2016 в 17:06
Там ещё пачка продвинутых настроек, но с 2012 жить стало намного проще.
- yosemity 19 июля 2016 в 17:13 (комментарий был изменён)
Я живу с vSphere и в ус не дую :)
- navion 19 июля 2016 в 17:38
Как раз в vSphere настроек синхронизации больше одной и без их отключения при определённом везении можно развалить аутентификацию в домене.
- yosemity 19 июля 2016 в 17:47
  - Да я собственно не к выбору гипервизора, а вообще о том, что смысла выделять под КД отдельную железку нет и опасения по поводу заморочек со временем идут от неверной настройки.
LoadRunner 20 июля 2016 в 08:49
А не поделитесь информацией об этих настройках?
- navion 20 июля 2016 в 14:13
Выше ссылка и где-то на Хабре был пост про это.
Ещё можно почитать талмуд про синхронизацию и бест практисы для гостевых ОС:
Timekeeping in VMware Virtual Machines
Timekeeping best practices for Windows, including NTP
Timekeeping best practices for Linux guests
navion 21 июля 2016 в 13:25
Ещё в Windows Server 2012 появился VM-Generation-ID (нужна поддержка со стороны гипервизора), который меняется при восстановлении из снепшота и КД сваливается в DSRM чтобы избежать потери данных.
- LoadRunner 21 июля 2016 в 13:51
Я так и не понял, это довод «за» КД на виртуалке или «против»?
Или это просто предупреждение — не использовать снэпшоты для КД?
- navion 21 июля 2016 в 14:03
Наверное «за», так как стало чуть сложнее выстрелись себе в ногу.
- LoadRunner 21 июля 2016 в 14:16
guglez 19 июля 2016 в 18:57
Сначала автор пишет, что хочет по-дешевле все сделать, но потом пошло про MSSQL и винду? Тут постгрес и линукс, а не мсскл и винда…
- Melex 19 июля 2016 в 19:32
Та ну блин, и не надоело вечно про это вспоминать?
Лицензия скуля+винды будет значительно дешевле, чем нанять адекватного спеца, который шарит в линуксе и постгри.
1с под виндой — работает быстрее чем под линуксом, и на скуле — из коробки, тоже работает быстрее.
Те уровни изменений, которые требуется сделать в постгри, что бы он начал работать на уровне с sql — очень высоки. Т.е. необходим спец, не дешевый, и вы постгри никогда не настроите за 10 минут, та даже за 1 день. Так как с ним необходимо воевать постоянно, вы должны его подстраивать под реальные процессы компании (количество документов, масштабы отчетов и проче-прочее-прочее).
Т.е. минимум на пол года. Это раз.
Два — спецам необходимого уровня — ваще не в кайф сидеть и ковырять 1С, получая гневные отзывы от бабушек из бухгатерии, за то, что медленно что-то работает и вообще — почини и заправь ей принтер.
Отсюда вывод — мс скуль + винда, это единственное что имеет смысл ставить компанием со штатом до 100 человек.
А вот если у вас 200 человек, несколько баз и т.д., вот тогда да, тогда другая песня.
И если вы сейчас скажите, что вы постгри настроили за 10 минут и все летает, я, и не только я — просто не поверю.
- VVizard 21 июля 2016 в 10:46
На самом деле все проще.
Для небольших баз в общем то нет особой разницы Postgres или SQL.
Для больших и нагруженных все равно нужно уметь настраивать и Postgres и SQL и специалисты нужны с соответствующими уровнями.
Установка Postgres (https://postgrespro.ru/products/1c_build) в общем то простая не сложней SQL (само собой для Linux администратора).
Насчет спецов, если это решение для бизнеса то в и для Win и для Nix нужны толковые админы, то что в Win порог входа ниже я бы записал в недостатки.
В том виде в котором описано в статье использовать Win платформу есть смысл только если админить всю эту систему будет тот же самый человек который будет сопровождать и дорабатывать 1С (для небольших компаний и/или филиалов это нормально).
Большинство 1С ников (включая и меня) «win only» так как 1С долгие годы была так же «win only» и только последнее время развернулась в сторону *NIX, в итоге специалистов по 1С умеющих работать с чем то кроме MSSQL+WIN довольно мало.
*по поводу того что спецам «ваще не в кайф сидеть и ковырять 1С», на мой взгляд это очень спорное утверждение. Если 1С это сердце бизнеса (а так часто бывает) то что там «в кайф спецам» владельцев бизнеса мало волнует. По мне так направление Linux + 1C очень перспективное.
- Melex 21 июля 2016 в 17:19
- Никто не говорит, что у SQL громадное приимущество, хотя у него таки есть ряд приимуществ, который в большей мере накоплен благодаря тому, что 1С таки долго только на нем и была.
- Я в своей практике не встречал чистых юникс андминов, у которых история не запятнана виндой, т.е. обычно человек вначале становится хоть каким то спецом в винде, и потом осознано переходит на никсы.
- Т.е. намного проще и быстрее найти спецов именно на винде.
- Отсюда следуюет комментарий для этой фразы:

*по поводу того что спецам «ваще не в кайф сидеть и ковырять 1С», на мой взгляд это очень спорное утверждение. Если 1С это сердце бизнеса (а так часто бывает) то что там «в кайф спецам» владельцев бизнеса мало волнует.

Все верно, только когда админа никсов задалбывает чинить принтеры и прочее, он сваливает, и вот тут уже может дойти до того, что бизнес просто встанет, так как другого никс андмина — найти уже достаточно сложно, и уж точно не быстро.
Та и франчи тут не помошники, так как чаще всего от них такие сразу и сбегают.
Буквально недавно звонили и просили помочь поднять бекап с постгри, так как админ уволился, пол года никто не следил за сервером, ибо тупо даже не знали как зайти туда и что смотреть. И все. Бизнес встал. Тут можно долго спорить, что сами олени и не нашли, но признаются честно — искали, но когда слышали цены никс админов — решили послать все нафиг и купить винду и скуль, так как за 3 года оно просто окупается. Ибо вин админом может быть тот же 1Сник, за те же деньги, по сути.

Areso 21 июля 2016 в 13:29
Скажем так, все в мире относительно.
К примеру, наша база (~17 ГБ, 25 пользователей) в MS SQL работает довольно сносно на машине E5620x2, 16 GB RAM (будет 24 осенью). Сервер 1С: Предприятия на этой же машине. Второй процессор для наших нужд никуда не упирается, а вот SAS HDD хотим поменять на SSD.
Ради интереса мы поднимали нашу базу на машине с Потстгрю, первоначальная настройка делалась одним автоматическим скриптом, работало медленнее скульного и даже немного медленнее файл-серверного варианта, но если хочется сэкономить на лицензии, то потерпеть можно.
А вообще 1С просто медленная. Нет, она нереально медленная. И тут уже ничем не помочь. То, что делают другие ЯПы в разы быстрее, а компилируемые вообще за секунды, 1С-ка делает секундами и даже минутами.
Хотя сделать еще хуже — запросто: слабое железо, кривые запросы/отчеты (как правило доработки), неадекватная настройка MS SQL/другой СУБД.
yosemity 21 июля 2016 в 13:31
Вы во многом правы, но да, постгря настраивается за 10 минут, если знаешь. Для начала просто берем pgtune + правка некоторых настроек, конечно нужно знать каких. По собственной инструкции сервер на дебиане 8 х64 + 1с х32 + ПГ 64 9.4.8 от ПостгресПро я подниму за полчаса с нуля, включая установку ОС. При чем уже с настройками. Не уверен нужна ли такая небольшая инструкция на хабре.
- navion 21 июля 2016 в 13:39
Мне будет полезна, а при правильно подаче не скатится в минуса.
Areso 21 июля 2016 в 13:44
LESHIY_ODESSA 19 июля 2016 в 20:57
\\ «для небольшой организации на 25-30 пользователей»
Только мне кажется что предлагаемое железо выходит за рамки небольшой организации.
\\ это лишь один из примеров недорогого внедрения 1С
Недорогого? Видимо я совсем отстал от жизни.
- Areso 21 июля 2016 в 13:38
- На самом деле, ценник железа и лицензий просто меркнет по сравнению с отраслевым решением+доработкой (тем самым «внедрением») — такому бизнесу пытаются продать внедрение вместо коробки — под потребности бизнеса. Из-за курса сейчас это не так сильно бросается в глаза, но раньше это было именно так. Это выливается в проекты, которые тянутся от нескольких месяцев до нескольких лет, а суммы поражают шестью нулями. Причем, вместо 1С: Предприятия с доработками можно вписать MS Dynamics AX (ERP), Sharepoint, SAP или любого другого монстра, внедренцы которого, если не разорят, то изрядно облегчат кошельки предприятия-заказчика.
kondrash055 21 июля 2016 в 10:46

Планирую делать ферму виртуалок. Пользовательские виртуалки будут на linux и windows для использования 1с, офисного пакета и браузера.
Писать статью?

Page updated

Google Sites

Report abuse