Ssd для 1с есть ли смысл
Обновлено: 06.07.2024
Замеры загруженности оборудования также очень важны. У для этой цели реализован сервис hardware, дающий отчёт о превышениях нормативов.
В настольной книге эксперта происходит отсылка к штатным механизмам в рамках операционной системы. Кроме того, вы самостоятельно можете использовать коммерческие утилиты, собирающие загруженность оборудования. Мы сосредоточились не на сборе данных, а на дальнейшей интерпретации собранных значений. Как показала наша практика, имея конкретные цифры, например о загруженности дисковой подсистемы, разные специалисты делают разные выводы. Мы посчитали правильным оттолкнуться не от того, что написано у вендоров в описании счётчиков, а от оценки того, насколько в реальности апгрейд исследуемого компонента сервера может помочь в решении задачи. Например, мы знаем, что решаемая задача – это ускорение оборотно-сальдовой ведомости для бухгалтера. Мало кто может вручную, посмотрев на график любой из характеристик дисков, чётко сказать – коррелируют ли цифры с событиями построения ОСВ и насколько быстрее ОСВ будет работать при замене исследуемых дисков.
Многие администраторы при апгрейде думают, что главная задача – на новом оборудовании получить более быстрое выполнение операции в одном потоке. По нашему опыту, при эксплуатации высоконагруженных информационных систем бОльшим приоритетом является обеспечение неснижения текущей скорости работы в пиковые моменты нагрузки. Зачастую маркетинговые описания вендорами характеристик продаваемого оборудования, не помогают при принятии решения.
Сложилась популярная практика: сравнивать диски по иопсам. Сделаем небольшое отступление и поясним, что иопс – это количество операций ввода-вывода за секунду.
Давайте поставим себя на место продавца, который хочет продать диски. Понятно, что нам нужно всякими правдами и неправдами показать наиболее выгодную информацию. Если при этом часть правды выгоднее не говорить, то кто-то может посчитать, что это не обман. Ярким примером некорректного сравнения иопсов могут быть дисковые подсистемы, построенные на SSD дисках и на SAS дисках. Сравнивая только по иопсам, можно не заметить легко, что время отклика у этого оборудования будет разным. Или например, максимально допустимая глубина очереди к диску, после которой начнётся резкая деградация производительности.
Есть и другие факторы, характеризующие диски, которые мы (как уже и было сказано во введении) можем посчитать несущественными и откинуть. Особо популярной является ситуация, когда происходят тендеры и покупается более дешёвое оборудование, а решение о том, что два различных компонента являются аналогами, принимает человек без достаточного опыта и знаний данного оборудования.
Далее про тесты и замеры, переходим к дисковой подсистеме. Есть много различных методик, порой очень сложных, с кучей вариантов тестирования, где один прогон теста может загружать систему на целые часы.
А мы используем Crystal Diskmark, пусть и не исчерпывающий тест, но очень быстро дающий неплохое представление о производительности дисковой подсистемы.
Вопрос производительности 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С:Предприятие в файловом режиме. И, что особенно важно, доступный по цене даже для небольших предприятий.
Несмотря на то, что программный комплекс 1С существует довольно давно, все равно вокруг него постоянно кипят баталии на форумах. Многие считают, что достаточно несколько HDD и сформированный аппаратный или программный RAID для обеспечения полноценной работоспособности программного комплекса, другие предпочитают использовать более скоростные накопители. Сегодня поговорим о SSD для сервера 1С, а чтобы было проще ориентировать, сформируем небольшой список требований, на которые будем ориентироваться:
программное обеспечение используется всеми сотрудниками, иногда единовременно;
взаимодействует с сайтом и другим программным обеспечением, например, выгружает прайс-лист и цены;
не будем вдаваться в технические подробности, смотрим именно на SSD для сервера 1С;
в качестве базы данных используется Postgre или MSSQL;
при большой нагрузке используется два сервера.
Если пользователей от 5 до 10
Стандартный набор для небольшого бизнеса, несколько человек работают с 1С постоянно, другие эпизодически, потому сценарий здесь крайне простой и не требует излишних затрат. Впрочем, можно выделить несколько возможностей:
Используем жесткие диски с интерфейсом SAS. Дорого и бесполезно. Несмотря на то, что он быстрее SATA, но при этом вдвое дороже. Построение зеркального RAID скушает немало денег без существенной пользы.
Использование HDD SATA. Зеркальный RAID будет крайне медленным, RAID 10 потребует 4 жестких диска. Тоже дороговато, а «бутылочное горлышко» в виде дисковой подсистемы иногда может давать о себе знать. И да, RAID 0 имеет малую отказоустойчивость, потому, если накопитель выйдет из строя, ваши данные будут повреждены, возможно, безвозвратно.
Интерфейс все тот же SATA, но используем твердотельные накопители. Они заметно шустрее и подходят для построения зеркального RAID, что позволит максимально эффективно работать и обезопасить данные. Использовать лучше память TLC или 3D NAND QLC, цена будет приемлемой.
Интерфейс NVMe. Очень быстро, но невероятно дорого, в данном случае будет неоправданной тратой средств.
Теперь расскажу о типах памяти, применяемых в SSD. MLC имеет в распоряжении около 3000 циклов перезаписи отдельной ячейки, потом она с высокой вероятностью выйдет из строя, скорость чтения/записи также довольно высока, около 600 МБ/с для чтения и 200 МБ/с для записи. TLC по скоростным параметрам практически не отличается , но надежность заметно ниже, отдельной ячейки хватает примерно на 1000 циклов перезаписи. 3 D NAND получился заметно надежнее и выше по скорости, при этом, позволил в тот же форм-фактор накопителя запихивать больше памяти . У 3D NAND TLC от 3 до 10 тыс. циклов перезаписи , у MLC 3D NAND примерно 10-15 000. Более подробную информацию можете узнать здесь.
Чтобы быстро убить такой твердотельный накопитель, придется несколько раз в день полностью его заполнять и стирать. В противном случае его спокойно хватит на несколько лет, а то и больше. Современные SSD очень надежны.
Но не стоит забывать про интерфейс NVMe. Архитектурно флеш-память с данным интерфейсом не имеет отличий, но суть в том, что быстродействие SSD ограничивают именно такие шины, как SAS и SATA. NVMe, в отличии от предыдущих типов, подключается напрямую в разъем PCI-E, что приводит к снижениям задержек при ответе на запросы к накопителю, а также конструктивно PCI-E имеет больше полос для пропуска данных, что приводит к значительному росту скорости. В качестве SSD для сервера 1С на 5-10 пользователей в использовании NVMe мало смысла, ведь столь серьезных потребностей в скорости нет, а вот цена будет кусаться, причем серьезно.
Наиболее выгодным вложением будет приобретение простых твердотельных накопителей с интерфейсом SATA, имеющим ресурс от 150 TBW и более или 0,5 DWPD. Обратите внимание следующие модели: Crucial MX500, Micron 5200 Pro. Они вполне подойдут для закрытия потребностей. Можно брать более старые модели, они, конечно, чуть похуже, но незначительно, а дешевле могут быть раза в полтора.
Если пользователей от 10 до 30
В данном случае HDD точно превратится в бутылочное горлышко, потому использовать жесткие диски не рекомендуется. А вот SSD с интерфейсом SATA или SAS закроют ваши потребности в полной мере. Наибольшую эффективность покажут NVMe-накопители, но такие SSD для сервера 1С с приличным объемом могут оказаться неоправданно дорогими.
Ваша задача следующая:
- прикинуть потенциальный объем будущей базы данных;
- рассчитать объем приложения и операционной системы;
- выделить достаточное количество дисков с учетом планируемого RAID.
Обычно в организациях с таким количеством пользователей объем активной базы данных составляет не менее 200 гигабайт, но редко превышает 1 терабайт. RAID 1, обеспечивающий сохранность данных требует 2 накопителя, потому смотрим на следующие модели:
- Seagate IronWolf 110 с объемом 960 Гб. Примерная стоимость около 17 500 рублей.
- Crucial BX500 с аналогичным объемом, стоимость около 7 тыс.
- Intel S4500 Series. Объем тот же, но надежность на порядок выше, чем у предыдущих моделей. Цена от 15 штук.
- Samsung 970 EVO Series. Он самый шустрый, но интерфейс M.2. Соответственно, нужно достаточно количество разъемов PCI-E x4. Стоимость около 12 000.
Конечно, это навскидку, можете выбрать другой объем, а также другие модели, но следите, чтобы TBW не было ниже 150, лучше выше.
SSD для сервера 1С на 30-50 пользователей
Старый добрый SATA еще будет работать, но повысить появится задача повысить не только надежность, но и скорость, потому рассчитывайте так, чтобы можно было построить RAID 10, для которого требуется 4 накопителя. Вас ожидает большое количество смешанных обращений к дисковой подсистеме, много пользователей способны серьезно нагрузить оборудования и даже на SSD создать «бутылочно горлышко». Потому, либо используйте SATA на RAID 10, либо есть вариант остановить выбор на нескольких отдельных серверах и отдельной системе хранения данных для базы данных. Но этот вариант очень дорог.
Если скорость очень важна, стройте дисковую подсистему на интерфейсе NVMe, обратите внимание на SSD Intel серии 760p. Конечно, есть модели получше, но цена получится значительно выше.
50-100 пользователей
Ситуация становится на порядок тяжелее. Придется делать распределенную базу данных, которая будет разделена на активную часть (к которой идут постоянные обращения) и на архивную (лежит в запасе, ибо может пригодиться). Накопители должны быть производительны и надежны. Предпочтение лучше отдать NVMe-накопителям, либо использовать SATA, но на нескольких серверах, которые впоследствии будет объединять данные в единный пул.
100 пользователей и более
Система практически та же, но потребуются производительные SSD для сервера 1С на каждом сервере. Подойдет Intel Optane, накопитель дорогой, но очень надежный. Также может использовать твердотельный накопитель Intel SSD DC P4500 Series, он имеет ресурс 1, 34 PBW, цена, конечно, высокая, но, думаю, для компании с таким количеством пользователей 1С она будет приемлемой. Самый лучшие вариант, использование кластера, в котором как минимум два устройства. Лучше больше, ибо требуется как сервер приложений, так и сервер баз данных. На каждом свои массивы, программными методами объединенные в пул.
Заключение
Как видите, с выбором SSD для сервера 1С могут возникнуть трудности. Но все довольно легко, больше пользователей — выше надежность отдельного накопителя. Для получения скорости придется строить сложные RAID, иногда использовать кластеры серверов. Если задача столь сложна, лучше нанять компетентного специалиста или обратиться к профессионалам, ссылку на которых оставил выше.
В принципе 1 С ни когда не занимался… Тонкостей не знаю.
Стоит сервер терминалом. На диске C –установлена система и 1С-ка, на диски D базы 1С, на F бекапы. Приобретён SSD (128 Гб). Сегодня попробовал перенести туда систему (удачно). Но вот думаю правильно ли я поступил, может есть смысл. SSD использовать под базы. (подключить как D) А ОС…пусть работает на обычном винте…. На один винт слить все не получается…если перенашу базы на диск С – вываливается ошибка. Что продуктивней?…..Использовать SSD для программы или же под базы? (Чую где то, что под базы), но хочется услышать мнения профи… Купил бы второй SSD - но пока бюджет не позволяет.
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
Для БД как раз таки лучше, работать в SSD или оперативной памяти, для быстрого чтения-записи, но я честно говоря не знаю, обычные SSD наверно все таки не стоит под все это дело ставить, для этого есть серверные.
У ССД малое время нароботки, ограничено по количеству чтении и запису. поэтому все те кто используют ссд ставят большую емкую оперативу и отрубают виртуальный диск, кеширование что бы снизить до минимума количество чтения записи.
на ссд ставят ОС, настраивают, ставят проги и тд и используют что бы все это быстро загружалось учитывая при этом что диск больше времени проводит в режиме ЧТЕНИЯ. а ЗАПИС до минимума.
ССД базару нет скоростной, но ненадежный. мое мнение как для хранения базы не годится. Для базы я всегда использую обычные винты в рейд массиве в зеркальном режиме, страховаться всегда надо.
Так что на ССД поставь ОС, насатрой, отключи виртуалку, кеширование и все. Хотя вообще зачем сервер терминалу ССД. он же один раз загрузится и все, будет круглые сутки пахать.
Ну и хай ССД стоит под 1С, главное бекапы делать на обычный хард и еще в облачное хранилище желательно. Смотря насколько все важно. По уму всегда настроить можно.
Хуже админа, который намеренно вредит, есть только админы, которые вредят из лучших соображений.
подключайте мониторинги и смотрите iow процессора. если оверхеда нет, то и делать ничего не надо.
в случае перехода на SSD
проблемы с малым (а на самом деле не таким уж и малым) временем работы SSD-диска решаются его заменой заранее, дабы перестраховаться.
проблемы же порядка "внезапно умер" есть у всех носителей.
СИС
на сколько я понимаю, там терминальный сервер для тонких клиентов.Ну и как результат? 1С стала работать быстрее или нет?
в данном случае перенос системы на SSD вижу более логичным, чем перенос туда базы 1С.
Перенос системы на SSD, дал результат - но не тот чего ожидалось. Временами 1С (когда делают какието проводки) просто тупит (Всего в сети 20 пользователей. Работает все хорошо. но временами случается вот такая ерундень.), буквально вчера, вернул все как было окрамя того что базу скинул на SSD. Сетка работает хорошо. От сервера до коммутатора гигабит. далее по сотни на машину. Вот сегодня тестовый режим, посмотрим поможет ли SSD.
svn
Сколько оперативной памяти на терминальном сервере? Какого размера база? Все пользователи работают исключительно через терминал?Временами 1С (когда делают какието проводки) просто тупит (Всего в сети 20 пользователей
имхо, держать файловую базу на ССД не самый лучший вариант, особенно если ССД не корпоративного класса, т.к. в платформе 1С хреновый контроль целостности базы данных. Есть некоторые виды ошибок, которые выявляются только при ТиИ ИБ, соответственно бэкапы недельной, месячной, квартальной давности также будут содержать ошибки.
надёжный "бюджетный" вариант - больше памяти, винчестеры корпоративного класса под базу данных, скл-сервер (темп каталоги желательно держать диске, отдельном от системы и баз).
aXmeD_2
скуль нужен также при замороченной аналитике отчётов в базе и при большом объеме базы.Ежели народу меньше 10, то смысла в SQL сервере нет.
SSD - проблеммы не решил. Жаль я ни чего не понимаю в 1С. Но как бы ли тормоза с проводками так и остались. Самая большая база почти 700 метров. Буду ждать 1С програмиста (в турлядии отдыхает). Настаивать на том чтобы сделал икзикуцию базам данных (читал что поможет "дефрагментация индексов и снять загрузку на информационную строку") Оперативки 16 - гигов. Сама система не тормозит, на сриншоте показана работа сервера при 24 активных терминальных пользователей.
Прикрепленные изображения
А 1С лицензионная?
Возможно, в этом и проблема. Что пиратка кривая.
Ну в самом начале же говорил. для таких случаев используй рейд массив. постав жестаки на 250гигов, один на зеркало, две на обьем.
на базе 1с отключи сжатие, пусть размером будет больше, но по шустрее будет
Апофеозом этой эпопеи с SSD стал приезд 1с программиста. Не знаю чего он там уж делал с базами данных и пользователями…. (программер приходящий с нами особо не делиться чего делает ) но с 2-го июля, тьфу, тьфу…..тормозов не было.
Я К его приезду снова перенес на SSD операционную систему и попросил его чтобы базы банных располагались именно на диске С:
С райд массивами пока заморачиваться не стал.( но обязательно сделаю) Бекаплю базы каждый день (не сам разумеется, автоматом). Ну и снял образ с системы. В случае краха, смогу менее чем за часик развернуть. Так пока, на всякий раз в недельку буду снимать образ с системы.
Еще как влияет. Зависит от того, как её крякнули. Если очень криво - то более чем влияетА лицензионность/пиратность 1С на скорость работы абсолютно никак не влияет.
Крамольная мысль
п1 Скорость сетевой 1С зависит от настроек сети и степени кривости конфигурации 1С (не бывает не кривых конфигураций в изначально кривой системе )
п2 Скорость диска сервера, объем памяти на нем к делу имеет мало отношения (не отрицаю конечно но основные проблемы см п 1)
п3 SSD боятся частых чтений -записи, 1С вторая после виртуальной памяти (файла подкачки) по частоте обращения к диску (если файловый вариант) или БД если серверный - причем соотношение количества циклов записи - чтения явно не в пользу чтения. Тепеь смотрим на "показания к применению" SSD
Вывод SSD для системы,программ - разумно
для БД имхо нет - прямое издевательство над SSD и испытания как быстро он загнется
Читайте также: