Перейти к содержимому

Какой ssd выбрать для 1с

  • автор:

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

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

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

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

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

1cv83-SSD-001.jpg

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

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

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

1cv83-SSD-002.jpg

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

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

1cv83-SSD-003.jpg

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

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

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

1cv83-SSD-004.jpg

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

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

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

1cv83-SSD-005.jpg

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

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

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

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

Дополнительные материалы:

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Поддержи проект!

Или подпишись на наш Телеграм-канал: Подпишись на наш Telegram-канал

Какой SSD выбрать для файловой 1С

Работаю с 1С на ноуте, т.е. всегда в базе работаю один, и в 99% база файловая.

Планирую поменять свой SSD (Plextor M3 на 256Гб) на что-то посвежее, на 512Гб.

Варианта три:
1. Samsung 950 Pro (но дорого блин)
2. Samsung 850 Pro
3. что-то из серверной линейки ssd

Вопрос, какие параметры Sdd наиболее влияют на работу 1С?
Например групповое перепроведение документов или свертка базы.

Т.е. какие параметры лучше смотреть, т.к. 2500Мб\сек последовательное чтение 950 PRo, скорей всего не сильно то помогут, а вот I\O наверно полезнее будет.

ждать загрузку данных час или 30 мин, разница есть, и если ssd поможет выполнять больше работы за одно и тоже время, то явно НЕ ЛЮБОЙ максимальною скорость.

Спрошу по другому — на каких дисковых операция 1с упирается в диск?

(2) естественно, что на записи и обновлении индексных данных. Но поскольку в частном конкретном случае не озвучены никакие более параметры, за исключением SSD, оценивать влияние именно SSD на текущую работу некорректно может быть.

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

Разница в цена почти в 2 раза
Пока разницы в работе не заметил.

(10) ну так у них характеристики на 10% отличаются.
10 сек или 9, не заметишь.

Да и 100 мин или 90, тоже особо не заметно.

(0) >> поменять свой SSD (Plextor M3 на 256Гб) на что-то посвежее, на 512Гб.

А в чем смысл замены?

ИМХО, меняя один SSD на другой, особой разницы, заметной глазу (как при смене обычного HDD на SSD), ты уже не получишь. Так что высчитывание скоростей чтения, записи, доступа и пр. и пр. — всё это знатное шаманство, дающее выигрыш одного диска над другим в единицы процентов. Ну будет у тебя расчет себестоимости в каком-нибудь УППырище делаться вместо 2-х часов за 1 час и 50 минут.

Если на ноуте обрабатываются какие-либо критичные и ценные данные, то имеет смысл смотреть на надёжность диска (например, гарантия производителя, как у Intel, или накопленная база отзывов, или вообще брать что-то из корпоративного сегмента).

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

(21) На мой взгляд варианта два: а) понтануться, б) "деньги ляжку жгут".

(23) Пункты а) и б), мне пофиг.
А свое время, не пофиг.

23 сообщения, а никто не может ответить какие операции "жрет" 1С на диски.

(24) Тебе 23 раза ответили, что 1С в любой SSD упереться не может — не способна она на это. И замена на любой другой не даст заметного эффекта. Ты упорно от нас требуешь показать "какие операции "жрет" 1С на диски". Поэтому серьёзно никто и не отвечает.

Открой монитор ресурсов на закладке диски, запусти любую операцию в 1С и посмотри загрузку. Максимум что ты там увидишь 10%.

(0) Шило на мыло. На слабом проце SSD не спасет. Нужен самый быстрый проц в однопоточном режиме еще. Intel Core i7-4790K @ 4.00GHz

Влияние ресурса перезаписи на выбор SSD

Выбор SSD для клиент-серверного варианта 1С для коллективной работы отличается от покупки SSD для своего ноутбука.

Значимым требованием к диску является в том числе такой фактор, как ресурс перезаписи.

Быстрее всего на класс устройства можно сориентироваться по показателям DWPD (или “полных перезаписей устройства в день в течение гарантийного срока”) и/или TBW/PBW (или “общий объём данных, который за время гарантийного срока можно записать на устройство»), измеряется в терабайтах для TBW и петабайтах для PBW. Чем выше/больше “полных перезаписей устройства в день” DWPD — тем обычно выше класс устройства.

Разные производители по-разному трактуют классы промышленных SSD, но в целом можно привести такой пример разделения:

Косвенно класс устройства можно понять, сопоставляя паспортные IOPS на чтение и запись. Чем ниже показатель записи по отношению к чтению — тем вероятно ниже и класс устройства. Например, у крайне производительных intel Optane первого поколения (P4800X) с DWPD 30-60 соотношение примерно 550K/550K, у “средних” P4610 с DWPD 3 соотношение 638K/222K, а у совсем “слабых” P4101 с DWPD на уровне 0.1-0.3 — соотношение 275K/16K у старшей модели в линейке и 60K/2.2K у младшей.

Очень важно понимать, что показатель износостойкости говорит не только о том, сколько всего данных за гарантийный срок можно будет записать на носитель, но и косвенно говорит о том, какой объём данных в среднем в сутки можно на этот носитель записать без существенного ухудшения производительности (то есть деградации производительности, о чём мы подробнее расскажем в одной из следующих статей). Закончиться ресурс накопителя может ещё только через годы, а деградация производительности может себя проявить прямо с первого дня активной эксплуатации.

К сожалению, на сайте intel не по всем моделям можно быстро увидеть паспортную ресурсоёмкость устройства, которая выражается в параметрах , поэтому приходится использовать сторонние источники. В качестве примера ресурса, где можно быстро сравнить ресурсоемкость по DWPD/TBW: https://en.wikipedia.org/wiki/List_of_Intel_SSDs .

Оценка текущей интенсивности записи на диск

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

Если Вы используете 1С в наиболее популярном варианте в связке с MS SQL Server, то основная нагрузка на диск будет через него и с помощью запросов к статистике сервера можно получить оценку интенсивности записи .

Нюанс тут заключается в том, что СУБД оценивает только “свою” запись (то есть не видит любые другие объёмы, записанные другими службами), и полученные цифры говорят об объемах чтения и записи только с момента старта службы MS SQL.
Обратите внимание, что если у вас будут и другие источники значимой интенсивности записи, то ниже показанный способ будет недостаточным. Если вы пишете например в виртуалке на виртуальный диск, расположенный на общем внешнем хранилище дисков, то реальную нагрузку на диски мы можем и не измерить правильно в таком подходе.

Данные с СУБД можно получать сразу в сгруппированном по дискам виде, и сразу с пересчётом в гигабайты, например таким запросом:

▶ Нажмите чтобы посмотреть текст запроса

SELECT SUBSTRING(saf.physical_name, 1, 1) AS [Диск]

, SUM(vfs.num_of_bytes_read/1024/1024/1024) AS [Прочитано (Гб)]

, SUM(vfs.num_of_bytes_written/1024/1024/1024) AS [Записано (Гб)]

FROM sys.master_files AS saf

JOIN sys.dm_io_virtual_file_stats(NULL,NULL) AS vfs

ON vfs.database_id = saf.database_id

AND vfs.file_id = saf.file_id

GROUP BY SUBSTRING(saf.physical_name, 1, 1)

например, получится вот такой результат:

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

▶ Нажмите чтобы посмотреть текст запроса

DECLARE @Days int
DECLARE @Hours int
DECLARE @Mins int
DECLARE @Secs int

SET @Secs = (
SELECT datediff(ss, login_time, getdate())
FROM master..sysprocesses
WHERE spid = 1
)
SET @Days = ((@Secs/60)/60)/24
SET @Hours = ((@Secs/60)/60)%24
SET @Mins = (@Secs/60)%60
SET @Secs = @Secs%60

PRINT ‘SQL server on »’ + @@SERVERNAME + »’ has been up for: ‘ +
convert(varchar(20), @Days) + ‘ day(s), ‘ +
convert(varchar(2), @Hours) + ‘ hour(s), ‘ +
convert(varchar(2), @Mins) + ‘ minute(s), ‘ +
convert(varchar(2), @Secs) + ‘ second(s).’

ВАЖНО. Если с момента рестарта пройдет меньше суток, то надо как минимум подождать пока набегут сутки и повторно посчитать.

ВАЖНО. Интенсивность записи в разные дни может быть сильно разная. Достаточно репрезентативным показательным интервалом времени аптайма сервера для оценки можно считать квартал. Либо генерируете в исследуемом небольшом период пик нагрузки.

ВАЖНО. Любая запись на диски, сделанная НЕ средствами СУБД, например полных бэкапов внешними средствами (например Акронис Бэкап) в замер субд не попадет.

Как видно на снимке, служба сервера запущена 14 дней 19 часов (или 355 часов) назад, и статистика накоплена именно за это время.

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

Например, в примере на диск P за это время записано 5142 гигабайта, то есть за неполных 15 дней выходит в среднем примерно по 350 гигабайт в сутки. Как получена эта величина: 5142 записанных гигабайта дел им на 355 часов сбора статистики и умножаем на 24 часа в сутках.

Таким образом в текущем примере интенсивность записи — 350 гигабайт в сутки.

Теперь чтобы подобрать SSD, надо посмотреть на подходящий размер и соответствующих “полных перезаписей устройства в день” DWPD.

Если Вы берете диск с 0,1 DWPD intel P4101 емкостью 512 Gb, то 512 * 0,1 = 51,2 Гб/сутки < реальной нагрузки 350 гигабайт в сутки. На практике Вы получите непредсказуемую неудовлетворительную работу диска.
Кроме того, в реальной жизни не только SQL Server генерирует нагрузку, так что надо еще делать поправочный коэф.-т на другую активность.

Требуемый нам диск должен перезаписывать более 400 Гигабайт. Понятно, что кроме этого надо смотреть на требуемый реальный размер диска. Вдруг у нас база размером в терабайт. Рассмотрим на примере диска intel p4610 размером 1,6 Тб

Рейтинг износоустойчивости (операции записи за все время эксплуатации): 12.25PBW — это означает гарантированную возможность записать 12.25 петабайта за гарантийный срок, который составляет: Гарантийный период: 5 yrs, то есть 5 лет.

Пересчитываем условно рейтинг износоустойчивости в расчёте “на 1 день”: 12.25 петабайт = 12250 терабайт, делим на (5 лет Х на 365 дней), получаем 6.7 терабайта в день, теперь делим эту величину на объём диска и получаем примерно 4 объёма полной перезаписи в день (то есть DWPD).

Сравниваем 6.7 Тб и 350 Гб реальной нагрузки (лучше с некоторым поправочным коэф.-том) — получаем приемлемый запас по ресурсу перезаписи, который гарантированно справится с текущей нагрузкой.

При этом надо понимать, что статистика представляет собой “среднее по больнице”, в периоды высокой активности пользователей запись может быть в несколько раз больше, или во время ночных регламентов на СУБД, а в другие периоды бывает поспокойней.

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

Бонус: если используется платный сервис http://gilev.ru/sqlsize

Если на сервере СУБД используется платный сервис http://gilev.ru/sqlsize, то можно сразу воспользоваться уже собранными там данными.

Поскольку данные статистики использования дисков накапливаются с момента старта службы — будет полезно сразу оценить время, за которое эти данные накоплены, в сервисе SQLSize это пункт “Параметры СУБД — Параметры SQL сервер”, пункты “Аптайм (часов)” и “Аптайм (дней)”, например мы там увидим 297 часов или 13 дней.

Далее смотрим статистику использования дисковой подсистемы в пункте “Нагрузка на сервер СУБД — Диски — Интенсивность использования”.

Надпись справа от названия отчёта информирует о том, когда именно была получена эта информация. На данном снимке нас интересует колонка “Записано, МБ”. Если просуммировать все показанные на снимке значения из этой колонки — получается примерно 4540 гигабайт записи на диск C.

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

В данном примере получается в среднем примерно по 350 гигабайт в сутки. При этом надо понимать, что статистика представляет собой “среднее по больнице”, ведь наверняка в периоды высокой активности пользователей запись существенно больше, или во время ночных регламентов на СУБД, а в другие периоды бывает поспокойней. Наиболее представительной данная информация будет например, если скриптом получать в некую табличку результат запросов по объёму записи каждый час в течение скажем нескольких дней высокой загрузки, а затем определить интенсивность запись именно в пиковые периоды, когда это могло мешать производительности бизнеса. Например, ночью нагрузка на диски будет большая, но в это время никто в базе не работает, и диски к началу рабочего дня уже могли успеть “прийти в себя”. Но может оказаться и так, что в течение нескольких часов нагрузка на диски по записи существенно превышает паспортную, и производительность записи заметно ухудшается (о чём нам как бы намекает из вышеприведённого снимка колонка “Отклик на запись”, где среднее сглаженное время отклика одной операции записи на разных файлах плавает от 13 до 27 миллисекунд, что было когда-то приемлемо для механических дисков, но это много для SSD, особенно с учётом того, что это той же “среднее по больнице” за 13 дней).

Дальше будет полезно выяснить, какая же модель накопителей используется в данном сервере, после этого сравнить «расчётные по DWPD» объёмы записи с фактическими.

Заметим, что производитель решил умолчать в данной спецификации о таких важных параметрах, как DWPD (гарантийный показатель количества перезаписей в день) и гарантийный ресурс устройства на запись. Практически единственным намёком на класс устройства в данной спецификации может служить соотношение IOPS на чтение и запись, а именно 275К против 16К.

Однако заметим, что если поискать данное устройство на сайте intel https://www.intel.ru/content/www/ru/ru/products/memory-storage/solid-state-drives/data-center-ssds.html — мы его найдём в разделе “Твердотельные накопители Intel® серии D1:

Оптимальная надежность и производительность бюджетного уровня для рабочих нагрузок с большим количеством операций чтения“. На странице описания собственно модели P4101 https://www.intel.ru/content/www/ru/ru/products/memory-storage/solid-state-drives/data-center-ssds/d1-series/dc-p4101-series.html написано: “Этот твердотельный накопитель с 64-слойной технологией Intel® TLC PCIe* NAND в форм-факторе M.2 разработан для моделей использования в качестве загрузочного диска и рабочих нагрузок с небольшим количеством операций чтения, таких как индексирование поисковых запросов и кэширование на периферии.”. Это такой намёк от intel, что не надо подобный диск использовать под активно записываемые базы данных ��

Дальнейшие поиски в интернете показывают различные варианты DWPD для данного устройства, но в целом они колеблются между 0.1 и 0.3, что для накопителя с ёмкостью 1 терабайт означает расчётный объём допустимой записи не более 100-300 гигабайт в сутки, причём расчёт исходит из идеально ровного распределения данного объёма внутри времени суток, то есть за каждый час не более 1/24 данного объёма. Очевидно, если в наблюдаемом примере каждые сутки на диск пишется более 350 гигабайт — это даже в оптимистичном варианте находится выше уровня предельно допустимой нагрузки. А если исходить из того, что в пиках активности запись на диск производится гораздо интенсивнее — станет понятно, что данная модель откровенно не подходит для имеющейся нагрузки , нужно устройство с существенно более высоким показателем DWPD на имеющийся объём (например, из имеющихся в продаже устройств могут подойти: intel P4610 с паспортным DWPD 3, то есть при объёме 1.6 терабайта — возможность записать в сутки до 4.8 терабайт, или Samsung PM1735 с таким же паспортным DWPD3).

Естественно любой продавец будет продавать диски подешевле, так как при этом он будет делать Вам более выгодное предложение нежели конкурент. В его задачу будет входить убедить Вас всеми правдами и неправдами — у нас есть «аналог», но только подешевле… При этом смотреть Вашу реальную интенсивность он вряд ли будет. Реальная судьба систем продавцов не интересует, даже если они Вам говорят обратное — они не могут быть объективны и не несут финансовой ответственности за ситуации, когда диск не решает возложенные на него задачи.

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

Собираем бюджетный сервер 1С на 30-40 пользователей

Всем привет, меня зовут Алексей, я занимаюсь развитием в компании Server Gate. Наша компания помогает малому и среднему бизнесу существенно сэкономить при покупке серверного и сетевого оборудования. И сегодня мы расскажем вам про бюджетное решение для сервера 1С от компании Hewlett Packard Enterprise.

Вторичный рынок серверного и сетевого оборудования можно сравнить с рынком автомобилей – лучше купить Mercedes с пробегом, чем нового китайца на фарше. Поэтому мы предлагаем нашим клиентам только used-серверы DELL и HP – «Мерседесы» в мире серверов.

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

Чтобы при работе с самой программой 1С не было тормозов, чтобы бизнес не терял деньги из-за простоя сотрудников, чтобы все данные были надёжно защищены, очень важно рассчитать конфигурацию под требования вашей компании. Можно растянуть статью на много-много букв и сделать её скучной, но мы разберем идеальное решение от компании Hewlett-Packard Enterprise на 30-40 пользователей.

В первую очередь сама система 1С любит высокую частоту процессора, начиная от 3.00 GHz и выше. Если пользователей не больше 50, то можно смело рассматривать однопроцессорную платформу (существуют ещё платформы на 2, 4 и даже 8 процессоров, но для нашей задачи это избыточно). Во-вторых, очень важно размещать вашу базу данных на SSD накопителях, при этом желательно чтобы накопителей было 2 или 4, чтобы построить RAID-1 и повысить отказоустойчивость своей базы данных. В-третьих, большой объём серверной памяти с коррекцией ошибок позволит системе работать быстро и стабильно.

Для бэкапов сервера лучше использовать отдельный NAS-сервер, но если стоит задача сэкономить, то можно построить RAID-5 массив на этом сервере из обычных HDD, и каждый день, где-нибудь в 4-5 утра производить бэкапы системы.

Мы подумали, что за простое описание конфигурации и публикации её здесь нас закидают помидорами, поэтому решили подкрепить свои слова фактами. Итак, мы собрали следующую конфигурацию:

— Сервер Hewlett Packard Enterprise DL120 Gen9

— Процессор Intel Xeon E5-1650v4 (базовая частота 3,60 GHz, 6 ядер, 12 потоков, 15MB кеша)

— Оперативная память DDR4, 64GB 2400 MHz (16GB x 4 планки, т.к. процессор работает на 4-ёх каналах, поэтому для максимальной производительности рекомендуем использовать именно 4 или 8 планок)

— Встроенный RAID-контроллер HPE Smart Array B140i Controller, который позволяет работать только с SATA-дисками и накопителями и нам этого достаточно, потому что мы использовали SATA SSD. Контроллер является программным, поэтому важно чтобы сервер поддерживал UEFI.

— SSD накопители – 2 x Intel 150GB DC S3520 6G 2.5″ SATA, на одном мы установили операционную систему Windows Server 2019, а на втором мы установим нашу базу данных.

Чтобы проанализировать эффективность сервера 1С Предприятия специально-обученные люди придумали особенный тест и назвали его «Тест Гилёва», который запускается непосредственно из-под 1С. Поэтому, первое с чего мы начнём это с проверки самого сервера и установки операционной системы. Для этого подключаемся к серверу через порт удалённого администрирования (Integrated Lights Out), производим диагностику, а далее прям в браузере занимаемся установкой и настройкой Windows Server 2019.

После установки, нужно сделать первичные настройки политики безопасности и настроить Remote Desktop Protocol (RDP), который позволит подключаться к серверу напрямую для установки сервера 1С. После подключения отформатируем второй накопитель и установим на него 1С Предприятие 8.3

Базу данных 1С Предприятия можно выбрать двух типов – файловая (это когда все данных находятся в файлах на жёстком диске) и SQL (всем привычный язык структурированных запросов). Тест мы произведем и там, и там и сейчас будет понятно почему.

Так, сервер 1С мы скачали, теперь нам нужно накатить на него обработку «Гилёва». Подключаем из конфигуратора обработку и загружаем саму 1С. Перед нами появляется интерфейс, в котором есть только 1 кнопка – «Выполнить тест». Нажимаем и ждём результатов, которые измеряются в «Попугаях» — это абстрактная единица измерения, которой пользуются айтишники для тестирования чего-либо.

Подумав где-то с минут 5, мы получаем следующие результаты тестирования:

Итог тестирования файловой базы данных составил 57,47 единиц в попугаях, что является почти идеальным показателем. Но вы должны понимать, что это нагрузка всего от 1 пользователя, поэтому при нагрузке в 30-40 человек файловая база данных не выдаст таких замечательных показателей.

Кстати, на скриншоте видно, что чаще всего администраторы тестируют именно SQL базу данных.

Поэтому перейдём к тестированию SQL базы.

Перед тем как произвести тестирование, нам потребуется снести файловую 1С, установить MSSQL Server 2019 и его настроить. Чтобы не томить вас скучным процессом установки и томительной настройкой, давайте сразу перейдём к результатам тестирования.

Итог тестирования SQL базы данных составил уже 31.06 единиц, что является «четвёркой с минусом» для сервера на 40 пользователей. Как сказал наш программист 1С – SQL база данных никогда не выдаст хороших показателей из-за массы оптимизаций Windows Server 2019 и самого сервера MSSQL. Либо, как вариант, можно собрать другой сервер на Intel Xeon Gold Series, но цена такого сервера будет свыше 200 000 рублей, что по нашим меркам не является бюджетным решением для малого и среднего бизнеса.

Чтобы обеспечить безотказную работу вашей компании, не нужно закапывать бешенные бюджеты в супер-серверы. Стоимость тестируемого нами сервера составила 86 284 рубля с НДС (на момент написания статьи). Достаточно взять этот сервер на вторичном рынке за разумные деньги (кстати, с гарантией до 5 лет) и позволить вашим бухгалтерам и менеджерам по продажам ощутить скорость и комфорт при работе с системами бухгалтерского и управленческого учёта. А вам – сэкономить на простоях кадров и обеспечить надёжность вашей информационной структуры.

P.S. Если статья понравилась, буду очень рад вашим лайкам 😉

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

А куда им деваться? Мы для обслуживания ИП на УСН свою систему написали, которая сводит баланс на 300 пользователей за полминуты на i5 с 4 гб, но не все же могут написать аналог 1С.

а оно будет работать быстрее чем свой сервер? Хотелось бы. 8-ка для типового пользователя работает, в принципе, на порядок медленнее 7-ки.
Плюс вопрос с интернетом — его пропадание будет означать, что работа офиса встанет. Сбои у провайдера в любом случае бывают чаще чем сбои с сервером.
Плюс надежность — не известно что там с бэкапами в облаке и насколько декларируемая надежность соответствует реальной в то время как у себя всегда можно иметь запасной сервер и время переключения будет равно нескольким минутам (с некоторой потерей в актуальности данных).

P.S. "Чтобы при работе с самой программой 1С не было тормозов" идеально не работать с 1С.

Так и я об этом. ��

Для 10 пользователей – вероятнее всего вы правы. А для 30 – необходимость.

А что использовать для учёта товара? Я вот пока на 1с в облаке от scloud, понимаю, что лучше раз заплатит за свою машину, но в нашей стране любят свет отключать, постоянно якобы какие-то поломки и профилактики

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

А чем сервера HP и DELL отличаются от небрендовых?

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

Стабильность работы, назначение, технические характеристики будут вероятнее всего идентичными, но все же различия есть. Для начала – качество сборки и надежность материалов, каждый компонент легко и просто устанавливается (будь то блок питания, вентилятор, салазки с жесткими дисками или другие компоненты). Качество самого металла даже разное, и не в пользу дешевых брендов. Ко мне однажды попалась платформа от Supermicro, причём современная. И то что я описал выше – практический пример, а не коммерческая хвальба. В серверах HP/DELL нашпигована масса датчиков, которая позволяет анализировать все показатели сервера, чтобы диагностировать надвигающийся шторм на ранней стадии и избежать больших проблем, сообщив об этом администратору по почте. И это далеко не все.

P. S. Что же касается китайца, который быстро разгоняется, то я бы здесь посмотрел в сравнении. Скажем – простейший GLK, 2012-2015 годов, с 221 л.с. под капотом, и современного китайца, любой HUV (не разбираюсь в модельных рядах, к счастью). Уверен, китаец будет восхищаться элегантностью задних фонарей немецкого коллеги.

Качество сборки это приятно конечно, но обычно сервер поставят и годами не трогают. То есть оно особо ни на что не влияет.
Насчет датчиков тоже непонятно. О перегрузке предупредит какой-нибудь Zabbix. О дисках Smart. У меня в аренде есть и HP и DELL, но что-то никакой дополнительной инфы от них не получаю 🙂
Есть ли еще какие-то преимущества? Или (как минимум при аренде) нет смысла переплачивать?
И кто сказал что китайцы быстро разгоняются 🙂 Делать приятный дизайн и нашпиговывать его фичами они научились, но вот с динамикой у китайцев пока беда)

Возможно у вас старенькие машинки, вроде Gen5-Gen7, потому что начиная с Gen8 поколения они умеют отправлять информацию на почту — https://www.youtube.com/watch?v=N_gZ5eFZws4. Речь не о перегрузках, а о тех же вентиляторах или жёстких дисках, о которых вас не проинформирует ни Zabbix, ни Smart (который не показывает состояние SAS дисков).
Если говорить про аренду, то вопрос — что арендуете и за какие деньги? Мы, например, тоже сдаем железо в аренду, но этот вариант подходит только тем клиентам, которым нужен сервер на 2-6 месяцев. При более длительной аренде, сервер выгоднее купить, тем более б/у.
Но из соображений безопасности, я бы не рекомендовал арендовать сервер под 1С как минимум.

P. S. Про китайца вы сказали — "Мерседес отличается от китайца в первую очередь по ездовым характеристикам. Быстрее разгоняется, лучше рулится, лучше держит дорогу и т.д."
Во всяком случае я вашу фразу интерпретировал как преимущества китайского автопрома 🙂

Хочется к публикации добавить немного спорной отсебятины, ибо на вкус и цвет товарища нет.
У нас много раз вставал вопрос о том какую инфраструктуру строить: облачную или собственную (конторка не большая). По сути главным доводом владельцев за облачную инфраструктуру было нежелание строить серверную. Пока я не нашел как вместо серверной использовать прямо в офисе серверный шкаф с активным подавлением шума. Если взвесить все "За" и "Против" по ссылке ниже, можно сильно задуматься о таком решении.

Облачные технологии это тупик и обман, они не лучше своего сервера.

Это знаем мы, это знаете вы, но попробуйте это объяснить далеким от IT людям, тем более владельцам.

я владелец бизнеса, правда, я много проработал в IT бизнеса. У облачных технологий есть свои перспективы, но то, что я вижу сейчас — это дутый пузырь. Пример — Гугл таблица, занимающая почти 1 гб оперативки и хорошо загружающая локальный процессор(при том что она как бы облачная) с откликом в 5-10 секунд на обновление после ввода данных , в то время как ее эксель аналог вполне мог бы работать с памятью раз в 100 меньше и в столько же раз быстрее.

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *