Почему практически не выросла производительность базы при переходе на SSD Raid массив?

Форум Администрирование Общие вопросы администрирования (Admin)

1. Michale 08.12.11 11:00 Сейчас в теме

Имею 2 сервера, на одном крутится сервер 1С и сервер терминалов (терминальщиков не много 4-8 человек), на другом SQL сервер. Сервера оба двухпроцессорные. Первый с 2 ядерными ксеонами, второй с 4 ядерными. Оперативки соответственно на первом 5 гиг на втором 16. На SQL сервере база располагалась раньше на raid контроллере собранном в 5-ом рэйде из 6 SAS винтов 15 тыс оборотов. Давненько не проводили никаких модернизаций, сервера в такой конфигурации работали с 2007 года, база хранит в себе данные с 2005 года и доросла со временем до размера в 41 гиг. Начали доставать тормоза. После просмотра очереди записи на диск было принято решение об эксперименте с ускорением дисковой подсистемы SQL сервера. Решили испытать SSD Raid массив из 4 дисков Corsair по 90 гиг каждый. В результате тестирования продолжительными операциями в 1-2 пользовательском режиме, получили увеличение производительности от 0 до 20%. Потестировали этот же массив разными тестировщиками и по их данным скорость массива выросла в среднем в 3 раза. Как найти узкое место в системе и почему ускорение такое ускорение дисковой подсистемы практически никак не отразилось на скорости в 1С?

Ответы

Подписаться на ответы Инфостарт бот

Свернуть все

2. Alex1c 32 08.12.11 11:04 Сейчас в теме

(0) не указана версия 1С. Речь идет о базе 41 гиг с 4-8 пользователями?

3. Michale 08.12.11 11:07 Сейчас в теме

Я же в заголовке написал 1С УПП, 8.0 релиз 1.1.3.5, использовалась в качестве базы и очень сильно дорабатывалась самостоятельно, так что от обновлений было решено отказаться. В базе в режиме активности около 50-55 пользователей, 4-8 из них подключаются терминально. Терминальный сервер и сервер 1С одно и тоже лицо.

13. Serg0FFan 08.12.11 17:18 Сейчас в теме

(3) Michale, а может дело в недостатке памяти для SQL? 16гиг маловато как то. Один рабочий процесса на платформе 8.2.14.540 сейчас жрёт до 1.5гигов, всего их 3, ну и системе 2 гига минимум отведите, в итоге имеем 9.5 гигов под SQL, это не много. Любит он когда памяти много, ну и по ощущениям моим все стало пошустрее работать после перевода сервера на новую платформу 8.2.14.540, до этого стояла 8.2.13.219 почти год.

4. Уфаныч 08.12.11 11:29 Сейчас в теме

// телепатия он
Могу предположить, что всё дело в рэйде.
// телепатия офф

// дело он

Каков размер блока в рэйде? Каков размер кластера файловой системы, на которой живёт база sql (если база не raw)? В исходных винтах секторы 512-байтные или 4-к? В новом SSD сектор 512б или 4К?

Если размер страницы в SQL - 8к, то нужно все эти размеры свести к 8к: и кластер ФС, и размер блока рэйда.

Кроме того, не указано, журнал у sql-базы расположен на том же самом томе, что и база, или нет? Ещё с SQl 6.5 была рекомендация выносить журнал базы на другой физический диск. Может быть лучше вынести журнал на ssd?

5. Michale 08.12.11 13:41 Сейчас в теме

Контроллер Intel Raid Controller RS25DB080 1G
Диски SSD CorsairForce 3 90Gb - 4 шт.
Raid 5 уровня.
Если дело в рэйде то почему тесты показывают такой неслабый прирост?

Вот данные теста старого рэйда построенного на 6 SAS винтах с 15 тыс. оборотов

Вот данные по новому рэйду из 4-ех SSD дисков

IOMeter в режиме database выдает практически такое же превосходство.

Размер блока в рэйде 64К.
Размер кластера диска 64К.
Диск NTFS.

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

6. ibazh 08.12.11 13:48 Сейчас в теме

Я думаю здесь вопрос к ядру, насколько пользует оптимизация

7. Michale 08.12.11 13:53 Сейчас в теме

ibazh пишет:

Я думаю здесь вопрос к ядру, насколько пользует оптимизация

Извиняюсь не понял? можно поподробнее?

8. maxkisa 08.12.11 16:26 Сейчас в теме

Michale пишет:
Я же в заголовке написал 1С УПП, 8.0 релиз 1.1.3.5

Т.е. все это крутится под платфорной 8.0? не 8.1 и не 8.2?
Если так, до для эксперимента советую попробовать на современной платформе потестить. То что, первые релизы 8-ки тормозили - это факт =) Точно помню, что между какими-то соседними релизами скорость записи бух регистра отличалась в разы!!!

11. Michale 08.12.11 16:57 Сейчас в теме

(8) maxkisa, Да всё под 8.0, переход на более поздние релизы планировали, но всё руки не доходят, пол отдела сократили и теперь как загнанные белки крутимся.

9. odindec 08.12.11 16:43 Сейчас в теме

странное решение: брать несколько ссдшников и ставить в рейд на SATA
более логично брать ссд со своим "личным" быстрым контролерром - принципиально лучше работает

но и странно было улучшшаить дисковую подсистему не убедившись что именно она является узким местом??

12. Michale 08.12.11 17:03 Сейчас в теме

(9) odindec,
брать рэйд со своим контроллером это как? отдельные платы сразу с распаянным жестко заданным объемом памяти не очень надежный вариант для сервера, никакого резервирования, никакой универсальности.

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

Вы бы лучше сказали как можно на 100% сказать где узкое место в системе, вместо того чтоб давать высокомерные советы.

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

14. Serg0FFan 08.12.11 17:21 Сейчас в теме

(12) Michale, сорри, про память я чуть ошибся, у вас под SQL отдельный сервер, это хорошо. Все равно я бы сначала обновил платформу и потом уже смотрел. Причем можно с помощью теста Гилёва сделать замер производительности до апгрейда и после, чтобы проверить есть результат или нет.

16. maxkisa 08.12.11 17:39 Сейчас в теме

(14) Serg0FFan,

+ на сколько я понимаю, в 8.0 под х64 была только бета версия сервака 1С.

15. Serg0FFan 08.12.11 17:33 Сейчас в теме

(12) Michale, кстати, на сервере 1С у вас сколько рабочих процессов? 1 - мало.

24. Michale 22.12.11 10:37 Сейчас в теме

(15) Serg0FFan,
Да на сервере с 1С один рабочий процесс. И честно говоря я даже не в курсе на счет возможности создания нескольких. Если дадите ссылки по этому вопросу буду признателен.

30. Serg0FFan 26.12.11 17:07 Сейчас в теме

(24) Michale, вот тут расписано все более менее http://www.gilev.ru/1c/app/

17. odindec 09.12.11 11:27 Сейчас в теме

(12) Michale, каюсь за "высокомерность" - я тут человек новый, только зарегался - нужно было обработку скачать по-быстрому ;)

по-существу могу только порассуждать: при выделенном SQL сервере и 16гигах оперативки на нем странно было бы "упереться" в диски... скорость работы базы именно снизилась со временем (ростом базы) или вас она просто перестала устраивать?
и в чем выражаются "тормоза"? какие-то спецефические моменты или "буквально все" медленно работает?
из "41 гига базы" ведь наверняка бОльшая часть лежит историческим грузом и ни текущее проведение документов ни отчеты не обращаются к "старым" данным ?
а у вас очередь на запись большая... неужели 4-8 человек способны генерировать большой объем новых документов?

что у вас за конфигурация? самописная/доработанная? - может посмотреть "внутри" на предмет тонких мест? что именно тормозит "запись доков/движений" ?

25. Michale 22.12.11 10:53 Сейчас в теме

(17) odindec,

У меня как раз сложилось впечатление, что дело вовсе не в оперативке. Дело в том что совсем недавно добавляли 8 гиг оперативки в SQL сервер в результате вообще не заметили даже малейшего прироста в скорости. Ни отчеты ни проведение документов быстрее не стало.
Повторюсь в базе работает около 50 человек. Бывают всплески до 60 одновременных пользователей, но основную массу времени именно в районе 50. Из этих 50 пользователей 4-8 пользователей терминальщики. Терминальный сервер и сервер 1С Предприятия это одна железка.

Конфигурация, порядочно переделанная УПП.

10. odindec 08.12.11 16:46 Сейчас в теме

еще добвалю что в моем случае ссд-диск (на своем контроллере) заработал в полную силу только с переходом на Вынь2008 (до этого 2003 была - наверно можно было и там добиться, но теперь ситуацию не восстановить чтобы понять с чем это связано)

18. dyh 4 09.12.11 15:20 Сейчас в теме

На ноуте в7, форс гт 120гб, 8рам. База 10гб работает быстрее чем на сервере (тс+скул, 1х юзер). серв е5520, 16гиг, р1 на 15000сас, в2003.

лечите платформу/конфу

19. Serg0FFan 09.12.11 15:54 Сейчас в теме

(18) dyh, она и будет работать быстрее, т.к. файловый вариант до определенного момента шустрее, а вот если вы свой файловый вариант дадите одновременно 10 юзерам по сети юзать? У вас оборотка за год будет формироваться минут5 не меньше! А вот для SQL что за год что за неделю, разницы нет, все будет секунд 5 не больше формироваться. В этом прелесть SQL - не такая зависимость от нагрузки как в файловом варианте. Но конечно по скорости SQL проигрывает с файловым вариантом. В случае работы одного пользователя в базе,а вот когда их будет больше 10 тогда и поймете разницу. Все мною сказанное относится к работе пользователя по сети, а не локально.

20. dyh 4 09.12.11 16:30 Сейчас в теме

(19) Serg0FFan,
Извините, некорректно написал (каюсь, $m, чтоб их). На ноуте тот же скул и виртуалка 2008. Т.е. условия максимально идентичные.

А про особенности скула и файла в курсе вроде б уже все ;)

PS Вообщем пробовать 8.2 пускать.

21. savvato 10.12.11 01:36 Сейчас в теме

(каюсь, $m, чтоб их)

тут половина из-за них бред пишет ;)

22. zzz_natali 61 16.12.11 16:44 Сейчас в теме

Вы бы лучше сказали как можно на 100% сказать где узкое место в системе, вместо того чтоб давать высокомерные советы.

Узкое место в 8.0. Надо однозначно обновляться.

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

раскидывать надо mdf/ldf/tempDB по разным дискам

26. Michale 22.12.11 10:55 Сейчас в теме

(22) zzz_natali,
mdf и ldf на одном SSD рэйде, tempDB на втором рэйде из SAS дисков на 15 тысяч оборотов.

29. zzz_natali 61 22.12.11 11:47 Сейчас в теме

(26) Michale,
Остается апгрейд платформы на 8.2

23. Diego_Iv 34 19.12.11 12:26 Сейчас в теме

А почему именно рейд 5 используется? ИМХО напрашивается рейд10 с таким количеством дисков, для скуля он определенно быстрее будет, особенно при записи.

27. Michale 22.12.11 11:00 Сейчас в теме

(23) Diego_Iv,
Потому, что по результатам теста именно 5-й рэйд как не странно показывает большую скорость на запись с данным количеством дисков.
Пробовал рэйд 5-й из трех дисков собирать, вот тогда он по скорости уступает десятому, а из 4 дисков 5-й рейд обгоняет 10-й на записи.
Нулевой вариант рэйда конечно уделывает по скорости и 5-й и 10-й, но чтобы десятый обогнал пятый мне придётся докупить еще штуки 4 диска.

28. zzz_natali 61 22.12.11 11:40 Сейчас в теме

Michale пишет:
Нулевой вариант рэйда конечно уделывает по скорости и 5-й и 10-й

И? Что смущает? Надежность?
Если мы говорим о том, что у нас крутейшие бизнес-процессы, в базе сидит полсотни манагеров, постоянно идут сделки, выписка счетов, отгрузок/поставок... что как следствие предполагает под это дело мощное железо, штат обслуги, постоянный регламент работы с базой и т.д. О каких таких дополнительных винтах говорить? Просто смешно!
Если бюджет урезан по хардам/софту и надо изгаляться "как можем", то чем плох вариант с нулевым райдом? Все равно бакапы как делались, так и делаются. И неизвестно, в каком случае быстрее поднимать систему... (я к тому, что если на 5м райде полетел винт, а производительность дисковой подсистемы архи-важна, то тормоза от выхода на крейсерскую скорость райда по времени после замены и синхнхронизации нового HDD - бабушка на двое сказала...)

Оставьте свое сообщение

E-mail: