Light-electric.com

IT Журнал
1 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Ssd 1c sql

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

  • Главная
  • Ускоряем 1С:Предприятие 8 при помощи SSD

Ускоряем 1С:Предприятие 8 при помощи SSD

  • Автор: Уваров А.С.
  • 28.11.2013

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

Один из наших клиентов, небольшая фирма по бухгалтерскому обслуживанию, начал жаловаться на медленную работу 1С:Предприятие. Собственно и так не очень быстрая работа приложения стала совсем тоскливой после перехода с Бухгалтерии 2.0 на Бухгалтерию 3.0.

В наличие имелся простой терминальный сервер на Core i3 2120, 8 Гб RAM, с дисковым массивом RAID 1 из двух Western Digital RE4, который обслуживал от трех до шести пользователей, каждый из которых работал с двумя — тремя базами одновременно.

Анализ производительности сразу выявил узкое место — дисковая подсистема (скриншот сделан уже после установки SSD, поэтому к RAID массиву относятся логические диски C: и E:).

Несложные расчеты показали, что запуск даже одной информационной базы практически полностью использует производительность массива, около 150 IOPS при текущем соотношении чтение/запись — фактический предел для зеркала из двух не самых быстрых дисков. На что косвенно указывает и размер очереди.

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

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

Стало ясно — требуется модернизация дисковой подсистемы. Даже по предварительным прикидкам, создание производительного массива на основе массовых HDD упиралось как в доступный бюджет, так и в физические возможности железа, которое просто не имело необходимого количества SATA-портов и дисковых корзин в корпусе. Поэтому было принято решение о приобретении SSD.

Так как высоких дисковых нагрузок не предусматривалось, то выбор производился в первую очередь из соображений цены. Скоростные характеристики также отходили на второй план, так как узким местом становился интерфейс SATA-II. В итоге был приобретен 128Gb Corsair Neutron [CSSD-N128GB3-BK] LAMD, который будучи установленным в сервер показал следующие скоростные характеристики:

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

Следующий вопрос, который нужно решить: это создать ли «зеркало» из SSD и пожертвовать TRIM ради отказоустойчивости или оставить одиночный диск, выбрав скорость вместо отказоустойчивости. Следует отметить, что современные SSD кроме команды TRIM используют собственные технологии борьбы с деградацией, такие как сбор мусора, что позволяет довольно эффективно работать даже на системах без TRIM. Используемый в данной серии SSD контроллер LAMD (Link_A_Media Devices) как раз таки отличается весьма эффективными технологиями сбора мусора, на уровне накопителей корпоративного уровня, что в общем неудивительно, так как его разработчики давно работают в enterprise-сегменте.

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

Количество операций ввода-вывода существенно выросло, как и скорость обмена с диском, при этом длина очереди не превышает единицы. Это очень неплохие показатели, осталось проверить насколько наши действия ускорили работу непосредственно с 1С:Предприятие.

Для этого мы провели небольшое экспресс-тестирование в ходе которого измеряли время загрузки информационной базы и время группового перепроведения комплекта документов за определенный период времени. В ходе тестирования применялась конфигурация 1С:Бухгалтерия 3.0.27.7 на платформе 8.3.3.721.

Также в ходе анализа производительности мы обратили внимание на тот факт, что в своей работе 1С:Предприятие активно использует временные папки, которые в нашем случае были расположены на жестком диске. Поэтому в целях достижения максимальной производительности их стоит также перенести на SSD, однако для любителей экономить ресурс твердотельных дисков мы включили в тест оба варианта: когда базы расположенны на SSD, а временная папка на HDD и когда для работы приложения полностью используется SSD.

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

Перенос на SSD временных папок позволяет сократить время загрузки более чем втрое и приблизительно в два раза ускорить проведение документов. Здесь есть над чем подумать даже убежденным приверженцам экономии ресурсов диска. Наше мнение по данному вопросу следующее, если вы купили SSD — то следует использовать его по полной программе.

Сделаем небольшое отступление. Используемый нами диск Corsair Neutron [CSSD-N128GB3-BK] имеет ресурс 2-3K циклов стирания/записи. Несложные расчеты показывают, что если ежедневно полностью перезаписывать всю емкость диска, то для исчерпания ресурса потребуется 5-8 лет. Кроме того статистика показвает, что основная причина выхода из строя SSD в течении гарантийного срока не связана с исчерпанием ресурса, а представляет собой производственный брак или ошибки в прошивке.

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

Вики IT-KB

Пошаговые руководства, шпаргалки, полезные ссылки.

Инструменты пользователя

Инструменты сайта

Боковая панель

Файлы системной базы данных tempdb

Системная база данных tempdb активно используется базами данных 1С:Предприятие 8.3 для хранения временных таблиц, промежуточных расчетов, версий строк при использовании режима версионирования и прочих временных данных. То есть для задач 1С:Предприятие интенсивность обращений к базе tempdb находится на высоком уровне, поэтому нужно подумать о размещении этой базы на выделенном быстром дисковом устройстве.Подходящими кандидатами на роль диска под tempdb будут выделенные быстрые дисковые RAID-группы уровня RAID1, выделенные накопители SSD или вообще RAM-диск.

В большинстве сценариев рекомендуется разбивать базу tempdb на несколько файлов данных с одинаковом начальным размером (Initial size) от 1GB и больше и увеличенным показателем прироста, например, в 512MB.

При определении количества файлов можно руководствоваться принципом: количество процессорных ядер = количество файлов данных tempdb, но при этом стоит помнить о том, что использование более 8 файлов (даже при количестве ядер более 8) далеко не всегда может иметь положительный эффект. Возможно по этой причине в инсталляторе SQL Server 2016 даже при большом количестве процессорных ядер по умолчанию предлагается 8 файлов tempdb.

Относительно 1С:Предприятие 8.3 можно встретить рекомендацию о том, что общий размер Initial size для всех файлов БД tempdb должен быть от 25% до 40% от размера рабочей БД 1С:Предприятие.

Читать еще:  Переезд на ssd

Саму процедуру переноса файлов tempdb на другой диск мы рассматривали ранее в заметке SQL Server 2008 — Перенос файлов БД tempdb на отдельный диск. Эта процедура может использоваться и на новых версиях СУБД, вплоть до SQL Server 2016.

Рассмотрим частный пример распределения файлов tempdb по разным дисковым томам, имеющим разные показатели производительности. В нашем примере имеется два тома NTFS:

Часть файлов данных в файловой группе tempdb, а также файл лога размещены на быстром диске. Файлы данных, расположенные на быстром диске установлены фиксированного размера без возможности авторасширения (исключением здесь является только файл лога). Другая часть файлов данных размещена на менее производительном дисковом томе, но при этом для файлов включено авторасширение.

В результате такой конфигурации, файлы tempdb в нашем случае будут распределены по дисковым томам следующим образом: 4 файла данных и лог tempdb окажутся на быстром томе T:

Другие 4 файла данных tempdb окажутся на менее производительном дисковом томе R:

В случае если в ходе работы экземпляра SQL Server потребуется дополнительное расширение ёмкости tempdb, то файлы начнут прирастать на меньшем по производительности, но большем по объёму дисковом томе R.

К операциям, которые могут вызвать бурный рост tempdb при работе БД 1С:Предприятие 8.3 можно отнести, например, регламентные процедуры с конфигурацией 1С, выполняемые из конфигуратора (обновление конфигурации, перерасчёт итогов и т.п.). Кроме того, активный рост tempdb может вызвать построение в 1С каких-то тяжёлых отчётов с большим количеством данных и за длительные периоды при условии, что код отчётов неоптимален или вообще содержит ошибки. В практической среде при размере БД около 170GB во время построения подобного отчёта мы наблюдали рост tempdb до 350GB. Учитывая эти моменты стоит подумать о полной изоляции файлов tempdb на выделенных дисковых томах, чтобы их возможный бурный рост не смог нарушить функционирования других БД SQL Server.

Используемый в нашем примере дисковый том T: представляет собой RAM-диск, подключенный к серверу SQL Server по методике, описанной в отдельной статье нашего Блога : Организуем RAM-диск для кластера Windows Server с помощью Linux-IO FC Target

Diesel Forum

1С и SSD. Не могу опредилиться под что лучше ис.

  • Нравится
  • Не нравится

svn 22-06-2013

В принципе 1 С ни когда не занимался… Тонкостей не знаю.
Стоит сервер терминалом. На диске C –установлена система и 1С-ка, на диски D базы 1С, на F бекапы. Приобретён SSD (128 Гб). Сегодня попробовал перенести туда систему (удачно). Но вот думаю правильно ли я поступил, может есть смысл. SSD использовать под базы. (подключить как D) А ОС…пусть работает на обычном винте…. На один винт слить все не получается…если перенашу базы на диск С – вываливается ошибка. Что продуктивней?…..Использовать SSD для программы или же под базы? (Чую где то, что под базы), но хочется услышать мнения профи… Купил бы второй SSD — но пока бюджет не позволяет.

Сообщение отредактировал svn: 26 Июнь 2013 — 09:37

  • Нравится
  • Не нравится

Web-Kg 22-06-2013

1. Поправка: не SDD, а SSD (т.е. не Solid Disk Drive, а Solid State Drive)
2. Я бы сделал так-же, как вы. Для баз вполне хватит и обычного винта, а на SSD система сама пошустрее будет. И программа. К тому-же SSD менее надежны и базы на них ставить не хорошо (хотя, есть бэкап). Ну в общем, думаю, что вы поступили правильно. А когда деньги будут — можно купить и второй SSD, поставить под базы. Но при условии, что на F останется HDD с бэкапами (как я уже говорил выше — SSD на такие надежные, как HDD)

p.s.s. я, к примеру, сам не увидел прям очень существенной разницы между SSD и хардом 7200 rpm 64 mb. Копируются файлы, конечно, быстрее. Но если так посмотреть — ничего особенного. ИМХО

Сообщение отредактировал Web-Kg: 22 Июнь 2013 — 23:58

  • Нравится
  • Не нравится

linainvers 23-06-2013

Web-Kg
Для БД как раз таки лучше, работать в SSD или оперативной памяти, для быстрого чтения-записи, но я честно говоря не знаю, обычные SSD наверно все таки не стоит под все это дело ставить, для этого есть серверные.

Сообщение отредактировал linainvers: 23 Июнь 2013 — 22:12

  • Нравится
  • Не нравится

Mirrad 23-06-2013

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

на ссд ставят ОС, настраивают, ставят проги и тд и используют что бы все это быстро загружалось учитывая при этом что диск больше времени проводит в режиме ЧТЕНИЯ. а ЗАПИС до минимума.

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

Так что на ССД поставь ОС, насатрой, отключи виртуалку, кеширование и все. Хотя вообще зачем сервер терминалу ССД. он же один раз загрузится и все, будет круглые сутки пахать.

  • Нравится
  • Не нравится

aXmeD_2 24-06-2013

svn
Можно под ОС и софт. Под базу тоже можно. Главное делать бекапы базы!
Если пользователей 1С много, то можно поставить SQL сервер и в нем хранить базы, которые будут лежать на SSD. Там же есть функции авто бекапа, настраиваем бекапирование на HDD (желательно RAID) и все. Ежели народу меньше 10, то смысла в SQL сервере нет.

  • Нравится
  • Не нравится

root_222 25-06-2013

Ну и хай ССД стоит под 1С, главное бекапы делать на обычный хард и еще в облачное хранилище желательно. Смотря насколько все важно. По уму всегда настроить можно.

  • Нравится
  • Не нравится

p1gmale0n 25-06-2013

Хуже админа, который намеренно вредит, есть только админы, которые вредят из лучших соображений.

подключайте мониторинги и смотрите iow процессора. если оверхеда нет, то и делать ничего не надо.

в случае перехода на SSD
проблемы с малым (а на самом деле не таким уж и малым) временем работы SSD-диска решаются его заменой заранее, дабы перестраховаться.
проблемы же порядка «внезапно умер» есть у всех носителей.

  • Нравится
  • Не нравится

p1gmale0n 25-06-2013

СИС

Ну и как результат? 1С стала работать быстрее или нет?

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

  • Нравится
  • Не нравится

svn 26-06-2013

Перенос системы на SSD, дал результат — но не тот чего ожидалось. Временами 1С (когда делают какието проводки) просто тупит (Всего в сети 20 пользователей. Работает все хорошо. но временами случается вот такая ерундень.), буквально вчера, вернул все как было окрамя того что базу скинул на SSD. Сетка работает хорошо. От сервера до коммутатора гигабит. далее по сотни на машину. Вот сегодня тестовый режим, посмотрим поможет ли SSD.

Сообщение отредактировал svn: 26 Июнь 2013 — 09:32

  • Нравится
  • Не нравится

rus1an 29-06-2013

svn

Временами 1С (когда делают какието проводки) просто тупит (Всего в сети 20 пользователей

Сколько оперативной памяти на терминальном сервере? Какого размера база? Все пользователи работают исключительно через терминал?

имхо, держать файловую базу на ССД не самый лучший вариант, особенно если ССД не корпоративного класса, т.к. в платформе 1С хреновый контроль целостности базы данных. Есть некоторые виды ошибок, которые выявляются только при ТиИ ИБ, соответственно бэкапы недельной, месячной, квартальной давности также будут содержать ошибки.
надёжный «бюджетный» вариант — больше памяти, винчестеры корпоративного класса под базу данных, скл-сервер (темп каталоги желательно держать диске, отдельном от системы и баз).

aXmeD_2

Ежели народу меньше 10, то смысла в SQL сервере нет.

скуль нужен также при замороченной аналитике отчётов в базе и при большом объеме базы.

Сообщение отредактировал rus1an: 29 Июнь 2013 — 13:46

  • Нравится
  • Не нравится

svn 01-07-2013

SSD — проблеммы не решил. Жаль я ни чего не понимаю в 1С. Но как бы ли тормоза с проводками так и остались. Самая большая база почти 700 метров. Буду ждать 1С програмиста (в турлядии отдыхает). Настаивать на том чтобы сделал икзикуцию базам данных (читал что поможет «дефрагментация индексов и снять загрузку на информационную строку») Оперативки 16 — гигов. Сама система не тормозит, на сриншоте показана работа сервера при 24 активных терминальных пользователей.

Прикрепленные изображения

  • Нравится
  • Не нравится

Web-Kg 01-07-2013

А 1С лицензионная?

  • Нравится
  • Не нравится

svn 01-07-2013

А 1С лицензионная?

Нет! На лицензионную 8 ку, контора собирается переходить только на следующий год. (Пока говорят не готовы)

  • Нравится
  • Не нравится

Web-Kg 01-07-2013

А 1С лицензионная?

Нет! На лицензионную 8 ку, контора собирается переходить только на следующий год. (Пока говорят не готовы)

Возможно, в этом и проблема. Что пиратка кривая.

  • Нравится
  • Не нравится

Mirrad 01-07-2013

Ну в самом начале же говорил. для таких случаев используй рейд массив. постав жестаки на 250гигов, один на зеркало, две на обьем.

на базе 1с отключи сжатие, пусть размером будет больше, но по шустрее будет

  • Нравится
  • Не нравится

svn 05-07-2013

Апофеозом этой эпопеи с SSD стал приезд 1с программиста. Не знаю чего он там уж делал с базами данных и пользователями…. (программер приходящий с нами особо не делиться чего делает ) но с 2-го июля, тьфу, тьфу…..тормозов не было.
Я К его приезду снова перенес на SSD операционную систему и попросил его чтобы базы банных располагались именно на диске С:
С райд массивами пока заморачиваться не стал.( но обязательно сделаю) Бекаплю базы каждый день (не сам разумеется, автоматом). Ну и снял образ с системы. В случае краха, смогу менее чем за часик развернуть. Так пока, на всякий раз в недельку буду снимать образ с системы.

  • Нравится
  • Не нравится

Web-Kg 05-07-2013

А лицензионность/пиратность 1С на скорость работы абсолютно никак не влияет.

Еще как влияет. Зависит от того, как её крякнули. Если очень криво — то более чем влияет

  • Нравится
  • Не нравится

MIl 08-07-2013

Крамольная мысль
п1 Скорость сетевой 1С зависит от настроек сети и степени кривости конфигурации 1С (не бывает не кривых конфигураций в изначально кривой системе )
п2 Скорость диска сервера, объем памяти на нем к делу имеет мало отношения (не отрицаю конечно но основные проблемы см п 1)
п3 SSD боятся частых чтений -записи, 1С вторая после виртуальной памяти (файла подкачки) по частоте обращения к диску (если файловый вариант) или БД если серверный — причем соотношение количества циклов записи — чтения явно не в пользу чтения. Тепеь смотрим на «показания к применению» SSD

Вывод SSD для системы,программ — разумно
для БД имхо нет — прямое издевательство над SSD и испытания как быстро он загнется

в этом отношении есть такое хорошее решение RAM диски

Выбираем сервер для 1С

Для начала предлагаю выделить несколько сценариев работы:

1.) Работа с файловой базой через общий ресурс (веб-сервер)

2.) Работа с файловой базой в терминале

3.) Работа с серверной (MSSQL) базой

Работа с файловой базой через общий ресурс (веб-сервер)


Здесь всё довольно таки просто. Если это обычные формы и 1-3 пользователя. То на «сервер» (машина, на которой будет лежать база выбираем:

  • быстые винты — обращаем внимание на скорость вращения шпинделя (берем 7200rpm). Например, не берем у WD серию green, берем black или red. У Seagate можно посмотреть серию Constellation.
  • Процессор — не столь важны ядра, как их частота. 1С довольно таки плохо использует многоядерность(вообще никак), поэтому выгоды от 8ми ядерного процессора вы не получите, 2ух-ядерный процессор с бОльшей частотой уделает его. Например, core i3 4360 — на текущий момент это максимальная частота у intel (4ghz в turbo режиме).
  • Оперативная память — роли она тут не сыграет. Учитывая как современные приложения пожирают память, поставьте 8гб
  • сеть — ну собственно, от 1гбит сети особо вы не выиграете, но тем не менее, если растянута 8ми жильная витая пара (можете посмотреть в коннекторах), то имеет смысл поставить гигабитный коммутатор, заодно будет быстрее файлообмен.
    И последний штрих в этом сценарии — не нужно размещать базу где-то на отдельной машине — длительные операции будут выполняться намного быстрее локально, чем по сети. Поставьте эту машину на рабочее место, откуда планируется, например,закрывать месяц или производить обновления ИБ.

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

    SSD накопитель* вместо обычного винта нас спасёт. Возьмите накопитель на 120гб, благо даже с учетом роста курса стоят они приемлемо. Рекомендую обратить внимание на intel 520/530 series, kingston v300. А лучше просто почитайте обзоры на свежие модели, т.к. этот рынок довольно быстро развивается и на рынок выходят новинки
    *Примечание: Если будете объединять диски в RAID с зеркалированием, например,RAID1. В этом случае есть такой момент: большинству SSD дискам требуется trim для очистки мусора(в основном, касается довольно старых моделей), в режиме raid команда может не поддерживаться и накопитель по мере работы будет деградировать в скорости. Чтобы избежать этой проблемы можно воспользоваться минимум двумя способами: в идеале, приобрести SSD enterprise уровня, например, intel DC3500. Если это покажется дорого можно использовать связку: мат.плата с чипсетом

4гб, а количество пользователей не превышает 4 (это максимальные размер базы и количество пользователей, которые видел я, возможно кто-то встречал случаи, когда через web-сервер с файловой базой работало больше человек? Напишите в комментариях)

Работа с файловой базой в терминале

Перейдем к следующему варианту. У нас есть терминальный сервер и есть файловая база. Здесь всё аналогично сценарию 1 за исключением процессора:

  • SSD накопитель вместо обычного винта.*
    *Примечание: обязательно соберите в диски в RAID с зеркалированием, например,RAID1. В этом случае есть такой момент: большинству SSD дискам требуется trim для очистки мусора(в основном, касается довольно старых моделей), в режиме raid команда может не поддерживаться и накопитель по мере работы будет деградировать в скорости. Чтобы избежать этой проблемы можно воспользоваться минимум двумя способами: в идеале, приобрести SSD enterprise уровня, например, intel DC3500. Если это покажется дорого можно использовать SSD пользовательского класса, но тогда убедитесь, что его ресурс перезаписи достаточен для вашего сценария работы.
  • Процессор — Здесь имеет смысл взять corei5 вместо i3, т.к. 1С будет работать на терминале, дополнительные 2ядра не помешают, но не забываем и про частоту.
  • Оперативная память есть такое устойчивое выражение у админов: памяти много не бывает ). Из моей практики 7 человек при работе в БП3 занимают 8-12гб на терминале (зависит сколько документов открыто у каждого пользователя). Для обычных форм количество памяти можно поделить на 2 :).Примерный расчет можно сделать так: 256мб для самой терминальной сессии + 1,5гб для 1С

Работа с серверной (MSSQL) базой


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

  • Размещение SQL сервера и сервера 1С. На разных машинах или на одной. Есть такой момент: если они находятся на одной машине, то общение между ними происходит через протокол shared memory, и в этом случае мы получаем бонус в быстродействии, которого нет, когда они находятся на разных машинах.
  • Процессор. А вот здесь уже пригодится и высокая тактовая частота и многоядерность. Т.к. у нас есть процесс SQL сервра, если он на этой же машине, и несколько процессов сервера 1С rphost которые будут загружать ядра процессора.Отдельно хочу выделить двухпроцессорные системы (т.е. когда на мат.плате два сокета для и более сокета). Даже если берете с одним пустым сокетом «про запас, докупить процессор потом, если вдруг понадобится». Я видел большое количество двухсокетных серверов, которые до глубокого end of life так и простояли с пустым вторым сокетом. Хотя, если фирма платит. зачем отказывать себе в удовольствии 🙂
  • Оперативная память. В своей работе SQL сервер* активно использует оперативную память, если её недостаточно, он будет лезть на диски, которые даже в случае ssd медленее оперативной памяти. Поэтому тут на памяти экономить не стоит. Заложите в бюджет максимально возможное количество (не забываем, конечно о здравом смысле 🙂 ), и оставьте свободные слоты на материнской плате, чтобы иметь возможность всегда доставить дополнительную планку.
    *Примечание: не забудьте ограничить максимально используемую SQL сервером ОЗУ, чтобы её хватило для ОС и терминальных сессий, а также увеличьте шаги увеличения tmp и базы SQL (по-умолчанию шаг 1мб, что очень мало, установите 200 МБ на базу и 50 МБ на лог)
  • Дисковая подсистема. Может появится мысль, что если объем ОЗУ будет больше размера базы, то она вся будет лежать в памяти и всё будет летать. Оно может так и было бы. до первой операции записи 🙂 которая будет писать на диски. И вот тут то жесткие диски обломают вас 🙂 Используйте SSD диски. И вот тут уже не экономьте не десктопных SSD, приобретите нормальные SSD enterprise уровня. Intel DC3700 -200гб,ресурс 3.7 петабайта (по 10 перезаписей всего объема накопителя в день в течение 5 лет), можно найти за 24000р/шт+второй для RAID1=48000. На лицензии уйдет во много больше.

Вроде всё. Если вопросы/жалобы/предложения — wellcome в комментарии 😉

Как выбрать и настроить сервер для 1C Предприятие 8.3

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

Это касается как небольших компаний, использующих базовые конфигурации: «Управление торговлей»,
«Зарплата и Управление Персоналом», «Бухгалтерский учет», так и применяющих версии «Управление
Производственным Предприятием» или «1С: Предприятие 8.3. Сервер приложений».
Если в вашей компании более 100 сотрудников, то потребуется удаленная работа через Remote Desktop, что
потребует дополнительных ресурсов сервера 1С. Во всех перечисленных случаях грамотный подбор сервера,
полностью (или даже с избытком) отвечающего профилю нагрузки — лучший способ избежать традиционных
для использования 1C проблем.

Выбор процессора и определение объема оперативной памяти для сервера 1С Предприятие 8.3

По моим наблюдениям, в компаниях, штат которых не превышает 10 сотрудников, а база 1-5 гигабайт, «1С:
Предприятие 8.3» обычно устанавливается на выделенном компьютере. И компьютер этот работает в
режиме файлового сервера. Такая нагрузка вполне по силам процессорам Intel Core i3 и E3-12xx. А памяти
оперативной нужно не менее 8 гигабайт (из них 2 гигабайта под ОС).

Средним компаниям, где 5 до 25 пользователей работают с базой до 4 гигабайт лучше всего подойдут
четырехядерные Intel Xeon E3-12xx либо AMD Opteron 4ххх. По четыре гигабайта оперативной памяти хватит
для подсистемы «Сервер приложений» и сервера базы данных MS SQL Server. Традиционно 2 гигабайта
займет ОС. Получается около 10 гигабайт, из которых не менее трети рекомендуется отвести для
кеширования базы данных. С учётом рекомендаций производителей процессоров и постоянно
снижающейся цены за гигабайт памяти рекомендуем 16Гб памяти с коррекцией чётности.
В средних и крупных компаниях (100-150 пользователей и БД от 1 гигабайта) с 1C обычно работают в
терминальном режиме. При этом на сервере одновременно запускается и сама система, и пользовательское
приложение. Опыт подсказывает, что серверные процессоры начального уровня для таких задач не
подходят.

Стоит обратить внимание, что когда оперативной памяти недостаточно, ОС может выгрузить «1С:
Предприятие 8.3. Сервер приложений» в файл подкачки (swap file). Нередко в таких ситуациях приложение
может оказаться недоступным на какое-то время. Закономерный вывод – оперативной памяти всегда
должно быть более чем достаточно.

Чтобы рассчитать требуемые для терминального доступа ресурсы, исхожу из того, что одно процессорное
ядро продуктивно обслуживает до 10 пользовательских сессий. Для сеанса из 20 таких сессий будет вполне
достаточно одного высокочастотного процессора, например, Intel Xeon E3-12xx. Из-за особенностей кода
программы 1С четыре быстрых ядра будут работать эффективнее, чем восемь медленных. Если число
пользователей перевалило за 20, а объем базы данных за 4 гигабайта, необходимы двухпроцессорные
решения на Intel Xeon E5-26xx или AMD Opteron 62xx.

Ссылка на основную публикацию
ВсеИнструменты
Adblock
detector
×
×