Есть Сервер 1С 8.3 и база данных MSSQL 2014, работающая на виртуализированном Windows Server 2012 R2 (VMware ESXi). У меня есть задача от Бухгалтерии повысить производительность . База данных имеет около 70 ГБ, выделенная оперативная память составляет около 90 ГБ. Виртуальная машина сейчас работает на дисках SAS 10k - RAID10. Я хочу перейти со спиннеров на SSD, но я хотел бы понять, даст ли это большую разницу в производительности, поскольку обновление дорогое, я говорю о Enterprise SSD. Ниже я написал, какие спиннеры я использую в данный момент, и SSD, которые будут куплены в конечном итоге, SSD будут использоваться в RAID10. Я хотел бы попросить вас помочь мне понять, даст ли модернизация необходимый прирост производительности? Спасибо.
Что есть в наличии и крутится в данный момент: IBM (Seagate ST900MM0168 900GB 10K RPM 12Gbps 2.5" SAS Hard Drive)
Brand: IBM
Model: 01EJ586
Capacity: 900Gb
Interface: SAS 2.5 inch
Data Transfer Rate: 12Gb/s
Rotational Speed: 10,000rpm
External Transfer Rate: 1200 MB/s
Sustained Transfer Rate (Outer to Inner Diameter): 215 to 108 MB/s
Average Latency: 2.9ms
Average Seek Time: 4.6ms
Internal Cache: 128Mb
Hot-swappable: Yes
Caddie: Yes
Что предполагается купить: IBM AS7J 1.6TB 12G SAS 2.5" MLC G3HS Enterprise SSD
Based on proven HGST Ultrastar SSD1600MM drive technology
Uses 20 nm Multi-Level Cell (MLC) NAND flash memory
Part number - 2.5" G3HS: 00FN409
Interface: 12 Gbps SAS
Capacity: 1.6 TB
Endurance (drivewrites per day over 5 years): 10 DWPD
Endurance (total bytes written): 29.2 PB
Data reliability: 1 in 10(17) bits read
MTBF: 2,500,000 hours (0.35% AFR)
IOPS reads (4 KB blocks): 130,000
IOPS writes (4 KB blocks): 100,000
Sequential read rate (64 KB blocks): 1100 MBps
Sequential write rate (64 KB blocks): 765 MBps
Read latency (seq): 100 µs
Write latency (seq): 45 µs
Под "спиннерами" подразумевается HDD? Или вот это?
В любом случае, переход с HDD на SSD безусловно дает прирост производительности, а вот насколько большой - зависит от многих факторов, а не только от типа накопителя.
(1)Хотелось бы узнать количество пользователей. И на чем организованна сама сеть в офисе. Может это узкое место.
В целом прирост однозначно будет: перепроведение ускорится приблизительно на 30%. При этом почти полностью снимется проблема с падением производительности при совместной работе.
(5)Бухгалтерия, около 10, работают на обычных формах (толстый клиент) и еще около 20 бухгалтеров в филиалах заходят иногда на веб морде для формирование пару отчетов, но они практически никакой нагрузке не дают на БД. Сеть 1Gbps, но почти все бухгалтера работают на RDP сервере.
(1) Ускорение виртуалки за счет железа - если и сработает, то эффект будет минимальным.
Советую прежде всего выявить в каких случаях тормозит. Например: у юзера с ПолнымиПравами всё в порядке, а у обычных тормоза; Так в этом случае надо с правами работать, а не ssd покупать.
Хочу понять если разумна потратить $1.200 за один SSD, когда нужны 4 для RAID10. Для меня важно чтобы бухгалтерия почуствовала не только на славах но довольно ощютимый прирост производительности. 1С на команды быстро реагирует, большые проблемы чаничаются когда формируются разные отчеты, нужно ждать минуты..
(7) А есть сейчас какой-то тест производительности системы? Что конкретно тормозит? Есть список ключевых операций и целевое время?
Вообще, SSD повысят производительность системы ввода-вывода, но они не повысят производительность 1С, как системы. Вот у Вас база, которая целиком может поместиться в память (70 vs 100 гигов), поэтому в общем и целом в части чтения у Вас и так все гут. Тем более при текущей работе используется гораздо меньше данных, чем есть в базе.
Я бы так поступил:
1. Протестил однопоток в Гилеве.
2. Определился с ключевыми операциями и настроил APDEX, указав целевое время. Это можно сделать, спросив у бухгалтеров, что конкретно тормозит.
3. Посмотрел бы, на сколько целевое время отличается от фактического (индекс APDEX).
4. Взял бы обычный SSD, положил бы базу на него и посмотрел бы, как от этого изменился однопоток в Гилеве.
Ну и да, виртуалка для 1С - это не очень хороший фактор. Ну и не понятно, настроена ли хост-система на высокую производительность, т.е. использует ли процессор буст, и на сколько хорошо. Ну и сам SQL можно настроить, распределив хотя бы дисковые ресурсы по разным дискам, увеличив количество баз для временных таблиц, ...
(9)Спасибо за участие в обсуждении. Да, есть. Если не затруднит, я ~1.5 года назад открывал тему, там есть тест гилева который весма не плох и пример отчета по договорам который формируется около 20 минут, очень долго, этот отчет в excel экспортировал показывает около 10.000 строк. .
(14) ну ниже 30 в гилеве - это так себе. Нормальная актуальная машина должна выдавать 40-50. Но у Вас просто проц фиговый древний с нтзкой частотой, поэтому так все не очень. Но для этого проца 25 - норм.
Ну и неясно, что конкретно тормозит. В вопросе по ссылке все правильно сказали, что нужно смотреть, что делает конкретный отчет, на чем висит. И нет границ в оптимизации - всегда можнотнаписать код так, чтобы он работал за секунды, для этого есть масса подходов, например, кеширование данных и промежуточных расчетов. Запрос в цикле может легко сделать простой и быстрый код медленным куском г-на.
Может с малого начать: обновить MS SQL, просмотреть планы обслуживания, чтобы индексы, статистика вовремя обслуживались.
При переходе с 2012 на 2019 SQL на казалось бы ровном месте получили огромный прирост производительности, по некоторым запросам в разы скорость выполнения увеличилась. Режим совместимости покрутить, еще есть настройки баз интересные. И поддержу мысль о том, что от виртуализации лучше уйти.
Безусловно SSD увеличит быстродействие и отклик запросов. Кто-то выше писал на 30% - соглашусь, допускаю и выше скорость. НО, при выборе учитывайте надежность контроллеров на которых будут работать SSD, это самое важное, тут я думаю вы понимаете, что все бекапы должны храниться исключительно на HDD, SSD нужен только для скорости.
Также обратил внимание на ваш сервер на базе - Intel Xeon E5-2630 v4 10. По возможности обновите и его, он уже староват и частота маловата, всего в бусте 3.1 Ггц
(8) По поводу обновления есть разные мысли и за и против, кто-то говорит что лучше не трогать, вот вы например говорите что нуждно обновить MS SQL. Вот даже не знаю что делать. "...еще есть настройки баз интересные" - можно по подробнее пожалуйста? К сожелении от виртуализации на данный момент нет возможности уйти, это предпологает расходы которые не предусмотрено в бюджете и скоро я думаю не предвидится. Спасибо.
(15) Не дба, и спецом по MS SQL себя не считаю, поэтому на истину не претендую.
Версия к версии Майкрософт допиливают/изменяют оптимизатор запросов. В зависимости от режима совместимости планы запросов, соответственно и скорость их выполнения могут сильно меняться. В самом запущенном случае у нас было время выполнения запроса с 5 минут уменьшилось до 20 сек, при изменении только режима совместимости у базы.
Макс степень параллелизма, исправление оптимизатора запросов можно установить для базы (но это особо не крутил).
С темпдб работа оптимизируется как-то, по крайней мере, Майкрософт так пишут.
Найти бы мне хорошего специалиста 1С, пройдется по коду и он быстро найдет "bottleneck", так сказать Audit нужен,но в наших краях таких наверняка сосчитать по пальцам да и еще знать где их найти. А то наш 1С контрактник установил да и забыл, что надо бухгалтерии быстро прелипил но о оптимизации кода даже и речь не едет, хотя большая доля вероятности что проблема тут.
Найти бы мне хорошего специалиста 1С, пройдется по коду и он быстро найдет "bottleneck", так сказать Audit нужен,но в наших краях таких наверняка сосчитать по пальцам да и еще знать где их найти. А то наш 1С контрактник установил да и забыл, что надо бухгалтерии быстро прелипил но о оптимизации кода даже и речь не едет, хотя большая доля вероятности что проблема тут.
как вы плавно перевели тему от обновления железа к оптимизации кода)
(16) ну так вон в соседней теме мильон фрилансеров индексируют себе зряплаты. А нажать замер производительности в конфигураторе самый последний стажер сможет за три копейки. Даже Вы сами это сможете сделать. Другое дело - результаты интерпретировать. А так - тут все готовы свои интерпретации выдать, кое-кто даже за так)))
(25)Дать доступ удалёно к такой информации я бы не стал, нужен человек который был бы на месте, буду искать, может всетаки найду. Но за подсказку скажу спасибо, может найдется фрилансер с моего города, создам заказ.
Дать доступ удалёно к такой информации я бы не стал
Ну так можете до своего компа анидеском прокинуть и наблюдать, что чел делает. Ему останется зайти в конфигуратор, запустить базу в режиме отладки, Вы нажмете формирование отчета, он нажмет замер, отключится, после формирования снова подключиться и посмотрит код, который в отчете занимает максимум времени, даст свою экспертную оценку в части, что с этим дальше делать.
Будут ли на SSD быстрее формироваться какие-то отчеты? Имхо вопрос толком не сформулирован, какие-то будут, какие-то нет. Гляньте хотя-бы виндовым монитором ресурсов - что происходит во время формирования интересующих отчетов - проц там пыхтит или длина очереди диска растет
(23) судя по картинке там у вас запрос в цикле. Сама 1С на курсах говорит о том, что так делать не надо. И непонятно, нафига вообще прогрессбар отчету (хотя если он 20 минут пилится, то смысл появляется).
Ну и как-то подозрительно мало памяти скулу выделено.